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

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

	Sorry for the delay. Answers inline.

>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
>Of Stefan Winter
>Sent: Sunday, September 07, 2003 3:46 AM
>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.

	It was recommended that we used IndexIntegerNextFree
as the basis for this object. I have constrained the 
values to being only positive and 0 to conincide with
the mplsTunnelIndex value and 0 as defined in the indexNext
object:

mplsTunnelIndexNext OBJECT-TYPE
   SYNTAX        IndexIntegerNextFree (0..65535)
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION  
       "This object contains an unused value for
        mplsTunnelIndex, or a zero to indicate
        that none exist. Negative values are not allowed,
        as they do not correspond to valid values of
        mplsTunnelIndex.
 
        Note that this object offers an unused value
        for an mplsTunnelIndex value at the ingress 
        side of a tunnel. At other LSRs the value
        of mplsTunnelIndex SHOULD be taken from the
        value signaled by the MPLS signaling protocol.
       "
   ::= { mplsTeObjects 1 }


>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; fixed:

mplsTunnelIndex OBJECT-TYPE
   SYNTAX        MplsTunnelIndex
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "Uniquely identifies a set of tunnel instances
          between a pair of ingress and egress LSRs. 
          Managers should obtain new values for row 
          creation in this table by reading 
          mplsTunnelIndexNext. When
          the MPLS signalling protocol is rsvp(2) this value
          SHOULD be equal to the value signaled in the
          Tunnel Id of the Session object. When the MPLS
          signalling protocol is crldp(3) this value
          SHOULD be equal to the value signaled in the
          LSP ID."
   ::= { mplsTunnelEntry 1 }

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

	Sorry. I believe this was the message in question:

Hello,

there is an inconsistency in the MIB definition of mplsTunnelHopTable in
the 
current draft of MPLS-TE-STD-MIB.
The DESCRIPTION clause of mplsTunnelHopTable claims that each row has
two 
indexes, mplsTunnelHopListIndex (Index 1) and mplsTunnelHopIndex (Index
2).
But the INDEX clause of mplsTunnelHopEntry has three indexes,
mplsTunnelHopListIndex (Index 1) 
mplsTunnelHopPathOptionIndex (Index 2)
mplsTunnelHopIndex (Index 3)
The DESCRIPTION clause of mplsTunnelHopTable needs to be updated to
reflect 
the correct indexing and should explain the secondry index 
mplsTunnelHopPathOptionIndex.


	I have corrected this in version -13.

	--Tom