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
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
