Subject: AD review of draft-ietf-ipv6-compression-nego-v2

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jan 2008 22:31:14 +0200

I have reviewed this draft. And asked help from James Carlson
to understand some of the number space issues in PPP (thanks!)

The draft is basically OK, but I have a few suggested editorial
changes. These relate mostly to readability, so I'm not considering
them blocking for starting the IETF Last Call.

I would like to ask Srihari to update the document with
these specific changes, however, and preferably in the
next couple of days so that other readers do not have to
struggle with the same questions that I had.

----

The document header should indicate "Obsoletes: 2472".

Add to the end of the last paragraph of Section 1: "Together with
RFC 5072 [2], this document obsoletes RFC 2472. However, no
protocol changes have been introduced over RFC 2472."

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.

Replace the IANA Considerations section with the following text:

      No specific action is needed for the assignment of a
      value for the Type field of IPv6 datagram compression
      option specified in this specification. The current 
      assignment is up-to-date at [4].

      No action is needed either for the assignment of the
      IPV6-Compression-Protocol values, as such values have
      already been defined by other documents listed in
      Section 2.1. Values for this field are always the
      same as the PPP Data Link Layer Protocol field
      values for that same compression protocol. As a
      result, future allocation of these values is governed
      by RFC 3818 [8] that requires IETF Consensus.

Jari

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: James Carlson <[email-masked]>
Date: Tue, 22 Jan 2008 15:42:16 -0500

>     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              <[email-masked]>
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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jan 2008 23:08:15 +0200

James,

> 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.

Which one is it?

In any case, I'm fine with dropping this reference.

Jari

---

From: James Carlson <[email-masked]>
Date: Tue, 22 Jan 2008 16:18:50 -0500

> For the purposes of knowing which numbers have been allocated, reference

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.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jan 2008 00:09:34 +0200

Ok.

Jari