Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu> wrote:
Scott O Bradner <sob(_at_)harvard(_dot_)edu> writes:
* 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?
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."
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 <john(_at_)jlc(_dot_)net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf