--On Tuesday, 28 June, 2005 09:37 +0200 Harald Tveit Alvestrand
<harald(_at_)alvestrand(_dot_)no> wrote:
...
In fact, a simple-minded grep for "iesg approval" shows that
RFC 2048, the first MIME registration procedures, was the
first to use it, 2 years earlier; that only shows where I
cribbed the term from, I guess.
Quote from 2048:
2.3.2. IESG Approval
Media types registered in the IETF tree must be submitted
to the IESG for approval.
Yep. Ned, Jon, and I did it. I can't remember precisely who
the original guilty party was for either the term or the
concept. The multiple-tree idea in this space was, I think,
originally mine but the rules for getting into the trees was, if
I recall, very much group discussion. We did it very
deliberately, and were deliberately vague about the procedure
IESG was to use. And it was not about document completeness
review, it was about content-based approval of whether or not
the IESG liked that content. We didn't feel a need to comment
on the adequacy of documentation bit because we could not
believe IESG would sign off on something in the IETF tree that
was incompetently described and IANA was still making decisions
that would have produced pushback on such a thing if IESG
somehow let an obviously-weak definition slip through.
_However_, there are two rather special properties of the
concept of IESG review as it appeared in 2048:
(1) If the IESG said "no", it wasn't "no, you can't
register this thing" or "no, you can't use it". Instead
(assuming competence of documentation), it was "nope,
not IETF tree, register it in one of the other trees).
Note that registration in the some of the other trees
was (and is) extremely permissive: in 2048, and as this
has evolved in its predecessors, the review required for
the others is, at most, "someone besides the applicant
needs to look at this, and you need to pay attention to
what they say before registering. So, what the IESG
review was determining was not "register or not" but
whether registration could occur in a particular tree or
category. The distinction between "determine category"
and "determine registration" is discussed in more detail
in section 4 of draft-klensin-iana-reg-policy-00.txt --
I recommend you have a look at it when it is posted and
see what you think of it.
(2) We introduced the term to include _all_ types of
IESG review and approval, including the entire range
from "IESG looks at it, nods approvingly, and tells IANA
to go ahead" to "standards approval". The reason for
the flexibility was primarily so the IESG could decide
that something was far enough along in development or us
in the IETF community to belong there and, in
particular, that a type specified in an I-D that had
received wide discussion could be approved long before
the I-D itself made it through the process and to the
RFC Editor. And the notion was clearly one of the IESG
determining, albeit informally and without requiring a
formal Last Call, the general direction of IETF
consensus on the matter. At least in retrospect, we
were relaxed about that because the media type name
space is not scarce and, because there were other trees,
inappropriately registering something in the IETF tree
or not doing so would not be of earthshaking
consequence.
Now -- personal opinion -- from that perspective we should
probably have been a bit more explicit about what criteria the
IESG was expected to use for that review. Although it does it
in extremely general terms rather than in the context of one
registry, draft-klensin-iana-reg-policy-00.txt attempts to
remedy that omission. More important, in retrospect, when you
picked the term out of context and defined it in 2434 without
criteria and in the absence of alternate registration trees,
that might not have been A Good Thing. But, probably, you
assumed that any specification that invoked that definition from
2434 would define criteria and procedures to the degree needed
by the registry involved. From that perspective, the disconnect
may have occurred with 2780, or we may have just drifted our way
into a problem in which, IMO, the "signoff on definition
quality" which applies generally to registrations and becomes
more important the more important the registration is got
confused with "approval of content" which is appropriate only
for choices among multiple-tree situations.
Again, draft-klensin-iana-reg-policy-00.txt attempts to focus
this discussion by elaborating on the model that underlies my
remarks and, I believe, those of several others. If the
community agrees with its analysis and recommendations, perhaps
we can dig ourselves out of this series of disconnects.
...
In keeping with the general tendency to let things be handled
by others when they can be handled by others, I think changing
requirements from "IESG approval" to "Expert Review" is a Fine
Thing (and think that the IESG should have the right to do
that on its own, even when documents say "IESG approval").
But I like the text describing the "IESG approval" part in
2434 just the way it is.
To preview what would otherwise be a discussion on the new I-D,
here we disagree, for two reasons:
(i) For some registrations, especially those for which
there are no alternate registration categories and where
unidentified use of mechanisms might lead to operational
problems, "IESG approval" may be appropriate, but IESG
non-approval must never mean "no, you can't register it".
(ii) For situations in which "IESG review" is actually
intended to convey a lightweight form of IETF approval,
substitution of the judgment of an individual for an
IESG determination of IETF consensus (however
lightweight that determination process) is completely
inappropriate. Expert Review is a mechanism for
determining adequacy of definition and for managing a
feedback process to submitters, it is not as substitute
for community consensus (however rough) about quality or
desirability, and must not be permitted to become a
substitute for such consensus.
Four-line summary:
We can reasonably delegate a determination of
definitional adequacy to an individual, but decisions
about "good" or "bad", or recommendations to use or not
use something, require community consensus.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf