The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Hi All,

On Mon, 22 Nov 2004 Internet-Drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.
>
> 	Title		: LDP Specification
> 	Author(s)	: L. Andersson, et al.
> 	Filename	: draft-ietf-mpls-rfc3036bis-01.txt
> 	Pages		: 162
> 	Date		: 2004-11-22

Let me quote Thomas Narten on the use of "IETF consensus" (and to
avoid quoting out of context, I quote at length at the end; you can
look up the whole email on the ietf list):

Thomas said: 'As one of the authors of RFC 2434 "Guidelines for
Writing an IANA Considerations Section in RFCs", I have long regretted
defining the term "IETF Consensus" as it is in that document.'

I would *strongly* recommend against using "IETF consensus" in the
LDP-bis Draft Standard document.

Here's my take on the IANA considerations section:

a) The first range should be allocated as Standards Track.
   Furthermore, stuff like "Message types in this range are part of
   the LDP base protocol." should be removed -- those not defined in
   this document are clearly not part of the base protocol.

b) The Vendor-private space uses a vendor ID as administered by the
   IEEE.  This is sub-optimal.  There is a vendor ID (more accurately,
   enterprise ID, but just about every vendor has one) space
   administered by IANA; moreover, this is the ID of choice for other
   vendor-private spaces (cf. RFC 3936, and draft-kompella-ospf-iana-...)
   This was not my first choice, but rather the result of much
   discussion.  Given that, if no one is using the LDP vendor private
   space today (and those who are are willing to change their
   implementation), it would be better to standardize on a common
   notion of "vendor ID".

c) For the Experimental space, ideally one would cite RFC 3692 -- and
   recommend the procedures thereof.

d) There is no reason to exhaust the entire space at this stage.  For
   example, for the Message type space, one could use 0x0000 - 0x1fff
   for Standards Action, 0x3e00 to 0x3eff for Vendor private, and
   0x3f00 - 0x3fff for Experimental.  The rest can (and should, imo)
   be set aside, with the caveat that values from the reserved space
   cannot be allocated until there is a Standards Track or BCP RFC
   that defines the allocation policy for that range.  There is no
   danger of 8000 Standards Action code points being used up in a
   hurry, given the glacial pace of Standards Track RFCs.  On the
   other hand, the notions of Vendor Private and Experimental are
   fairly new, and who knows what other new types will come up that
   for which we might need an allocation range?

e) I would *strongly* recommend against having a First-Come-First-Served
   range for the FEC Type name space.  It is too small to frivolously
   waste, and FCFS is a dangerous policy [keep in mind 'teeth' and the
   (G)MPLS change process].

Kireeti.
-------

Date: Wed, 29 Jan 2003 20:20:26 -0500
From: Thomas Narten <narten@us.ibm.com>
To: RJ Atkinson <rja@extremenetworks.com>
Cc: Bob Braden <braden@ISI.EDU>, ietf@ietf.org, kireeti@juniper.net,
     iesg@ietf.org
Subject: "IETF consensus"  in IANA considerations [was Re: Last Call:
    CR-LDP Extensions for ASON to Informational ]

RJ Atkinson <rja@extremenetworks.com> writes:

> On Thursday, Jan 23, 2003, at 17:54 America/Montreal, Bob Braden wrote:
> > I interpret "IETF consensus" as meaning that at least a Last
> > Call was conducted.  To use any other interpretation seems to me to
> > be dishonest.  I guess I am agreeing with Kireeti.

> [IAB hat off]

> I agree with the above.  IESG approval is not identical to IETF
> consensus.  If it were, the IETF community would not be giving such
> vocal feedback about concerns with the IESG at the last 2 meetings
> and on the ietf-problems mailing list, IMHO.

As one of the authors of RFC 2434 "Guidelines for Writing an IANA
Considerations Section in RFCs", I have long regretted defining the
term "IETF Consensus" as it is in that document. 2434 says:

>       IETF Consensus - New values are assigned through the IETF
>            consensus process. Specifically, new assignments are made via
>            RFCs approved by the IESG. Typically, the IESG will seek
>            input on prospective assignments from appropriate persons
>            (e.g., a relevant Working Group if one exists).
>
>            Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address
>            Family Identifiers [BGP4-EXT].

The intent of the above wording was to provide a way for documents to
request that IANA only assign code points when there exists a document
that gets published as an RFC. The wording above specifically does not
say "Standards Track" RFC and was intented to include informational
and experimental documents, whether from a WG or not. There is an
alternate definition - "Standards Action" - that can be cited if IANA
assignments are only to be made for Standards Track documents.

I think intent of the above definition is fine. But naming the term
"IETF Consensus" is obviously problematical and confusing, as there
are many Info and Experimental RFCs for which there is nothing close
to IETF consensus on, and no one would claim so.

So, let's be clear that in the context of most of the discussion on
this thread, folks seem to be applying their own definition of what
"IETF Consensus" means when in fact the 2434 definition is what should
be used, as is cited in the relevant IANA considerations section.

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls