Subject: Re: "Discuss" criteria

From: [email-masked] (Scott O. Bradner)
Date: Fri, 29 Dec 2006 18:10:01 -0500 (EST)

to follow up on Dave's note

> * The IETF as a whole does not have consensus on the technical
>   approach or document. There are cases where individual working 
>   groups or areas have forged rough consensus around a technical 
>   approach which does not garner IETF consensus. An AD may DISCUSS 
>   a document where she or he believes this to be the case. While 
>   the Area Director should describe the technical area where
>   consensus is flawed, the focus of the DISCUSS and its resolution 
>   should be on how to forge a cross-IETF consensus.

what actual evidence must an AD present to indicate that the
assertion of non-consensus is anywhere but in the one AD's mind?

Scott

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Sat, 30 Dec 2006 00:19:34 -0500

>>>>> "Scott" == Scott O Bradner <[email-masked]> writes:

    Scott> to follow up on Dave's note

    >> approach which does not garner IETF consensus. An AD may
    >> DISCUSS a document where she or he believes this to be the
    >> case. While the Area Director should describe the technical
    >> area where consensus is flawed, the focus of the DISCUSS and
    >> its resolution should be on how to forge a cross-IETF
    >> consensus.

    Scott> what actual evidence must an AD present to indicate that
    Scott> the assertion of non-consensus is anywhere but in the one
    Scott> AD's mind?

None.  But the AD must be willing to propose a procedure that the rest
of the IESG can go along with to determine whether there is in fact a
lack of consensus or wether the AD is wrong.  This style of discuss is
much more of a "Hold on here, let's work together to check consensus,"
than a "I'm blocking this document for ever."  

David used this style of discuss recently to show us that we did not
have consensus behind Brian's mailing list document.  He presented
very little evidence (I think none but don't want to go back and look
at the record) but it was easy for me as shepherd to work with David
to agree on a procedure for checking consensus.  David was right in
that instance.

I came very close to filing a similar discuss with
draft-ietf-grow-anycastbut ended up filing a strong abstain instead.

If there are people on the IESG who you don't trust with the ability
to say "Hey, I think we have a problem here.  Let's take the time to
find out," then please work to remove them.  That is true even if I'me
one of the people you believe needs to go.  Asking the IESG to do its
job without giving the members this power is giving responsibility
without the necessary power.  I'm not interested in that job, I doubt
others are either.

---

From: John Leslie <[email-masked]>
Date: Sat, 30 Dec 2006 16:32:49 -0500

Sam Hartman <[email-masked]> wrote:
> Scott O Bradner <[email-masked]> writes:
> 
> what actual evidence must an AD present to indicate that
> the assertion of non-consensus is anywhere but in the one
> AD's mind?
> 

   This is venturing into dangerous territory. The best expertise on
the technical issues involved _should_ be in the WG that produced the
document. Expecting to find _better_ expertise within the IESG seems
less than rational...
 
> David [Kessens] used this style of discuss recently to show us that
> we did not have consensus behind Brian's mailing list document.
> He presented very little evidence (I think none but don't want to go
> back and look at the record) but it was easy for me as shepherd to
> work with David to agree on a procedure for checking consensus.

   Ouch! I should have seen that coming. :^(

   It certainly can be argued that for a BCP, actual IETF consensus
is necessary. By extension, certain changes to a BCP should show
actual IETF consensus. In this case there was a belief that such
changes (to BCP83) were proposed.

   This is _not_ the general case. For the general case, I must agree
with Dave Crocker:
] 
] This is perhaps the scariest of the criteria.  It says that a
] knowledgeable, motivated constituency can spend months on solving a
] problem that it needs to have solved, and then others who have not
] participated in the work can come along and sabotage it.

   Actual IETF consensus (not just the lack of adverse comments during
Last-Call) is very hard to achieve. Requiring it for ordinary WG work
is non-scalable. (We can't reasonably expect to accomplish it more
than perhaps a half-dozen times a year.)

   This DISCUSS criteria (alleging lack of IETF-wide consensus), as
written, allows any AD (hopefully not the one shepherding it!) to
effectively block the work of a WG. Sam's "solution" amounts to
negotiation among non-players over _how_ to judge the prejudices of
folks who mostly don't understand the issues.

   Further Sam's "solution" tends to favor re-running the Last-Call
if you don't like the results. This is a very bad practice. It
causes everyone who pays attention to believe there must be problems
below the surface; and strongly tends to produce a situation in
which consensus looks impossible (because too many issues have been
raised).

   In the normal case, any DISCUSS should go back to the WG. With
technical issues named, addressing them is workable. With a demand
for review by particular experts, there's at least a place to start.
With "So-and-so thinks somebody somewhere wouldn't like this," there's
really no place to start. :^(

   Simply re-running the Last-Call is even worse. It essentially
invites flame-wars, and encourages the moderate folk in the WG to
simply disengage. It's hard to imaagine _any_ case where it will
lead to a better document.

   Granted, it may lead to dropping a document which would actually
have caused problems. But wouldn't it have been better for all
involved to actually _state_ what those problems look to be?

--
John Leslie <[email-masked]>