[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
(iana@isi.edu)."
> .
> 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" <adrian@olddog.co.uk>
> To:
<ccamp@ops.ietf.org>
> Cc:
"Thomas D. Nadeau" <tnadeau@cisco.com>
> 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: <Internet-Drafts@ietf.org>
>
> To: <i-d-announce@ietf.org>
>
> Cc: <ccamp@ops.ietf.org>
> >
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
> > > i-d-announce-request@ietf.org 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:
> > > mailserv@ietf.org.
> > >
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
> > > I-D-Announce@ietf.org
> >
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> > >
> >
> >
>
>
>