Re: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs

["Adrian Farrel" <[e-mail]>]

Hi Tom,

OK, I think I understand your concerns better now.

Would your issue be solved by the inclusion of a statement like...

         Values of IANAGmplsSwitchingType are reserved for
         switching types that correspond to entries in the 
         Switching Types sub-registry of the GMPLS Signaling
         Parameters registry managed by IANA.

Since that registry is controlled by allocation policies already agreed by IETF consensus, this text would ensure that new allocations within the textual convention would be equally controlled.

I want to retain the "However, the actual values..." text because I do not want to force the values used in the textual conventions to match the values used in the protocol elements. For example, if the relevant working group decided to assign widely discontiguous values for a protocol field, I would not want to force the IANA to use those identical values in the textual convention. It would be adequate that they assigned values that corresponded but were not equal.

A concrete example is provided by IANAGmplsSwitchingType. This takes values to correspond to the GMPLS switching types, but these have values in the IANA registry of 1, 2, 3, 4, 51, 100, 150, 200. The IANA may consider that it is inappropriate to assign enumerations in a TC that are discontiguous, and could assign values 0 through 8 rather than those suggested in the draft.

You are correct that the text in section 11.2 is broken and should point to the description clauses of the individual TCs. Thanks for catching this.


Question: does all this address your concerns?

Note: We have just submitted new revisions of the MIB modules to fix compilation issues, and those revisions do not attempt to address this issue.


Cheers,
Adrian






> I am still uncomfortable with the apparent lack of constraints for the
> allocation of new values in IANA-GMPLS-TC-MIB.  There is now
> 
> "The rules for additions or changes to the IANA-GMPLS-TC-MIB are
>    outlined in the DESCRIPTION clause associated with its
>    MODULE-IDENTITY statement."
> 
> but I do not see anything about this in the DESCRIPTION clause.  Rather, it is
> the DESCRIPTION clauses of individual TCs that contain the information, e.g.
> 
> "This textual convention is strongly tied to the Switching
>              Types sub-registry of the GMPLS Signaling Parameters
>              registry managed by IANA. Values should be assigned by IANA
>              in step with the Switching Types sub-registry and using the
>              same registry management rules. However, the actual values
>              used in this textual convention are solely within the
>              purview of IANA and do not necessarily match the values in
>              the values in the Switching Types sub-registry.
> <snip>
>              Requests for new values should be made to IANA via
>              email ([e-mail])."
> .
> It is that "However ..." that bugs me; coupled with the final sentence, I still
> see an e-mail from anyone in any SDO or elsewhere causing IANA to allocate a new
> value regardless of on-going work in the IETF.  Perhaps unlikely given the
> close-knit world of GMPLS but I would still like to see tighter control, Expert
> Review would be my choice.
> 
> But I am also unclear what change control was intended by the wording in the
> latest draft.
> 
> As with my my earlier e-mail,
> 
> "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.
> 
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Cc: "Thomas D. Nadeau" <[e-mail]>
> Sent: Wednesday, October 12, 2005 10:41 PM
> Subject: New versions of GMPLS MIBs
> 
> 
> > Hi,
> >
> > We have been working on the GMPLS MIBs after MIB Doctor comments.
> > The revisions just being posted have addressed all of the nits and
> > editorial issues except:
> >
> > - conformance/compliance
> > - lint
> > - compilation
> >
> > Tom has just been working on these issues and the ball is now back with me
> > to integrate his changes and republish. I hope to do this in the next
> > couple of days.
> >
> > In the mean time, if you have any comments on the revised versions then
> > please let us know.
> >
> > Cheers,
> > Adrian
> >
> >
> > ----- Original Message -----
> > From: <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Wednesday, October 12, 2005 8:50 PM
> > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt
> >
> >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > > This draft is a work item of the Common Control and Measurement Plane
> > Working Group of the IETF.
> > >
> > > Title : Generalized Multiprotocol Label Switching
> > >                           (GMPLS) Traffic Engineering Management
> > Information Base
> > > Author(s) : T. Nadeau, et al.
> > > Filename : draft-ietf-ccamp-gmpls-te-mib-10.txt
> > > Pages : 61
> > > Date : 2005-10-12
> > >
> > > This memo defines a portion of the Management Information Base (MIB)
> > >    for use with network management protocols in the Internet community.
> > >    In particular, it describes managed objects for Generalized
> > >    Multiprotocol Label Switching (GMPLS) based traffic engineering.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-10.txt
> > >
> > > To remove yourself from the I-D Announcement list, send a message to
> > > [e-mail] with the word unsubscribe in the body of
> > the message.
> > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > to change your subscription settings.
> > >
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login with the
> > username
> > > "anonymous" and a password of your e-mail address. After logging in,
> > > type "cd internet-drafts" and then
> > > "get draft-ietf-ccamp-gmpls-te-mib-10.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > > [e-mail].
> > > In the body type:
> > > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-10.txt".
> > >
> > > NOTE: The mail server at ietf.org can return the document in
> > > MIME-encoded form by using the "mpack" utility.  To use this
> > > feature, insert the command "ENCODING mime" before the "FILE"
> > > command.  To decode the response(s), you will need "munpack" or
> > > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > > exhibit different behavior, especially when dealing with
> > > "multipart" MIME messages (i.e. documents which have been split
> > > up into multiple messages), so check your local documentation on
> > > how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > >
> >
> >
> > --------------------------------------------------------------------------
> > ------
> >
> >
> > > _______________________________________________
> > > I-D-Announce mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/i-d-announce
> > >
> >
> >
> 
> 
>