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

["Tom Petch" <[e-mail]>]

Aaaah, now I see; I had not imagined that the values in the MIB registry would
be different to those in the GMPLS registry (but I understand why they might).
Since I have been confused, I suggest expanding that sentence to

"However, the numerical values  used in this textual convention are solely
within the
purview of IANA and, for a given enumeration,  will not necessarily be the same
as the value in
the Switching Types sub-registry.  This might arise if the values in the
Switching Types sub-registry are unsuitable for use in SMIv2."


I am fine with your other sentence below (with similar sentences for each TC).

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <[e-mail]>
To: "Tom Petch" <[e-mail]>; <[e-mail]>
Cc: "Thomas D. Nadeau" <[e-mail]>
Sent: Friday, October 14, 2005 2:54 AM
Subject: Re: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs


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