Re: AD review of draft-ietf-ipv6-compression-nego-v2
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AD review of draft-ietf-ipv6-compression-nego-v2
Jari Arkko writes:
> Change in Section 2.1 as follows:
> OLD:
> No IPv6-Compression-Protocol field values are currently
> assigned. Specific assignments will be made in documents that
> define specific compression algorithms.
> NEW:
> IPv6-Compression-Protocol field values have been assigned in
> [RFC2023] for IPv6 Header Compression (004f), [RFC2507, RFC3544]
> for IP Header Compression (0061), and [RFC3241] for Robust Header
> Compression (ROHC) (0003). Other assignments can be made in
> documents that define specific future compression algorithms.
I don't believe that the reference to 2023 is correct here. As a
matter of history, that document did declare 004f for a presumably
VJ-like compression scheme (analogous to IPv4), but I know of no
actual documentation of such a scheme that was ever published, nor any
implementations.
RFC 2023 was obsoleted by 2472, which removed the never-used 004f
reference. RFC 2472, in turn, is now obsoleted by 5072, which puts us
in a somewhat unstable state as the still-in-use IPv6-Compression-
Protocol option was removed from that document, pending this draft's
publication.
I know of no reason to refer to the old 2023 assignment of 004f.
(When we talked, I thought we were talking strictly about the history
of the assignment, and I should have noted that at least going
forward, it's dead.)
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
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 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.