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

From: Bob Braden <[email-masked]>
Date: Thu, 23 Jan 2003 22:54:08 GMT

*> 
  *> Hi,
  *> 
  *> I just saw the message that this document has been approved.  I
  *> have a question about the process.
  *> 
  *> Definition in RFC 2434, "IETF Consensus - New values are assigned through
  *> the IETF consensus process".  The CR-LDP code points are clearly marked
  *> as "IETF Consensus", not IESG Approval.
  *> 
  *> I have heard repeatedly, from at least 5 different ADs that three people
  *> for and one against does *not* constitute a consensus -- in fact, this
  *> was repeated in the TE WG list a couple of days ago.
  *> 
  *> There were several people that raised various objections, from nits
  *> to technical issues.  Many remain unanswered.
  *> 
  *> Am I to understand that the IESG inferred consensus from the discussions
  *> that have taken place (and are still under way)?
  *> 
  *> Kireeti.
  *> 

Since I was CC'd, I will note that in my role as IANA designated expert
for RSVP, 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.

Bob Braden

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 24 Jan 2003 12:36:45 -0500

On Thursday, Jan 23, 2003, at 17:54 America/Montreal, Bob Braden wrote:
> I interpret "IETF consensus" as meaning that at least a Last

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

I don't see how I could support the IESG if such a decision were 
appealed
to the IAB and no *successful* (meaning no substantive negative comments
received) Last Call were held per the usual IETF procedures.

Ran Atkinson
[email-masked]

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 24 Jan 2003 18:15:57 +0000 (GMT)

On Fri, 24 Jan 2003, RJ Atkinson wrote:

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

Can you give a pointer to this ietf-problems mailing list, please?

L.

> appealed to the IAB and no *successful* (meaning no substantive
> negative comments received) Last Call were held per the usual IETF
> procedures.
>
> Ran Atkinson
> [email-masked]

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 24 Jan 2003 20:30:09 +0100

> Can you give a pointer to this ietf-problems mailing list, please?

[email-masked] - use the "-request" convention to 
subscribe.

This list was set up in conjunction with the IESG plenary in Atlanta, and 
has been used to continue the discussion from there. A working group 
charter is being discussed.

                Harald

> _______________________________________________
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed. Decisions on
> what to pass are made solely by Raffaele D'Albenzio.
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 29 Jan 2003 09:43:10 +0100

and I forgot....
the archives are at
http://eikenes.alvestrand.no/pipermail/problem-statement/

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Jan 2003 20:20:26 -0500

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

I don't know what can be done a this point to change the terminology
in 2434. It's been in use for some 4 years now...

I'm reminded of another great choice of terms, the Best Current
Practice, where we have had numerous threads about whether something
was actually "best" or a "currently practice". There too, the actual
definition as defined in the RFC is not quite the same as the what the
literal term might suggest.

Thomas

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Jan 2003 21:12:36 -0500

--On Wednesday, 29 January, 2003 20:20 -0500 Thomas Narten 
<[email-masked]> wrote:

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

Thomas, not to be splitting hairs, but the intent --at least in 
SMTP-EXT (STD10/RFC1869), which was cited as an example-- was 
somewhat more than simple publication as an RFC (or, in your 
words, "a document that gets published as an RFC").  While, 
clearly, "standards track" was not intended, we did intend that 
the IESG make a formal decision that the request was consistent 
with community consensus (as well as having a published 
document).  We didn't specify what steps the IESG would go 
through in reaching that conclusion, but, other than the 2026 
requirement for a Last Call for standards-track documents, 
nothing else does either.  The simple ability to convince the 
RFC Editor to publish an informational or experimental document 
was not intended to be sufficient, even with IESG agreement that 
the document wasn't likely to be severely harmful.

> 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.
>
> I don't know what can be done a this point to change the
> terminology in 2434. It's been in use for some 4 years now...

I don't see that there is a problem.  Especially to the extent 
that you can argue that 2434 modifies or clarifies the 
procedures that 1869 calls for, I can imagine nothing that would 
prevent revising and reissuing 2434 if you think clarification 
is needed.  Or, if it were preferred, one could modify the I-D 
IESG procedures document to "update" 2434 and specify exactly 
what the IESG does in those situations going forward.

IMnvHO, ambiguous procedures documents that confuse the readers 
and the community, and that then encourage or require IESG to 
make ad hoc decisions about how to interpret them, get us into 
far more trouble than issuing RFC-quality clarifications or 
replacements.  Even when the older documents have been around 
much longer than four years.

regards,
   john

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 30 Jan 2003 09:35:26 -0500

On Wednesday, Jan 29, 2003, at 20:20 America/Montreal, Thomas Narten 
> in 2434. It's been in use for some 4 years now...

It would seem quite simple for you to take the text of RFC-2434,
edit the text appropriately to pick a more clear and accurate
term, then run it past the community for BCP.

If you think that process is too heavyweight to fix this, then that
would be an existence-proof that even IESG members believe the IETF
processes have become too cumbersome.

Please do fix.

Ran
[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Thu, 30 Jan 2003 10:22:44 -0500

> term, then run it past the community for BCP.

Sure, this is easy. The harder part is that there are many many RFCs
that use the "IETF Consensus" terminology in their IANA considerations
(e.g., the documents that sparked the original thread). I suspect that
the confusion will remain as long as folks read those RFCs and just
assume they know what the term is supposed to mean. But I agree it
makes sense to update the document for future usage.

Thomas

---

From: Randy Bush <[email-masked]>
Date: Thu, 30 Jan 2003 16:29:15 +0100

> that use the "IETF Consensus" terminology in their IANA considerations

and they meant the current 2434 definition

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jan 2003 10:31:07 -0500

> term, then run it past the community for BCP.

well, the phrase "IETF Consensus" would still be embedded in several 
other documents.  are you claiming that it's simple to update these
also?

---

From: Scott Bradner <[email-masked]>
Date: Thu, 30 Jan 2003 10:34:05 -0500 (EST)

> and they meant the current 2434 definition

or they misread 2434 (or did not read 2434) and thought they knew 
what "IETF consensus" means

Scott

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jan 2003 10:54:31 -0500

> what "IETF consensus" means

which means that it's not simply a matter of revising text, but
of asking again what was intended, and perhaps reopening the debate.

so perhaps we should assume that they meant what was written in 2434
unless we have a good reason to believe otherwise.

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Jan 2003 15:04:12 -0500

--On Thursday, 30 January, 2003 16:29 +0100 Randy Bush 
<[email-masked]> wrote:

>>> It would seem quite simple for you to take the text of
>>> RFC-2434, edit the text appropriately to pick a more clear
>>> and accurate term, then run it past the community for BCP.
>> Sure, this is easy. The harder part is that there are many
>> many RFCs that use the "IETF Consensus" terminology in their
>> IANA considerations
>

Except, perhaps, for the documents that were written before 2434 
with a rather specific definition --discussed with the IESG at 
the time-- in mind.  If 2434 modifies them, then 2434 can be 
updated and the update can update all of the earlier documents 
as well.   If 2434 doesn't modify them, then we are, for better 
or worse, back into the situation we were in with 2119 -- 
documents could either use it or could not refer to it but, 
instead, make up their own defintions.

The fact that there has been significant traffic on this 
probably justifies an update / clarification.  For the record, I 
don't care what that clarification is although:

	* I think pushing all of these things toward standards
	track would be a mistake.
	
	* I think that an intermediate position between
	"standards track document" and "RFC publication" is a
	desirable thing to have, when the WG's position is
	really that some determination of consensus and
	reasonableness by the IETF (not just by IANA) is
	desirable.

  john

---

From: Thomas Narten <[email-masked]>
Date: Thu, 30 Jan 2003 15:45:13 -0500

John,

> words, "a document that gets published as an RFC").

Agreed, now that I have gone and looked at RFC 1869. Some relevant
wording from 1869 would seem to be:

   Any keyword values presented in the EHLO response that do not begin
   with "X" must correspond to a standard, standards-track, or IESG-
   approved experimental SMTP service extension registered with IANA.  A
   conforming server must not offer non "X" prefixed keyword values that
   are not described in a registered extension.

By my read, it would seem that informational documents can't be used
to assign such code points.
   
> While, clearly, "standards track" was not intended, we did intend
> that the IESG make a formal decision that the request was consistent
> with community consensus (as well as having a published document).
> We didn't specify what steps the IESG would go through in reaching
> that conclusion, but, other than the 2026 requirement for a Last
> Call for standards-track documents, nothing else does either.  The
> simple ability to convince the RFC Editor to publish an
> informational or experimental document was not intended to be
> sufficient, even with IESG agreement that the document wasn't likely
> to be severely harmful.

I should clarify a bit, as I also agree that just convincing the RFC
editor to publish is not good enough. When the IESG reviews non-WG
documents, ADs always have the chance to review them to see if there
is some reason to comment or otherwise hold up publication. In the
case of something like an SMTP extension, I can't imagine that the
document would get approved without a relevant AD first consulting
with some mail knowledgable folk first. The details of how that are
done are not written down, but in practice broken proposals would not
get approval without some discussion first.

In practice, "IETF Consensus" (as defined in 2434) means that
procedurally the IESG has to sign off on a document before IANA
assigns code points for it. And for something that relates to an
existing IETF protocol, we almost always check with some knowledgable
folk as to whether the document conflicts with that protocol or
otherwise is problematical before approving. So, I suspect that in
fact, the review you are saying is supposed to be happening would
happen in practice in this case (and in other similar cases).

> is needed.

I don't claim 2434 updates 1869; in fact, I'd argue otherwise. 1869
was cited as a specific example, but you've pointed out that it is an
incorrect example.

> Or, if it were preferred, one could modify the I-D 

I think the wording in 2434 is quite clear. When someone says "IETF
Consensus, as defined in [RFC 2434]" (which is the type of language I
like to see in documents because it is VERY clear), IANA doesn't
assign code points until the document is approved for publication as
an RFC. As the IESG approval is one of those steps, IESG has a chance
to review.  If folks actually want a different criteria, there are a
number of other choices to choose from in 2434, or they could write a
very specific one (subject to it being something IANA can actually
deal with).

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 30 Jan 2003 15:53:07 -0500

John,

> as well.

RFC 2434 doesn't update any IANA instructions that exist in RFCs that
predate 2434 - I'd encourage folk to go and read the document... I'd
like to think it's a useful read :-)

> If 2434 doesn't modify them, then we are, for better 

That has always been and continues to be an option.  But for the
majority of documents, chosing from a menu of well-defined choices
seems to be simpler for everyone. IANA also has to be able to
understand what needs to happen, for instance, and the burden on IANA
shouldn't be excessive either. Sticking to well-known definitions when
possible seems to help here.

> 	track would be a mistake.

I agree. That is why there are categories like "expert review", or
"First Come First Served"

> 	reasonableness by the IETF (not just by IANA) is

The menu choice out of 2434 that I suggest to people for the above is
"Expert Review".

Thomas

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Jan 2003 16:32:41 -0500

--On Thursday, 30 January, 2003 15:45 -0500 Thomas Narten 
<[email-masked]> wrote:

> John,
>
>> Thomas, not to be splitting hairs, but the intent --at least
>> in  SMTP-EXT (STD10/RFC1869), which was cited as an example--
>> was  somewhat more than simple publication as an RFC (or, in
>> your  words, "a document that gets published as an RFC").
>
> Agreed, now that I have gone and looked at RFC 1869. Some
> relevant wording from 1869 would seem to be:
>
>    Any keyword values presented in the EHLO response that do
> not begin    with "X" must correspond to a standard,
> standards-track, or IESG-    approved experimental SMTP
> service extension registered with IANA.  A    conforming
> server must not offer non "X" prefixed keyword values that
> By my read, it would seem that informational documents can't
> be used to assign such code points.

That was the conclusion of the WG.  I don't exactly remember the 
reasoning, but it might have had something to do with a 
conviction that we wanted the barrier to be fairly high and 
serious and that even Experimental was an escape clause.

>> While, clearly, "standards track" was not intended, we did
>> intend that the IESG make a formal decision that the request
>> was consistent with community consensus (as well as having a
>> published document). We didn't specify what steps the IESG
>> would go through in reaching that conclusion, but, other than
>> the 2026 requirement for a Last Call for standards-track
>> documents, nothing else does either.  The simple ability to
>> convince the RFC Editor to publish an informational or
>> experimental document was not intended to be sufficient, even
>> with IESG agreement that the document wasn't likely to be
>> severely harmful.
>
> I should clarify a bit, as I also agree that just convincing
> the RFC editor to publish is not good enough. When the IESG
> reviews non-WG documents, ADs always have the chance to review
> them to see if there is some reason to comment or otherwise
> hold up publication. In the case of something like an SMTP
> extension, I can't imagine that the document would get
> approved without a relevant AD first consulting with some mail
> knowledgable folk first. The details of how that are done are
> not written down, but in practice broken proposals would not

Yes, but part of the discussion in Atlanta and on the 
problem-statement list is whether the type of review you are 
describing is an abuse of IESG authority and discretion. 
RFC2026, at least as I read it, permits IESG to hold up an 
informational or experimental document that was submitted to the 
RFC Editor _only_ to prevent or annotate end-runs and things 
that would be harmful to the infrastructure.  "Not harmful" is a 
much lower threshold than "IETF Consensus".   So, if you expect 
IESG review to "hold up" anything that does not originate from 
within the IETF, or to comment on any such documents, you had 
best seek a procedural authorization for doing so.  I can't 
speak for the community, but my impression is that tolerance for 
IESG "holding things up" --and I am astonished that you are 
willing to use those words-- is rapidly diminishing.

> assigns code points for it. And for something that relates to
> an existing IETF protocol, we almost always check with some
> knowledgable folk as to whether the document conflicts with
> that protocol or otherwise is problematical before approving.
> So, I suspect that in fact, the review you are saying is
> supposed to be happening would happen in practice in this case
> (and in other similar cases).

Yes, but see above.

>> > 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.
>> >
>> I don't see that there is a problem.  Especially to the
>> extent  that you can argue that 2434 modifies or clarifies
>> the  procedures that 1869 calls for, I can imagine nothing
>> that would  prevent revising and reissuing 2434 if you think
>> clarification  is needed.
>
> I don't claim 2434 updates 1869; in fact, I'd argue otherwise.
> 1869 was cited as a specific example, but you've pointed out
> that it is an incorrect example.

Ok.  Then we need to add to the oral tradition that, if a WG 
wants serious review, they should not use the term "IETF 
Consensus", but should replicate the 1869 text, with or without 
inclusion of informational documents as they think appropriate.

> I think the wording in 2434 is quite clear. When someone says
> "IETF Consensus, as defined in [RFC 2434]" (which is the type
> of language I like to see in documents because it is VERY
> clear), IANA doesn't assign code points until the document is
> approved for publication as an RFC. As the IESG approval is
> one of those steps, IESG has a chance to review.  If folks
> actually want a different criteria, there are a number of
> other choices to choose from in 2434, or they could write a
> very specific one (subject to it being something IANA can
> actually deal with).

Ok, modulo the observations above.

   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Jan 2003 16:39:12 -0500

--On Thursday, 30 January, 2003 15:53 -0500 Thomas Narten 
<[email-masked]> wrote:

> That has always been and continues to be an option.  But for
> the majority of documents, chosing from a menu of well-defined
> choices seems to be simpler for everyone. IANA also has to be
> able to understand what needs to happen, for instance, and the
> burden on IANA shouldn't be excessive either. Sticking to
> well-known definitions when possible seems to help here.

Absolutely.  Otherwise, this discussion wouldn't be worth the 
trouble.  But, if you are going to define "IETF Consensus" as 
"Publication as an RFC" then

	- We don't need the added term to add confusion.
	
	- We open up a loophole case in which a document comes
	to the RFC Editor, then to the IESG.  The IESG decides
	it is a bad idea, and puts a disclaimer on it that says
	"this is a terrible idea".  The RFC Editor decides to
	publish it anyway.  We now have an RFC that, regardless
	of its other properties, clearly does not represent IESG
	consensus that it is a good idea.  But whatever it calls
	for is eligible for registration.

>> probably justifies an update / clarification.  For the
>> record, I  don't care what that clarification is although:
>
> I agree. That is why there are categories like "expert
> review", or "First Come First Served"

But the "expert review" is, in my experience in most cases, a 
sanity check by one person, not the judgement of the community 
that something is appropriate.  So it responds to one of the 
possible cases, but not the others.

> The menu choice out of 2434 that I suggest to people for the
> above is "Expert Review".

See above.

    john

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 30 Jan 2003 17:51:36 -0800 (PST)

Hi Thomas,

On Thu, 30 Jan 2003, Thomas Narten wrote:

> assigns code points for it.

RFC 2434 has (among others) these two definitions:

      IESG Approval - New assignments must be approved by the IESG, but
           there is no requirement that the request be documented in an
           RFC (...)

      IETF Consensus - New values are assigned through the IETF
           consensus process. Specifically, new assignments are made via
           RFCs approved by the IESG.  (...)

I understand the first: it's completely within the IESG, and no RFC is
required.

For the latter, clearly IESG approval and an RFC are necessary.  And
your note above seems to indicate that these are sufficient.  In that
case, what does the phrase "through the IETF consensus process" mean?

And, if your note is correct, why was an IETF-wide Last Call issued?
Finally, why, when there was an active debate with no consensus (IMHO),
was the document summarily approved?

If the IESG saw rough consensus in the debate, that would be useful
information.  If on the other hand the IESG issued the Last Call as a
formality, that would be useful to know as well.

> an RFC.

Perhaps "IETF Consensus" being defined to mean "an RFC with IESG
approval" is clear to you.  For my part, I see neither 'IETF' nor
'consensus' in "an RFC with IESG approval".  If the category were
called "IESG Approval documented in an RFC", I wouldn't be having
this discussion.

Kireeti.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 31 Jan 2003 16:06:42 -0500

> "Publication as an RFC" then

Since I don't seem to be able to make this clear enough, once again, I
do not and have never intended "IETF Consensus", in the literal sense,
to be defined as "Publication as an RFC". We all know that the two are
not the same. That term was used as a shorthand way in RFC 2434 to
indicate RFC publication was required.

If I could go back in time, I would leave the defintion as it is, but
give it a different name. I probably wouldn't have tried to define
"IETF Consensus" at all, as I'm not sure how that would be done in a
way that encompasses both standards track and non-standards track
documents (or that such a definition would even be useful).

> 	for is eligible for registration.

What this points out is that the relationship between IESG review,
IANA assignments and RFC editor independence is both complex and
subtle. Not suprisingly, it has evolved over time in a way that no
longer matches the exact words in (say) 2026. A literal intepretation
of some of these words could easily lead us into situations that we
probably don't want to be in.  I agree that it would be good to
clarify and update the written words.

Thomas