Subject: Last Call: IP Version 6 over PPP to Proposed Standard

From: Karl Fox <[email-masked]>
Date: Mon, 5 Jan 1998 09:29:01 -0800

Hi folks,

If you can possibly afford the time, please read through the
below-named document and submit your comments to this list.  The IESG
needs our OK before approving it.  Watch especially for common PPP
errors such as option direction errors, redundant text describing how
to negotiate options, etc.

Thanks,

Karl

The IESG writes:
> The IESG has received a request from the IPNG Working Group to consider
> IP Version 6 over PPP <draft-ietf-ipngwg-ipv6-over-ppp-04.txt> as a
> Proposed Standard. This document will replace RFC2023 which will be
> reclassified as Historic.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by January 14, 1998.
> 
> Files can be obtained via
> ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-04.txt
-- 
Karl Fox, servant of God, employee of Ascend Communications
655 Metro Place South, Suite 370, Dublin, Ohio  43017   +1 614 760 4041

---

From: [email-masked] (Rich Shea)
Date: Mon, 05 Jan 1998 15:13:58 -0500

> to negotiate options, etc.

One thing that struck my eye was that this document, and indeed rfc2023,
describe the negotiation of an IPv6-specific header compression
mechanism, but give no reference or description of such a mechanism.  Is
there at least an I-D which describes this mechanism?

If there isn't (which I'm not sure of), should this I-D support the
negotiation of something which doesn't yet exist?  This doesn't seem too
clean, since for an implementation to support the negotiation of an
option it should also support the operation of some functionality due to
the negotiation of that option.  I think the specification of the option
and the specification of what to do when that option is specified (or
when a given value for an option is specified) should be given in the
same document (which they don't appear to be).  If one takes the
approach that the IPv6 header compression scheme isn't defined or
referred to in this document, but IPv6 HC is the only valid value for
the IPv6-Compression-Protocol option specified, then there are no valid
values for this option and so it shouldn't be defined here.  If the
authors want a place-holder, they can keep the option there with the
only defined value for the option being zero (0), i.e. no compression. 
This has only marginal value in my opinion however.

Richard.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Jan 1998 21:37:15 +0100 (MET)

> there at least an I-D which describes this mechanism?

Attached please find a summary by Steve Casner (IETF AVT WG chair) on
the three relevant header compression Internet-Drafts currently under
consideration by the IESG.

Obviously, everyone interested in running PPP over low-speed links
should have a close look at these documents.

Gruesse, Carsten
-----------------------------------------------------------------------------
  Title     : IP Header Compression
  Author(s) : S. Pink, M. Degermark, B. Nordgren
  Filename  : draft-degermark-ipv6-hc-05.txt
  Purpose   : Defines IP, TCP and non-TCP header compression for IPv4
              and IPv6
	    
  Title     : Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
  Author(s) : S. Casner, V. Jacobson
  Filename  : draft-ietf-avt-crtp-04.txt
  Purpose   : Fits into framework defined by draft above to add
              compression of IP/UDP/RTP stack
	    
  Title     : IP Header Compression over PPP
  Author(s) : M. Engan, S. Casner, C. Bormann
  Filename  : draft-engan-ip-compress-02.txt
  Purpose   : Defines extensions to the IP-Compression-Protocol option
              in PPP for protocols in drafts above, and makes PPP
              protocol type number assignments.

---

From: Stephen Casner <[email-masked]>
Date: Mon, 5 Jan 1998 12:47:39 -0800 (Pacific Standard Time)

> there at least an I-D which describes this mechanism?

I'm enclosing below the message I sent to the main ietf list in
response to the Last Call announcement.  I think this answers your
question.  I did get a response from the draft author that the
reference I mention would be added.  Note that the PPP number
assignments in draft-engan-ip-compress-02.txt were discussed at the
PPPEXT in Washington, DC.
							-- Steve

    > reclassified as Historic.
    
    I have no comment on the changes made from RFC2023 to the new draft,
    but there is an additional change that I believe should be made.
    
    The IPv6-Compression-Protocol option lists one "current value":
    
               004f                    IPv6 Header Compression
    
    There is no reference listed for this PPP protocol number assignment
    either in the most recent "Assigned Numbers" RFC nor in the file
    ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers, but my
    understanding is that this assignment corresponds to a proposed header
    compression protocol specified in an internet-draft that expired some
    time ago without being published as an RFC.
    
    Meanwhile, a different IP header compression protocol designed for use
    with both IPv6 and IPv4 has been developed in the IPNG WG and is
    specified in draft-degermark-ipv6-hc-05.txt.  Last Call was also
    requested on this draft (on November 23), though the Last Call notice
    has not been posted yet.
    
    Last Call was also requested (two days ago) on a companion i-d
    draft-engan-ip-compress-02.txt that defines extensions to the
    IP[v6]-Compression-Protocol options in the PPP Control Protocols for
    IPv4 and IPv6 [RFC1332, RFC2023] to handle negotiation of additional
    parameters for the new compression protocol.  This draft also suggests
    to IANA the assignment of value 0061 (as one of a set of assignments)
    for this header compression protocol.
    
    Given that RFC2023 is being updated now as well, all the right
    up-to-date references should be made.
    
    In draft-ietf-ipngwg-ipv6-over-ppp-04.txt:
    
      - The IPNG WG should decide whether the 004f assignment should be
        deprecated and how it should be listed (or not) in this draft.
    
      - The value 0061 (assuming IANA proceeds with that assignment)
        should be listed for the new IP header compression protocol.
    
      - There should be references to the RFC's that the two drafts
        draft-degermark-ipv6-hc-05.txt and draft-engan-ip-compress-02.txt
        are published as, assuming Last Call on them is approved.
    
    In draft-engan-ip-compress-02.txt:
    
      - References to RFC2023 should be updated by the RFC Editor to be
        the new RFC that draft-ietf-ipngwg-ipv6-over-ppp-04.txt becomes.
    
    In other words, I suggest that draft-ietf-ipngwg-ipv6-over-ppp-04.txt
    be updated and then processed with the package of the other two drafts
    and a fourth related draft I didn't mention here.
							-- Steve