Re: [Int-area] Re: I-D ACTION:draft-fenner-iana-exp-2780-01.txt

[Marshall Eubanks <[e-mail]>]

Hello;

On Jan 12, 2006, at 7:53 AM, Brian E Carpenter wrote:

> Some personal comments on this.
>
> I'm in favour of making these assignments. I think they will allow
> innovation and deflect some of the pressure for assignments for
> essentially private use.
>
> I'd actually question whether we shouldn't state explicitly that
> it's OK to use these values in production in a private network.
> That was why we defined some diffserv space as "experimental/local"
> and so far I don't think it's caused any difficulty. Private
> use is nicely defined in RFC 2434 (and 2434bis) and mentioned
> in RFC 3692.
>
>> Status of this Document
>>    This is a strawman to see what the community thinks of allocating
>>    experimental numbers as [RFC3692] proposes to other IANA- 
>> maintained
>>    number spaces.
>
> Presumably, this is the last version that needs to carry this  
> disclaimer.
>
>> 2.4.2.  IPv4 Multicast
>>    The globally routable group 224.0.1.20 is set aside for
>>    experimentation.  For certain experiments, the administratively
>>    scoped multicast groups defined in [RFC2365] may be
>>    useful.[[anchor10: Should there be a 'link-local' 224.0.0.x
>>    experiment group? --wcf]]
>
> To me it doesn't really seem necessary. Any link-local resource is
> safe to use experimentally, subject to local administration.

I would agree. Note that, per RFC2365, there is all of 239/8  
available for any local experimentation, again
subject to local administration, and I would regard that as a better  
place for it.

Regards
Marshall Eubanks


>
>> 2.5.  IPv4 Option Type field
>>    This document assigns a single option number, with all defined  
>> values
>>    of the "copy" and "class" fields, resulting in four distinct  
>> option
>>    type codes.
>
> Maybe add "See Section 8." since otherwise the reader may be  
> puzzled about
> where the number is. (Same comment for section 3.5.)
>
>> 3.6.3.  IPv6 Neighbor Discovery Option Type
>>    This document assigns two IPv6 Neighbor Discovery Option Types,  
>> TBD1
>>    and TBD2.
>> 4.  Fields in the IPv4 ICMP header
>>    This document assigns two ICMPv4 type numbers, TBD1 and TBD2.   
>> ICMPv4
>>    code values are allocated per-type, so it's not feasible to assign
>>    experimental values in this document.
>
> Shouldn't each new TBD get an incremented suffix, TBD3 etc.?
>
>>    [I-D.ietf-ipv6-unique-local-addr]
>>               Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
>>               Addresses", draft-ietf-ipv6-unique-local-addr-09  
>> (work in
>>               progress), January 2005.
>
> This is RFC 4193 now.
>
>    Brian
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/int-area


_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area