Subject: Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

From: "Ken Carlberg" <[email-masked]>
Date: Fri, 24 Jun 2005 16:11:58 -0400

>  | 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.

there is precedence regarding concern over new efforts and their
relationship to TCP.  I can't cite chapter and verse, but I seem to 
recall that the work on reliable-multicast and BEEP (two different 
efforts altogether) were informed by the powers-that-be to be 
"TCP friendly".  the degree by which one views the new algorithm as 
"unfriendly" is something I'll defer to others more qualified than 
myself.

what I do find troubling is the arguement that new requirements 
for IPsec security gateways and new behavior for routers is an
added reason for rejecting the proposal.  in a rebuttal comment,
Thomas Narten writes:

> RFC 2780 says:
>
>> 5.5 IPv6 Hop-by-Hop and Destination Option Fields
>> 
>>   Values for the IPv6 Hop-by-Hop Options and Destination Options fields
>>   are allocated using an IESG Approval, IETF Consensus or Standards
>>   Action processes.
>
>(where those terms are defined in RFC2434.)
>
>The clear intention of the above is that assignments for HBH code
>points be conditioned on IETF review (and approval). That is, a
>document that gets published as an Internet Draft, gets reviewed, and
>then pops out as an RFC.

intention or even tradition has little weight.  The key word used
above is IESG Approval "or" standards action (ie, RFC).  That being
the case and agreed to by the IESG allows Dr. Roberts to go straight
to the IESG and ask for the extension.

Dr. Roberts may have given the IESG a jolt in being very thorough 
about what could be done with such an extension, but I side with
Robert Elz as to the relevence.  The system says that someone can
make a request for an extension to IPv6.  If there are no additional
criteria set forth for the field, and the extension doesn't clash,
it would seem that request should be satisfied.  Dr. Roberts seems
to have played within the rules.

-ken

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked] (Scott Bradner)
Date: Wed, 29 Jun 2005 14:55:25 -0400 (EDT)

Yakov asks:
> What was the reason(s) the request was made for an assignment
> that required IESG Approval, rather than either Specification
> Required or First Come First Serve ?

it semed to be the right thing at the time

it seemed to be too lose to have the IETF out of the loop
when changing one of the core IETF protocols in a way that could
require changes to deployed software and hardware but it seemed
a bit much to require that all such options have to go through 
a full IETF development process ( because there could
be options the IETF did not have much interest or concern
about and such a lack of interest should not be an automatic block)

i.e. a middle ground

Scott