Subject: What review is required for "IETF Consensus"?

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 02 Feb 2003 10:30:09 -0800

Thread B from my previous message..... this is being CCed to the POISED 
list, for reasons that may be obvious after reading the message; for POISED 
subscribers - this is followup to an IETF list thread.

Question:

What review process must the IESG take before taking the action to block or 
allow publication of such an internet-draft (ie "what does IETF Consensus 
mean")?

This is not written in RFC 2434.
Some tactics that have been used in the past to gather information for the 
IESG's decision include:

- "It's obviously OK". Approved WG document, or competently written 
documentation from subject matter experts, reviewed by people with 
competence on the specific registry. The IESG looks at it and thinks that 
it's obvioiusly right. Example: application/ogg, documented in 
draft-walleij-ogg-mediatype.

- Subject matter expert group review. For instance, posting to the DHC WG 
asking for opinions on a DHCP extension. WG chairs' feedback will carry a 
lot of weight.

- IETF Last Call for Informational/Experimental, with the IESG evaluating 
the feedback.

In all cases, the IESG has to evaluate; there's no other established body 
to do it. "The buck stops here".

Among the cases to consider:

- Everyone approves. Go for it.

- Nobody cares. No comments; the IESG will usually decide that nobody saw 
any looming danger to the Internet, and allow the registration.

- Serious objections. The comments clearly indicate that the registration 
would be harmful to the Internet (and how), and the IESG agrees with that 
evaluation. The IESG will refuse.

- Incompetent or incomplete document. The IESG will usually object to this 
on its own - without documentation clear enough to determine whether this 
is OK or harmful, it would be remiss of the IESG to let the document go 
forward even to an IETF Last Call.
We can't claim IETF consensus on something we can't understand.

- Dissension within the IETF. Like in the case of a WG, the IESG has to 
evaluate the arguments on their merits; obviously the proposers think that 
the registration should be allowed, and opposition without a rational basis 
should no more be allowed to block this registration than it should be 
allowed to block WG progress. But as the saying goes - "this is why you get 
the big bucks".
Among the things to consider here is that the determination must be made in 
a timely fashion - sometimes there are reasons why letting debate rage for 
another 6 months doesn't seem like an attractive option.

Questions for the audience:

- should this description, or something like it, go into 
draft-iesg-procedures?
- are there guidelines that the IESG should use when trying to determine 
the right outcome in the "dissension" case?
- does this debate belong on the POISED list, together with the discussion 
of the IESG charter and the IESG procedures?

Thoughts?

                 Harald

---

From: Jeff Williams <[email-masked]>
Date: Sun, 02 Feb 2003 21:27:05 -0800

Harald and all,

  I "Guess" that a IETF consensus really means whatever you Harald
says it means much like what consensus meant while you were
Chair of the DNSO GA.  But to be honest, no consensus can be
determined unless it is measured, which means a VOTE must be
held amongst IETF participants.  Perish the thought, eh Harald?!  >;)

> of the IESG charter and the IESG procedures?

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!)
================================================================
CEO/DIR. Internet Network Eng. SR. Eng. Network data security
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number: 214-244-4827 or 214-244-3801

---

From: John Leslie <[email-masked]>
Date: Mon, 3 Feb 2003 04:35:51 -0500

I must admit to some confusion about what Harald is asking for.

   The context here is discussion of RFC 2434 "Guidelines for Writing
an IANA Considerations Section" (BCP 26). We're discussing "example"
policies for IANA assignments. Specifically there is:

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

which requires publication of an RFC, and

" IESG Approval - New assignments must be approved by the IESG, but
" there is no requirement that the request be documented in an RFC
" (though the IESG has discretion to request documents or other
" supporting materials on a case-by-case basis).

   I think Harald is asking for comments on this.

> This is not written in RFC 2434.

   I read this section of RFC 2434 as an escape hatch, not as a regular
process.

   Before I can intelligently discuss the "process" for "IESG Approval",
I need some justification of why this option is used at all. It strikes
me as decidedly unwise to make a permanent IANA assignment based upon
an Internet Draft (which by definition expires in six months).

> draft-walleij-ogg-mediatype.

   Well, immediately we are struck with the question, _which_
draft-walleij-ogg-mediatype. I believe draft-walleij-ogg-mediatype.08
is current.

   Granted, I have no reason to believe the IANA assignment has
changed or will change; and the actual registration is minimal:

" To: [email-masked]
" Subject: Registration of MIME media type application/ogg
" MIME media type name: application
" MIME subtype name: ogg
" Required parameters: none
" Optional parameters: none
" Encoding Considerations: ...
" Security Considerations: ...
" Interoperability considerations: ..
" Published specification: See [1]

where [1] is:

" [1]  Pfeiffer, S., "The Ogg encapsulation format version 0",
"      Internet-Draft XXXX, November 2002.

   There's the problem: We've got an unquestionably useful format
depending on a document which will expire in May. IMHO, this richly
deserves an RFC (which doesn't expire).

> asking for opinions on a DHCP extension. WG chairs' feedback will carry a 

   This is a limited case, where the appropriate WG is still active.
Clearly the WG Chair is the appropriate judge of WG consensus. But the
documentation is always in danger of being too sparse...

> - IETF Last Call for Informational/Experimental, with the IESG evaluating 

   Isn't that an RFC?

> any looming danger to the Internet, and allow the registration.

   So long as there's no imminent danger of exhaustion of the name space,
and the documentation is adequate, I agree.

> We can't claim IETF consensus on something we can't understand.

   Technically, we're not talking about "IETF consensus" ...

   However, "IESG Approval" certainly _should_ imply that the IESG
_understands_ the registration request.

> evaluate the arguments on their merits; obviously the proposers think
> that the registration should be allowed, and opposition without a
> rational basis should no more be allowed to block this registration
> than it should be allowed to block WG progress. But as the saying goes
> - "this is why you get the big bucks".

   Did I miss the part where your salary was increased?

> Among the things to consider here is that the determination must be made
> in a timely fashion - sometimes there are reasons why letting debate
> rage for another 6 months doesn't seem like an attractive option.

   So often, when "time is of the essence", it means that the person(s)
preparing the request _chose_ not to allow sufficient time. This sort
of behavior should NOT be rewarded.

   That said, "letting debate rage for another 6 months" isn't the
right solution either. Clearly defining the issue to be resolved is
the best policy, followed by careful reading (and possible feedback)
of the documentation which ensues.

> - should this description, or something like it, go into 

   I'm not convinced. I still think we're talking about an escape hatch,
not the "normal" process.

> the right outcome in the "dissension" case?

   Minimize your work!
   Demand clear documentation.

> of the IESG charter and the IESG procedures?

   Seems reasonable to me...

--
John Leslie <[email-masked]>

---

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

> 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

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

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

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

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 10 Feb 2003 10:02:24 -0500

> clarify and update the written words.

ASIDE:

An operational bug at present is that while the RFCs clearly state
that the IAB is responsible for the RFC-Editor relationship, the
actual practice is largely that IESG (and NOT IAB) is providing
direction to the RFC-Editor (even on matters not involving the
output of IETF WGs nor involving standards-track publication).

I think that this is a significant problem that does need to be fixed.
The two most obvious forms of fix are to re-align the practice to
match the RFC language or to revise the RFC language to match the
actual practice.  Other solutions probably also exist.  I don't
claim to know what the right fix is.

This discrepancy really IS a problem and one way or another needs
to be fixed.

It is NOT just an IETF issue, so IETF can't solve it unilaterally.
IRTF, IAB, and other ISoc-umbrella groups that do NOT report to IESG
nor report directly to the IETF also use (and need to continue to use)
the RFC-Editor to publish documents.

My personal preference would be that this bug get sorted out with
full input from the broader IETF community, IRTF community, and "other
folks who publish RFCs" community [1], rather than being worked
out behind closed doors.

Ran
[email-masked]

[1] Those communities each overlap, but they are NOT identical in 
practice.