Re: Last call complete on GMPLS MIBs

["Tom Petch" <nwnetworks@dial.pipex.com>]

Adrian

I finally got to look at the new versions of the GMPLS MIBs that came out in
June and am pleased to see my previous comments in use:-).  Some follow
up thoughts.

In draft-ietf-ccamp-gmpls-te-mib-09, I see that
IANAGmplsSwitchingType ::= TEXTUAL-CONVENTION
still references
                   "1. Kompella, K., Rekhter, Y. (Editors), Routing Extensions
                in Support of Generalized Multi-Protocol Label Switching
                draft-ietf-ccamp-gmpls-routing, work in progress.
which I think should be draft-ietf-ccamp-ospf-gmpls-extensions for
l2sc (51).  The former introduces the concept but does not give a value; the
latter assigns the value 51.

IANAGmplsLSPEncoding has a reference to
D. Papadimitriou (Editor), Generalized MPLS
                Signalling Extensions for G.709 Optical Transport
                Networks Control, draft-ietf-ccamp-gmpls-g709,
                work in progress
which I think should make that a normative reference.

And, more generally with these references to I-Ds which are normative, should we
add a note to tell the RFC editor to replace this with a reference to the RFC
when it emerges?  That would be business as usual in the References section but
might need a little encouragement buried in a MIB module DESCRIPTION.

IANAGmplsAdminStatusFlags defines BITS as
                     delInProgress (0),
                     adminDown (1),
                     testing (2),
                     reflect (31)
while RFC3471 has reflect as bit 0 and delInProgress as bit 31.  Is that
correct? (I assume that the intent is to keep them in line and I don't know
which way round BITS go; I assumed bit 0 came first and was MSB.  If ITU and
IETF part company over this, we should be using IETF nomenclature:-)

In draft-ietf-ccamp-gmpls-lsr-mib-08.txt, I would like you to give the RFC
Editor a little more help in resolving
GMPLSTCMIB
by explicitly stating that it is the RFC produced from
draft-ietf-ccamp-gmpls-tc-mib-07.txt

Somewhat bigger issue; I am concerned that no constraint is placed on the
allocation by IANA of new values in the IANA MIB module, where the base
documents call for more stringent action (although there is some disagreement as
to what that is).  As it stands, it seems to me that anyone in the world can
e-mail IANA and get a new value assigned in the IANA MIB module, whereas I think
it should be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing or
draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, perhaps by
Expert Review ie the existence of a new name/number mapping is documented in an
RFC or I-D and Expert Review allows that mapping to be added to IANA MIB module.
We could require the RFC that introduces a new mapping to have an IANA section
that updates the MIB module but I fear that most editors would forget to include
it, so Expert Review seems best.

Finally, I would prefer the IANA MIB modules to be retained in the published RFC
with a note that the authoritative source is IANA; this gives us an audit trail
of how we got to where we are, or not as the case may be.  There has been a case
just recently elsewhere where the RFC and IANA are different and it is valuable
to see just what it was that was last called and approved by all concerned.  As
and when the RFC containing the IANA MIB module is reissued, then there would be
no need to replicate it.

Tom Petch