RE: errors in draft-ietf-te-mib-12.txt

["Thomas D. Nadeau" <tnadeau@cisco.com>]

	One comment below.

>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
>Of Wijnen, Bert (Bert)
>Sent: Sunday, September 07, 2003 2:11 PM
>To: 'Stefan Winter'; mpls@UU.NET; iesg@ietf.org
>Subject: RE: errors in draft-ietf-te-mib-12.txt
>
>
>Inline
>
>> -----Original Message-----
>> From: Stefan Winter [mailto:mail@stefan-winter.de]
>> Sent: zondag 7 september 2003 9:46
>> To: mpls@UU.NET; iesg@ietf.org
>> Subject: errors in draft-ietf-te-mib-12.txt
>> 
>> 
>> Hello,
>> 
>> sorry for bothering you again. But during the implementation 
>> of the MPLS MIBs I came across some more inconsistencies...
>> 
>> 1) concerning data types: mplsTunnelIndex is of syntax 
>mplsTunnelIndex, 
>> derived from UNSIGNED32. But the corresponding scalar 
>mplsTunnelIndexNext is 
>> of type IndexIntegerNextFree, derived from INTEGER32. I 
>don't think it is a 
>> good idea to have different data types for these two.
>> 
>That would indeed not be a good idea, but as far as I can tell,
>IndexIntegerNextFree is also an Unsigned32, as per this snippet
>from RFC3289, where it is IMPORted from:
>
>  IndexIntegerNextFree ::= TEXTUAL-CONVENTION
>    DISPLAY-HINT "d"
>    STATUS   current
>    DESCRIPTION
>       "An integer which may be used as a new Index in a table.
>
>       The special value of 0 indicates that no more new entries can be
>       created in the relevant table.
>
>       When a MIB is used for configuration, an object with this SYNTAX
>       always contains a legal value (if non-zero) for an index that is
>       not currently used in the relevant table. The Command Generator
>       (Network Management Application) reads this variable 
>and uses the
>       (non-zero) value read when creating a new row with an SNMP SET.
>       When the SET is performed, the Command Responder (agent) must
>       determine whether the value is indeed still unused; Two Network
>       Management Applications may attempt to create a row
>       (configuration entry) simultaneously and use the same value. If
>       it is currently unused, the SET succeeds and the Command
>       Responder (agent) changes the value of this object, according to
>       an implementation-specific algorithm.  If the value is in use,
>       however, the SET fails.  The Network Management Application must
>       then re-read this variable to obtain a new usable value.
>
>       An OBJECT-TYPE definition using this SYNTAX MUST specify the
>       relevant table for which the object is providing this
>       functionality."
>    SYNTAX   Unsigned32 (0..4294967295)
>
>Now, since MplsTunnelIndex has a range of (0..65535). It might indeed
>be a good idea to change:
>  mplsTunnelIndexNext OBJECT-TYPE
>     SYNTAX        IndexIntegerNextFree
>into:
>  mplsTunnelIndexNext OBJECT-TYPE
>     SYNTAX        IndexIntegerNextFree (0..65535)
>So that it is inline with the range that a real tunnel index can get.

	If this is the recommendation, we can do this.

	--Tom



>> 2) DESCRIPTION clause of mplsTunnelIndex states "should 
>>    obtain new values for row creation in this table by reading 
>>    mplsTunnelIndexNextFree". The scalar in question is not called 
>>    mplsTunnelIndexNextFree but mplsTunnelIndexNext.
>> 
>Good catch! 
>
>Thanks for pointing these out.
>
>> BTW, I never got a reply to my comments in message 
>> http://cell.onecall.net/mhonarc/mpls/2003-Aug/msg00105.html
>> I hope it didn't get lost...
>> 
>I was hoping/assuming that the document authors will indeed
>at least answer, but probably also address your comment in that
>posting. If you can pls keep an eye on it when the next
>revision of the doc comes out, that would be great! 
>
>Bert
>> Greetings,
>> 
>> Stefan Winter
>> 
>> 
>