ietf
[Top] [All Lists]

Re: Why ask for IETF Consensus on a WG document?

2011-06-24 07:56:26
   (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.)

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(_at_)ietf(_dot_)org> 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(_at_)jlc(_dot_)net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf