Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Joan,

> > > 7) gmplsTunnelUnnumIf
> > >
> > > What IF-MIB object are referring to in the DESCRIPTION?
> > > Could you state which object in the description?
> >
> > Ack
> > An entry in ifTable.
>
> Could you specify the ifType(s)?

Yup. It'll be 166 (MPLS).

Added to document.

> > > Section 11.2.1. IANA-GMPLS-MIB Definition
> > > -----------------------------------------
> >
> > > 38) I believe that the TC
> > >
> > >    IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION
> > >
> > > should be put in the GMPLS-TC-STD-MIB or should just
> > > remain in the GMPLS-TE-STD-MIB.  The reason is that this
> > > is not an assigned numbers list maintained by IANA, so
> > > should not be in the IANA GMPLS MIB.  If I am incorrect
> > > about this please let me know, but I didn't see an IANA
> > > maintained Administrative Status Information enum.
> >
> > Nack
> > There are no fewer than three requests in CCAMP I-Ds that have passed
WG
> > last call for this space to be managed by IANA.
>
> Is this going to be managed by IANA soon?  (just curious)

Cerainly it'll happen before this I-D is an RFC.

Soon? I wouldn't want to comment on the IESG review process and RFC Editor
process (but I am serving on the PESCI team).

> > > 39) Several comments on the SYNTAX clause:
> > >
> > > 40a) smicngPRO gives the error
> > >
> > > E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS
> > > must be in contiguous positions
> > >
> > >       SYNTAX  BITS {
> > >                      delInProgress (0),
> > >                      adminDown (1),
> > >                      testing (2),
> > >                      reflect (31)
> > >                    }
> > >
> > >
> > > RFC2578 specifies that BITS should be contiguous
> > > (although there are exceptions to this, but this
> > > object does not seem to be an exception).
> >
> > Nack
> >
> > To quote the DESCRIPTION...
> >              The relationship between the assignment of
> >              gmplsTunnelAdminStatusFlags values and of the bit flags
> >              in the Admin Status object or TLV within the GMPLS
> >              signaling protocols is solely the purview of IANA and is
> >              subject to change without notice."
> > However, it seems to us that making the bits match the flags in the
> > Admin Status object is a Good Idea (TM).
> >
>
> Here is the TLV that the object represents:
>
> 0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |R|                        Reserved                       |T|A|D|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       Reflect (R): 1 bit
>       Reserved: 28 bits
>       Testing (T): 1 bit
>       Administratively down (A): 1 bit
>       Deletion in progress (D): 1 bit
>
> The BITS as specified look backwards when viewing the TLV.
> Are the BITS correctly specified?
>
> I consulted with other MIB Doctors and the following was suggested:
>      SYNTAX  BITS {
>                       delInProgress (0),
>                       adminDown (1),
>                       testing (2),
>                       reserved3(3),       -- 0 on send, ignored on
receive
>                       reserved4(4),       -- 0 on send, ignored on
receive
>                       ..
>                       reserved30(30),      -- 0 on send, ignored on
receive
>                       reflect (31)
>                     }
>
> Would this be acceptable?

We can fill in the gaps.

Thanks once again for engaging.

Adrian