On Jun 24, 2011, at 8:55 AM, John Leslie wrote: > (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.) Well, there was also a process issue because a standards action (changing 6to4 to historic) was advertised as a proposal to publish an informational document. But I read 2026 as requiring broad community consensus for standards actions. >> 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. I served on IESG for four years, and understand all of that. Nevertheless, even a strong consensus of a WG should never be taken as consensus of the IETF as a whole. Working groups are almost inevitably narrowly focused, and in practice they rarely consider the wider effects of their actions. And in this particular case, I don't think there was even rough consensus within the v6ops working group. Moreover, while it is always necessary to get rough consensus from the broad community on any standards action, WG consensus is not a necessary condition. Individual submissions for standards-track can be approved with a 4-week Last Call. The value of a narrowly-focused working group is not so much to gain consensus of that group (though this can be useful), but to encourage an appropriate amount of attention on protocol design. Clearly the broad community consensus is more important than the working group's consensus. A working group should understand that its job is to put forth a proposal that will win consensus of the broad community. >> 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. Working groups that are narrowly focused (which is to say the vast majority of them) cannot possibly balance the competing concerns of the broad community. They are too subject to the dictates of a single "area". And schedule conflicts at IETF meetings also discourage cross-area participation. > I'm not sure I agree that IETF-wide consensus needs to be evaluated > at all. RFC 2026 states over and over again, in several different ways, that the goal of the process is to achieve broad community consensus. Keith _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf