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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

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.

> 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
> 
>