IANA mib for GMPLS

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

I have been looking at a GMPLS MIB, thinking it might be improved and am tying
myself up in knots over it.

draft-ietf-gmpls-te-mib-08
defines three enumerations which are under IANA control; except they are not
enumerations at all.  gmplsTunnelSwitchingType has a SYNTAX of Integer32
(0..255) and a list of numbers and names is in the DESCRIPTION clause; I think
this should be an enumeration in a TC and under IANA control.

The original values were defined in RFC 3471 as part of the protocol and says
 " All future assignments should be allocated through IETF Consensus
   action or documented in a Specification."

They has been updated by draft-ietf-ccamp-ospf-gmpls-extensions-12.txt (which
has no IANA considerations so that needs fixing) while

draft-ietf-ccamp-gmpls-g709-09.txt says

 "Switching Type: Assigned by IANA via IETF Standards Track RFC  Action. "

so that is now more restrictive.

Question.  If this is defined as a TC under IANA control, then the numbers which
appear in the protocol will be under one part of IANA control while the
name-number bindings of the enumeration will be under a different part of IANA
control, duplication, with the possibility - no, make that probability - they
will get out of step.  Is this ok? Any precedents?

Assuming it is ok, what action should update the mib module?  If the protocol
numbers are standards track action, as they look like being, and a new I-D adds
a number to the protocol, will the author remember to add a new number to the
IANA MIB? unlikely, so to avoid needing a second RFC just to add the latter, I
would like a less stringent action for the mib, like Operations AD plus expert..

Finally, the DESCRIPTION clause of one of the other 'enumerations' lists VC1VC12
as one of the descriptors so that needs to be vc11vc12; fortunately, RFC 3471
does not specify this descriptor so that is readily changed (it took me ages to
see what smilint was complaining about).

 Thoughts?

Tom Petch