Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt

From: [email-masked]
Date: Wed, 12 Oct 2005 15:50:02 -0400

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 
[email-masked] 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:
	[email-masked].
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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Oct 2005 21:41:46 +0100

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: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 12, 2005 8:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-10.txt

> implementation to automatically retrieve the ASCII version of the

--------------------------------------------------------------------------
------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 13 Oct 2005 17:50:51 +0200

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 ([email-masked])."
.
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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Oct 2005 01:54:47 +0100

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

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 14 Oct 2005 14:40:06 +0200

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" <[email-masked]>
To: "Tom Petch" <[email-masked]>; <[email-masked]>
Cc: "Thomas D. Nadeau" <[email-masked]>
Sent: Friday, October 14, 2005 2:54 AM
Subject: Re: IANA-GMPLS-TC-MIB was New versions of GMPLS MIBs

Hi Tom,

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.

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