Date: Fri, 24 Jun 2005 18:07:15 -0400
From: Sam Hartman <hartmans-ietf@xxxxxxx>
Message-ID: <tslaclf2yuk.fsf@xxxxxxxxxx>
| What you seme to be saying is that you would be happy if we told
| Dr. Roberts to ask for review knowing full well that such a review
| would be long, complicated and would probably end up in a rejection.
I think you're confused. There neither is, nor ever was any requirement
that the actual proposed use of the option be agreed as a "good thing"
by the IETF, of for the IETF to approve the techniques that are being
proposed by Dr Roberts' group.
All that the IETF needs to decide is whether or not it is reasonable to
assign a code point in the IPv6 options number space for their needs.
This is hardly something controversial, or that should take very long.
Nor is there any good reason for such a request to be rejected, as long
as there is an option code available (IPv6 isn't exactly swamped with
header options...) and the proposed use is documented enough to be
clear to anyone who sees the option how they should process it, if their
implementation feels inclined to participate.
Whether anyone would want to bother implementing the thing, beuyond the
group that is requesting it, is immaterial. Allocating an option doesn't
require any implementations to support it, let alone to support the
infrastructure that the option is intended to enable.
Just ask the IPv6 working group if there's an option number available,
and if there's any particular reason thatthis particular option would
do harm to IPv6. Assuming they answer "yes, all the option numbers
aren't currently allocated" and "no, we can just ignore this option if
we see it, or drop packets containing it", (whichever option variety was
requested - I forget) then there's no good reason to encourage them to
go and assign an option code for themselves, and by doing so end up
creasting possibly conflicting uses.
Refusing code point allocations, in any registry whatever, should be
a very rare event - and mostly done only for lack of adequate documentation
(somewhere, requiring an RFC is not necessary) or because of duplication.
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf