Date: Fri, 24 Jun 2005 13:08:25 -0400
From: Thomas Narten <narten@xxxxxxxxxx>
Message-ID: <200506241708.j5OH8PSa010808@xxxxxxxxxxxxxxxxxxxxxx>
| The clear intention of the above is that assignments for HBH code
| points be conditioned on IETF review (and approval).
I'd actually say it was more requiring that options be suitably documented.
If IETF approval was required, then only "standards action" would be
permitted. "IETF consensus" permits informational RFCs, and "IESG
approval" actually permits no documentation at all.
| The "IESG Approval" case is a bit of an escape clause, allowing for
| unusual/exceptional situations where getting an RFC published isn't
| appropriate or would take too long.
Or, just perhaps, where the documentation is already published, or
is being published, by another standards body.
Note that 2780 doesn't say "IESG approval in exceptional cases", and
in fact, actually lists "IESG approval" as the first of the methods
by which option code values can be allocated. It doesn't look to me
to just be an escape clause, but one entirely appropriate way for
options to be allocated (especially given that 2434 suggests that for
IESG approval the IESG can request documentation, that hasn't been made
by the RFC process).
| The right thing to do is to have this document reviewed proper in the
| IETF and then let the IETF decide what it wants to do with it.
That's fine. You'll note that I didn't say that the option should
have been approved. What I said was that the way the IESG approached
the issue, rejecting the request because (to paraphrase) "we are also
doing QoS work, and we like our yet to be developed method better, and
we will do everything that we can to make sure that no other proposal
gets any kind of assistance", was not the way that the IESG should be
operating.
| IMO, it would have been completely inappropriate for the IESG to have
| approved this code point assignment. Indeed, had they done so, I am
| certain that a large number of folk would have immediately screamed
| that the IESG had no right to do so (i.e., had exceed its authority,
| etc.), and that it should have consulted with the IETF instead.
I have no problem with that - a last call to seek comments from the
IETF on the request, based upon the existing (non I-D) doc, or even
a referral to the ipv6 working group, might have been appropriate
responses. But that isn't what the IESG did. What they didn't do
was consult with the IETF - consulting is just as important when you
say "no" as when you say "yes".
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf