Subject: Re: Last Call: CR-LDP Extensions for ASON to Informational

From: Bob Braden <[email-masked]>
Date: Tue, 14 Jan 2003 23:00:51 GMT

*> 
  *> > The IESG has received a request to consider CR-LDP Extensions for ASON
  *> > <draft-aboulmagd-ccamp-crldp-ason-ext-02.txt> as an Informational RFC.
  *> > This has been reviewed in the IETF but is not the product of an IETF
  *> > Working Group.
  *> 
  *> I have two comments about this draft.
  *> 
  *> The first is that the draft calls for assignment of code points for
  *> some new messages, TLVs and status codes.  The draft, however, fails
  *> to say from which spaces these should come (e.g., that to be allocated
  *> by IETF Consensus, First Come First Served, Experimental).  If this is
  *> not specified, then I would suggest that code points from Experimental
  *> spaces be used.
  *> 

According to the IANA assignment rules for RSVP values, the only two
options are IETF consensus and FCFS.

  *> If code points are to be allocated from the space to be allocated by
  *> IETF Consensus, I strongly suggest that a *Standards Track* document be
  *> written, with more detail on the messages, especially their processing.

Indeed, that is what "IETF consensus" means, isn't it?

Bob Braden

  *> Also, more detail on what the goal is here, under what circumstances
  *> these messages need to be sent/replied to, etc.
  *> 
  *> Kireeti.
  *> 
  *>

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 14 Jan 2003 16:40:39 -0800 (PST)

> options are IETF consensus and FCFS.

The document in question is the *CR-LDP* Extensions.  I am (sadly)
aware of the RSVP assignment status.

> Indeed, that is what "IETF consensus" means, isn't it?

Is it?  That's good.  Currently, the document is Informational, and
is being processed as such.  Can this be changed?

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 14 Jan 2003 19:11:12 -0800 (PST)

> > Indeed, that is what "IETF consensus" means, isn't it?

Having wisely been advised to reread RFC2434 for the definition of
'IETF Consensus', I did so:

"Specifically, new assignments are made via RFCs approved by the IESG."

The RFC doesn't have to be Standards Track; however, I assume that the
RFC needs IETF consensus for publication.

If the assignments requested are from the IETF Consensus space, I do
not consider the current document ready for publication.

If the assignments are from the vendor private or experimental space,
this document is not needed; indeed, as I understand RFC 3036, IANA
management of these spaces is not needed either.

Kireeti.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 15 Jan 2003 08:38:59 +0100

--On tirsdag, januar 14, 2003 23:00:51 +0000 Bob Braden <[email-masked]> 
wrote:

>   *> IETF Consensus, I strongly suggest that a *Standards Track* document
> be   *> written, with more detail on the messages, especially their
> processing.
>

Bob,
as I said when we discussed this a bit earlier:

RFC 2434 defines this term, and it says, in extenso:

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

Quoting from the references: [SMTP-EXT] is RFC 1869:

   The IANA maintains a registry of SMTP service extensions.  Associated
   with each such extension is a corresponding EHLO keyword value. Each
   service extension registered with the IANA must be defined in an RFC.
   Such RFCs must either be on the standards-track or must define an
   IESG-approved experimental protocol.

[BGP4-EXT] is RFC 2283:

   Subsequent Address Family Identifiers (other than those reserved for
   vendor specific use) are assigned only by the IETF consensus process
   and IESG approval.

There are circumstances (IS-IS standardization is one; experiments are 
another; other non-IETF-managed extensions are a third) where it makes 
sense to have non-standards-track documents allocate values in registries 
where the IETF intends to keep some kind of control.

The IESG has made some use of the Last Call mechanism for these documents; 
that seems to be one way to implement "the IESG will seek input".

RFC 2434 reserves the term "standards action" for the case where a 
standards-track RFC is required; there is a reason why it defines two 
terms, not one.

                         Harald