On Jun 24, 2011, at 4:17 PM, John Leslie wrote: > Paul Hoffman <paul.hoffman@xxxxxxxx> wrote: >> On Jun 24, 2011, at 5:55 AM, John Leslie wrote: >> >>> First, note the Subject line: an IETF Last-Call on a Working Group >>> document _isn't_ asking for IETF Consensus: it's simply a last-call for >>> comments on an action proposed by a Working Group. >> >> I'm quite confused by this opinion. *No* IETF Last Call announcements, >> even those for standards track documents, say that they are to determine >> IETF consensus, yet IETF consensus is required for many of these >> documents. > > I cannot speak with any authority on this, but I can quote RFC 2026: > ] > ] 4.2.2 Informational > ] > ] An "Informational" specification is published for the general > ] information of the Internet community, and does not represent an > ] Internet community consensus or recommendation. > Even if the document was to be labeled as informational, this was clearly a standards action. > This seems pretty plain to me. > > As for Standards-track and BCP, I read RFC 2026 to call for "consensus > building", not "IETF consensus". YMMV. Yes, but that consensus that is called for is IETF-wide consensus. If WG consensus were all that were were required, there would be no need for an IETF-wide Last Call. And I can't tell that there's been any attempt at all by the v6ops group or the document authors to build IETF-wide consensus on this. >> In your view, how are we to know which IETF Last Call announcements >> are to determine IETF consensus > > IMHO, essentially none of them. To quote RFC 2026: > ] > ] 14. DEFINITIONS OF TERMS > ] Last-Call - A public comment period used to gage the level of > ] consensus about the reasonableness of a proposed standards action. > ] (see section 6.1.2) > > Section 6.1.2 is pretty long; I'll quote only one paragraph: > ] > ] The IESG will send notice to the IETF of the pending IESG > ] consideration of the document(s) to permit a final review by the > ] general Internet community. This "Last-Call" notification shall be > ] via electronic mail to the IETF Announce mailing list. Comments on a > ] Last-Call shall be accepted from anyone, and should be sent as > ] directed in the Last-Call announcement. > > I don't read that as requiring "IETF Consensus" to be determined: > merely that the "level of consensus" be considered -- strongly suggesting > that the IESG may approve something where the "level of consensus" falls > below "rough". (I do not intend to express any opinion whether they ever > do so.) The stated purpose of Last Call is to "gage [sic] the level of consensus". Of course, IESG does have an additional role beyond determining consensus. e.g. It may also make judgments about the document's technical quality, whether a document meets the 2026 criteria for a particular status (e.g. "no known technical omissions" for Proposed), whether appropriate processes were followed by a WG, etc. RFC 2026 does not explicitly state that community-wide consensus is required for standards action. However it makes abundantly clear that community-wide consensus is the goal of everything in the process. It also implies that lack of consensus is justification for appeal, and that the goal of the appeals process is to achieve consensus. > I have not said that. IMHO, the IESG procedures don't even attempt to > "determine IETF consensus" on the vast majority of documents. They attempt > to determine instead whether the document should be sent back for rework. In my experience, this was also true. Consensus was not an issue for most documents that I saw while on IESG; technical quality was. But it's also clear that IESG is supposed to evaluate Last Call comments to "gage" consensus. Keith _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf