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(_at_)network-heretics(_dot_)com> 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(_at_)ietf(_dot_)org> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf