Date: Wed, 22 Jun 2005 11:12:53 -0400
From: IESG <iesg@xxxxxxxx>
Message-ID: <E1Dl6uL-0006ci-9i@xxxxxxxxxxxxxxxx>
| The IESG declines Dr. Roberts's request for a hop-by-hop option for
| QOS purposes.
I have no idea whether the option is actually any good or not, nor whether
it should be approved, so don't consider this a message in support of
the option.
However, the IESG's stated reasons for declining to register the option
are utter nonsense, and cannot be allowed to remain as a precedent for
the way the IETF and IESG does business.
| The proposal includes significant changes to the
| Internet architecture including a new TCP congestion control
| algorithm, new requirements for IPsec security gateways and new
| behavior for routers.
Whether any of that is a viable proposal or not is for others to
judge (not even the IESG I'd suggest), but it makes no difference
what the answer is to that question for the actual request that
was made.
| Adopting the changes to the Internet
| architecture contemplated by this proposal would require review and
| consensus within the IETF; it would be inappropriate for another
| standards organization to modify IETF protocols as contemplated by
| this proposal.
Yes, that's true, but what is the relevance?
| Within the NSIS working group, the IETF is already
| actively working on solutions to QOS and to other problems identified
| in this specification.
That's great, and also irrelevant.
| We believe that these efforts will lead to a
| preferable solution to the problems identified in this proposal.
Thats optimistic. It is a little hard to believe in anything that's
both significant and new appearing from an IETF working group this days.
But that's also irrelevant.
| Reviewing this proposal within the IETF as an alternative to the
| ongoing work would be a multi-year endeavor.
Then don't do that. That isn't what was requested, as best I can tell.
| The IESG is pessimistic that this effort would ever achieve consensus.
That's probably a more realistic assessment of the chances of any
proposed working group doing anything significant.
| So, the IESG
| declines the assignment request and recommends against pursuing this
| proposal within the IETF.
All that was requested (of the IANA) as far as I can see was the assignment
of an option code. That implies nothing about whether or not anyone should
actually support the thing. All it does is encourage interoperability by
avoiding collisions in the option number space. That's why the IANA
registries exist. They're not there so the IETF can prevent anyone from
attempting anything without getting IETF approval first.
Legitimate reasons for refusing a request would be that there's already
an option code defined that does the same job, or that the specification of
the proposed option isn't clear enough to allow anyone to actually process
the thing correctly, or ... (others like that).
An illegitimate reason for refusing such a request is "we don't like the
use you're planning to make of the option". All that does is encourage
people to ignore the IANA registry (and IESG and IETF) and define their
own option code, and later, present it as a "already implemented in
hundreds of products" fait accomplii (sp??) which isn't in anyone's best
interests.
I's encourage Dr Roberts to commence the appeal procedures set forth in
RFC2026 as soon as possible. If the IESG don't either reverse their
decision, or produce legitimate reasons for rejecting it, then if the IAB
is doing its job even half properly, the IESG should get totally squashed
by this one.
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf