Re: "Discuss" criteria

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave asked a series of pointed questions about the discuss criteria document.

First and foremost, I want to point out that this draft, in whatever form it is, represents a good thing. The IESG is making an effort to tell the community what it is doing, and to listen to the comments it gets.

As a practical matter, the IESG needs the freedom to change these policies if they turn out to have problems. It would be really bad if the policy had a problem, but they could not work around it for the months it took to get a new RFC out.

Now, I want to point out a basic a disagreement I have with the perspective Dave suggests, below the extract from his comments.

At 11:44 AM 12/29/2006, Dave Crocker wrote:
* The specification is impossible to implement due to technical or clarity issues.

When this assertion is made, is it sufficient to cite existing implementations
based on the current version of the specification? Is the AD at least required to explain the assertion in detail?


* The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity.

Will demonstrations of interoperability be sufficient to counter this claim?


* It is unlikely that multiple implementations of the specification would interoperate, usually due to vagueness or incomplete specification.

Will demonstrations of interoperability be sufficient to counter this claim?

I think in all of these cases, the question is the wrong question, and the answer is no, an implementation (or event three implementations) does not answer the concern. We have had several documents in different areas where the documents were severely under-specified. There were implementations. They were from folks who were involved in the working group discussion, and so knew all the unstated assumptions. They tested against each other until they got it working. That set of implementations did not prove that the spec was implementatable, clear, or particularly good.

We ostensibly choose the IESG members for technical skill, and we ostensibly ask them to apply technical judgement. Refusing to pay attention to such judgement is a recipe for more under-specified (or broken in other ways) specifications.

Yes, the IESG members objecting should be as specific as they can be.
However, I will note that I have reviewed documents where all I could say at the end was "I can't make head or tail of this." And it wasn't some obscure, complicated technical document. There have also been documents where my personal reaction was that the documents needed to be re-written from scratch by someone who spoke English (First second, or third language, but English.) They were simply too badly written to tell if they were accurate.


Yours,
Joel M. Halpern


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]