--- 1/draft-ietf-rohc-over-ppp-02.txt	2006-02-05 01:25:08.000000000 +0100
+++ 2/draft-ietf-rohc-over-ppp-03.txt	2006-02-05 01:25:08.000000000 +0100
@@ -1,17 +1,17 @@
 
 INTERNET-DRAFT                                           Carsten Bormann
-Expires: January 2002                                     TZI/Uni Bremen
-                                                               July 2001
+Expires: February 2002                                    TZI/Uni Bremen
+                                                             August 2001
 
                              ROHC over PPP
-                    draft-ietf-rohc-over-ppp-02.txt
+                    draft-ietf-rohc-over-ppp-03.txt
 
 Status of this memo
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC 2026.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
@@ -230,22 +230,36 @@
             2n+2
 
          Value
             n octet-pairs in ascending order, each octet-pair specifying
             a ROHC profile supported.
 
 3.  Multiple Network Control Protocols
 
    The ROHC protocol is able to compress both IPv6 and IPv4 datagrams.
    Both IPCP and IPV6CP are able to negotiate option parameter values
-   for ROHC.  These values apply to the compression of packets where the
-   outer header is an IPv4 header and an IPv6 header, respectively.
+   for ROHC.  The ROHC capability negotiated as a whole applies to the
+   compression of packets where the outer header is an IPv4 header and
+   an IPv6 header, respectively; e.g., an outer IPv6 header MUST NOT be
+   sent if the ROHC IP-Compression-Protocol option was not negotiated
+   for IPV6CP.
+
+   Offering a specific ROHC capability in a Configure-Request in either
+   IPCP or IPV6CP indicates that the capability is provided for the
+   entire ROHC channel formed by the PPP link.  When the option is
+   negotiated with different values in IPCP and IPV6CP, the result is
+   that the set of parameters for the entire ROHC channel is the logical
+   union of the two values, i.e., the maximum for MAX_CID, MRRU or
+   MAX_HEADER, and the logical union of the suboptions.  For the
+   PROFILES suboption, the logical union is the union of the two sets of
+   profiles.  Note that each new suboption for this option must define
+   the meaning of "logical union", if the concept applies.
 
 3.1.  Sharing Context Identifier Space
 
    For the compression and decompression of IPv4 and IPv6 datagram
    headers the context identifier space is shared.  While the parameter
    values are independently negotiated, sharing the context identifier
    spaces becomes more complex when the parameter values differ.  Since
    the compressed packets share context identifier space, the
    compression engine must allocate context identifiers out of a common
    pool; for compressed packets, the decompressor has to examine the
@@ -300,25 +314,25 @@
    demultiplexing method.  Therefore, no consideration was given to
    locking down one of the context numbers for the uncompressed profile
    (see [RFC3095] section 5.1.2).  Note, however, that according to the
    ROHC specification profile 0x0000 must not be rejected [RFC3095], so
    it MUST be implemented by all receivers.
 
 5.2.  Parameter selection
 
    For each of the ROHC channel parameters MAX_CID and MRRU, the value
    is the maximum of the respective values negotiated for the IPCP and
-   IPv6CP instances, if any.
-
-   The ROHC channel parameter FEEDBACK_FOR is set implicitly to the
-   reverse direction on the same PPP link (see "Sharing Context
-   Identifier Space" above).
+   IPv6CP instances, if any.  The ROHC channel parameter FEEDBACK_FOR is
+   set implicitly to the reverse direction on the same PPP link (see
+   "Sharing Context Identifier Space" above).  The ROHC channel
+   parameter LARGE_CIDS is not used, instead the PPP protocol ID on the
+   packet is used  (see "Demultiplexing of Datagrams" above).
 
    A number of parameters for ROHC must be set correctly for good
    compression on a specific link.  E.g., the parameters k_1, n_1, k_2,
    n_2 in section 5.3.2.2.3 of [RFC3095] need to be set based on the
    error characteristics of the underlying links.  As PPP links are
    usually run with a strong error detection scheme [RFC1662], k_1 = n_1
    = k_2 = n_2 = 1 is usually a good set of values.  (Note that in any
    case k values need to be set low enough relative to n values to allow
    for limited ability of the CRC to detect errors, i.e., the CRC will
    succeed for about 1/8 of the packets even in case of context damage,