(Wearing my Narrative-Scribe hat) 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. Second, I think the Narrative Minutes will help considerably in understanding this situation. They will likely be published July 5 or 6. Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > > It's problematic, and I believe inappropriate, to consider WG consensus > as contributing to community consensus. I agree -- however, this was not a call for community consensus. (Possibly it should have been. At the same IESG telechat, there was a Statement on moving an RFC to Historic Status, which perhaps should cover cases like this.) > The two questions need to be considered separately, for two reasons: > > 1. Working groups often have strong biases and aren't representative > of the whole community. Put another way, a working group often > represents only one side of a tussle, and working groups are often > deliberately chartered in such a way as to minimize the potential > for conflict within the group. Nonetheless, WGs are open to all. When a WG document comes before the IESG, there are several Directorate reviews and an IETF-wide Last-Call. These exist to give guidance to the IESG on whether to send the document back to the WG with comments on how to improve it. If it is sent back, the WG must deal with anyone who may join that WG to express opinions on those comments. IESG members dislike sending documents back to the WG, because it is perceived (by WG members) as "micro-management" or whatever nasty term may come to mind. Generally, IESG members choose to avoid this when they don't believe the WG consensus will change. > So when evaluating standards actions for the whole community, the > consensus within a working group means little. I don't agree. The WG is where concerns are supposed to be balanced. The <ietf@xxxxxxxx> list cannot handle the bandwidth of doing this. > In this particular case, v6ops heavily represents the interests of > operators (who are naturally interested in having IPv6 run smoothly > in the long term) and works against the interests of applications > developers (who are naturally interested in having transition > mechanisms that allow them to ship code that uses IPv6 and an > IPv6 programming model regardless of whether the underlying network > supports it). True. > 2. Working groups have spent a lot of time working on a document and > will have several members actively participating. By contrast, most > of the wider community will not have these issues "on their radar" > until they come up for IETF-wide Last Call. Also, busy people need > to find time to review a document before making comments, and this > may require multiple readings. True. > So it's hardly surprising if the number of IETF-wide Last Call > comments is smaller than the number of WG Last Call comments. > Consensus needs to be evaluated separately in the WG and the IETF > because the populations and sample sizes are different. I'm not sure I agree that IETF-wide consensus needs to be evaluated at all. The model of IETF is that work is normally done in WGs, and that an IETF-wide review is done before publishing an RFC. In this particular case, we have an Informational-status RFC intended to declare a Standards-Track RFC to no longer be an Internet Standard in any sense. It is arguable that such an action _should_ require IETF-wide consensus; but at the moment there is no procedure requiring it. So, Keith, you must first convince us that an action like this _does_ require IETF-wide consensus. -- John Leslie <john@xxxxxxx> _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf