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

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.

> 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
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area