On 5/15/2013 7:55 AM, Ted Lemon wrote:
On May 15, 2013, at 10:41 AM, Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
The motivation for a particular feature of a protocol is not
clearenough. At the IESG review stage, protocols should not be blocked
because they provide capabilities beyond what seems necessary to acquit
their responsibilities.
I strongly disagree with what the NON-DISCUSS criteria say.
DISCUSS isn't just for blocking documents. And document quality is
as important (in the sense that poor document quality can lead to
as many interoperability or other problems) as technical
correctness.
The interpretation of this particular NON-DISCUSS criterion that Joe
has given is simply wrong. The key word to pay attention to to see the
error is "motivation." The point of this criterion is to eliminate a
very specific sort of stall that has been known to happen in the past:
the stall where the AD doesn't understand why the document is being put
forward at all, and therefore blocks the document until the authors
explain the motivation behind the document to the satisfaction of the AD
who is holding the DISCUSS.
I'm impressed that you have such a specific interpretation that this
criteria refers to the entire document, even when it talks about the
"feature of a protocol".
So now we're supposed to accept your interpretation of this rather than
the explicit text?
This is a real issue that has created real problems in the past, and
that is why it is in the NON-DISCUSS criteria. But this criterion
_does not_ mean that a criticism that the document itself is unclear
is not a valid reason to hold a DISCUSS on it.
Agreed - this does not refer to the document. It refers to a specific
feature of a protocol.
In fact, it's an
excellent reason to hold a DISCUSS on it. A lack of clarity in a
document can result in it being implemented incorrectly, or in the
case of a BCP, interpreted incorrectly.
I agree that THESE are good reasons for a DISCUSS, but simply not being
clear is NOT.
Or in extreme cases, not
read at all.
There's nothing you can do about that; RFCs are not read all the time.
Joe