Russ Housley wrote:
As you said in your note, we disagree on the details. I have forwarded
the text to the list that shows that the issue was raised during IETF
Last Call. Meaning, it was not a late surprise.
First, there is a difference between a reviewer's making an observation, versus
an Area Director's imposing it as a requirement. The latter is the issue in the
Second, even the reviewer said they didn't care about it. So it is not merely a
possibility of having missed the reviwer's comment; it is that the reviewer
explicity removed any need for concern about their observation.
I agree that the community should not have to watch IESG decisions to
infer trends. In this case, the ID Checklist already includes a SHOULD
statement. It could be more clear. More about that below.
I'll ask again: When did ID-Nits become an authoritative source, rather than a
summary of other sources?
And if it does indeed represent the sole venue for imposing some requirements,
by what approval process did these individual items get reviewed and approved?
This should be particularly explained with respect to the specific rule that you
are using as the basis for blocking the document.
And lastly, what has emerged from this exchange is a rather explicit
clarification that the IETF really has a two-state requirements model.
The first set of requirements is based on community consensus and the second on
IESG consensus, with the latter overriding whatever might be set by the first,
in terms of form, style or content.
This is, after all, the real implication of a framework which leaves the IESG
free to impose whatever judgment it wishes either in requirements documents it
issues without community approval, or Discuss vetoes it sustains.
To the extent that this summary of the IETF authority model is incorrect, how?
To the extent that it is correct, is this really what the community wants?
IETF mailing list