--On fredag, juli 01, 2005 19:20:37 +0700 Robert Elz <kre(_at_)munnari(_dot_)OZ(_dot_)AU>
wrote:
Date: Fri, 01 Jul 2005 12:26:31 +0200
From: Harald Tveit Alvestrand <harald(_at_)alvestrand(_dot_)no>
Message-ID: <B0E3C978F498DC96D6CED4DA(_at_)B50854F0A9192E8EC6CDA126>
| So we've got two possible interpretations:
|
| - The authors and the community that let this be published thought
that | there were some cases where the IESG could make a decision
without | consulting the community. Presumably this included "no"
decisions. |
| - The authors and the community did not understand that there was a
| difference between "IESG Approval" and "IETF Consensus".
|
| I trust the competence of these authors, so I think the first
decision is a | reasonable one.
I agree with every word of that.
The question is, upon what basis should the IESG make the yes/no decision.
Some apparently believe (and I suspect that most or many of the IESG,
and recent past IESGs are included) that it means "for whatever reason
the IESG concludes is appropriate".
I do not agree. To me, everything in 2434 is talking about what level
of documentation should be required to register a parameter (code point,
whatever you want to call it) via the IANA. The "IESG approval"
section contains nothing to suggest it should be different. To the
contrary, it expressly says that no RFC (ie: one documentation
possiblilty) is required, but that the IESG can request more
documentation if it feels it necessary. Everything is about
documentation.
Documentation is the subject to be judged, and should be the sole
basis for the yes/no decision.
If you agree with that, then we are in total agreement, and I'd suggest
that you should have yourself moved from the "satisfied" to the
"dissatisfied" column in Ken Carlberg's list.
I don't agree, which is no surprise.
RFC 2434 also says (section 2):
One way to insure community review of prospective assignments is to
have the requester submit a document for publication as an RFC. Such
an action insures that the IESG and relevant WGs review the
assignment. This is the preferred way of insuring review, and is
particularly important if any potential interoperability issues can
arise. For example, many assignments are not just assignments, but
also involve an element of protocol specification. A new option may
define fields that need to be parsed and acted on, which (if
specified poorly) may not fit cleanly with the architecture of other
options or the base protocols on which they are built.
That's technical review, not just documentation review.
Like you, I don't think the issue itself is important enough to waste this
many cycles on. Whether the IESG did a competent technical review or not is
beside the question - they make mistakes, like any other body.
The important part is that when they are asked to review something, we
SHOULD expect them to make technical judgments. And that's how I think it
should stay.
Harald
PS: Going on holiday in 14 hours. So this may be the last I say on the
subject.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf