Jari Arkko writes: > > I know of no reason to refer to the old 2023 assignment of 004f. > > > For the purposes of pointing people to the right spec for implementing > or understanding something, there is no reason to refer to 2023. > > For the purposes of knowing which numbers have been allocated, reference > to 2023 might be useful.
Once this RFC is published, it'll be immutable even if new compression mechanisms are later defined. That means that any list it provides is at best a hint that there are other documents to read, and can't serve (as the IANA reference is supposed to) as a definitive list of protocol numbers. If we're going to provide "helpful" references -- all that we can do -- I think it'd be most helpful to include just the ones that currently have some meaning. As I don't think 004f has any real meaning, and no implementor reading this document should be attempting an implementation of it, I think losing that one reference would be a step in the right direction. It serves only to send readers off into the weeds. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
