[Pana] [Fwd: Re: PANA-SNMP REVIEWERS NEEDED]

[Yacine.El_Mghazli at alcatel.fr]

hello all,

please find below a review from robert story (SPD MIB author) on the 
pana snmp document. this is mostly related to the example section. the 
comments will be taken into account in the next version of the draft.

thanks,
yacine



-------- Original Message --------
Subject: Re: PANA-SNMP REVIEWERS NEEDED
Date: Thu, 28 Sep 2006 17:38:20 -0400
From: Robert Story <rstory at sparta.com>
Organization: SPARTA
To: Yacine.El_Mghazli at alcatel.fr
CC: baerm at tislabs.com,hardaker at tislabs.com,Yoshihiro Ohba
<yohba at tari.toshiba.com>,Julien Bournelle
<Julien.Bournelle at int-evry.fr>, Rafael Marin Lopez <rafa at dif.um.es>
References: <450125F4.40304 at alcatel.fr>



There has been a significant change in the upcoming 07 version of the
SPD MIB draft that will require some changes to the examples. The
spdEndpointToGroup table now uses ifIndex as the index for the table,
instead of AddressType+Address. Luckily this is a pretty simple change.
Affected tables in the examples section: spdEndpointToGroupTable,
ipiaIkeIdentityTable,


8.*

This entire section needs to be checked and revamped with respect to
how VariablePointer values are represented. The first case is here:

   spdGroupContentsTable, row 2:
   ...
   o  spdGroupContFilter = diffServMultiFieldClfrTable.10;

What you mean here is 'row 10 of the diffServMultiFieldClfrTable',
which you define later. The problem is that
diffServMultiFieldClfrTable.10 looks like a SNMP OID, but it isn't. The
text for    spdGroupContFilter states:

            [...] This value can be used to indicate a scalar or a
            row in a table.  When indicating a row in a table, this
            value MUST point to the first column instance in that row.

You can take a few approaches to fixing this:

- text        e.g. diffServMultiFieldClfrTable, index 10
- array-like  e.g. diffServMultiFieldClfrTable[10]
- valid OID   e.g. diffServMultiFieldClfrAddrType.10

I'd recommend the valid OID, as this represents the actual OID that
needs to be sent over the wire.

This problem is compounded when a table doesn't have a simple integer
index, as the diffServMultiFieldClfrTable does. The first example of
this is in 8.3:

   spdGroupContentsTable, row 6:
   ...
   o  spdGroupContFilter = ipiaPeerIdentityFilterTable.1;

   ipiaPeerIdentityFilterTable, row 1:
   o  ipiaPeerIdFiltName = "PaC1-IKE1-ID-FILTER";

Using the same options here, you would have:

- text        e.g. ipiaPeerIdentityFilterTable, row 1
- array-like  e.g. ipiaPeerIdentityFilterTable["PaC1-IKE1-ID-FILTER"]
- valid OID   e.g. ipiaPeerIdFiltIdentityType."PaC1-IKE1-ID-FILTER"


With regards to scalars, I'd also recommend that a valid OID be used.
That will usually mean that it will end with '.0'. e.g.
spdAcceptAction.0. An exception would be for objects which have the 0
defined in the MIB. These objects usually end with "Instance". (e.g.
spdTrueFilterInstance).



8.2.  General IP-based Access Control

You should remove the diffServMultiFieldClfrTable, row 2, since it
isn't referenced in the example and the last paragraph states that 'The
same thing must be done for the outgoing direction'.


8.3

   ipiaIkeActionProposalsTable, row 1:
   o  ipiaIkeActPropName = "PaC1-IKE-PROP1";
   o  ipiaIkeActPropPriority = '1';

This is confusing, despite the explanation above it about proper
indexing. At the very least, the priority needs to come before the
PropName. I recommend being explicit, and show both indexes:

   ipiaIkeActionProposalsTable, row 1:
   o  ipiaIkeActName = "PaC1-IKE";
   o  ipiaIkeActPropPriority = '1';
   o  ipiaIkeActPropName = "PaC1-IKE-PROP1";


The last sentence of the section is missing some info:

   [...] See for further details on the IPSP MIBs
   usage.


I'm still going over all the relationships between the tables in the
examples, to see if you've missed anything.

Some nits I noticed while skimming various sections:

6.2.  Notification of PaC presence

   If reliability needs to be guaranteed for the notification
   (panaNewPacNotification), hence Inform notification (which is
   acknowledged) MUST be used.

This should be either

   Since reliability needs to be guaranteed for the notification
   (panaNewPacNotification), Inform notification (which is
   acknowledged) MUST be used.

or

   If reliability needs to be guaranteed for the notification
   (panaNewPacNotification), then Inform notification (which is
   acknowledged) MUST be used.

--
Robert Story
SPARTA







_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana