Sam Hartman <hartmans-ietf@xxxxxxx> wrote: > Scott O Bradner <sob@xxxxxxxxxxx> 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@xxxxxxx> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf