SUBSTANTIVE DIFFERENCES 
BETWEEN draft-ietf-dccp-ccid2-08 AND draft-ietf-dccp-ccid2-09
===========================================================================

A clarification.

@@ Page 5, Section 2 @@

 OLD:

     ((no text, add the following paragraph at the end of the section))

 NEW:
 
     The phrases "ECN-marked" and "marked" refer to packets marked ECN
     Congestion Experienced unless otherwise noted.


Another clarification, this one more significant.  We made this in late
11/2004 in response to a question from Pengfei Di.

@@ Page 9, Section 5 @@
 
 OLD:

     Congestion events, namely one or more packets lost or marked from a
     window of data, cause CCID 2 to reduce its congestion window.

 NEW:

     Congestion events cause CCID 2 to reduce its congestion window.  A
     congestion event contains at least one lost or marked packet.  As in
     TCP, two losses or marks are considered to be part of a single
     congestion event when the second packet was sent before the loss or
     mark of the first packet was detected.  As an approximation, a
     sender can consider two losses or marks to be part of a single
     congestion event when the packets were sent within one RTT estimate
     of one another, using an RTT estimate current at the time the
     packets were sent.


Allison requested the following changes to IANA Considerations as part of
IESG review.

@@ Page 15, Section 10 @@

 OLD:
 
     CCID 2 also introduces three sets of numbers whose values should be
     allocated by IANA.  We refer to allocation policies, such as
     Standards Action, outlined in [RFC 2434], and most registries
     reserve some values for experimental and testing use [RFC 3692].

 NEW:

     CCID 2 also introduces three sets of numbers whose values should be
     allocated by IANA, namely CCID 2-specific Reset Codes, option types,
     and feature numbers.  These ranges will prevent any future
     CCID 2-specific allocations from polluting DCCP's corresponding
     global namespaces; see [DCCP] (Section 10.3).  However, this
     document makes no particular allocations from any range, except for
     experimental and testing use [RFC 3692].  We refer to the Standards
     Action policy outlined in RFC 2434.
 
@@ Page 16, Section 10.1 @@

 OLD:

     The remaining Reset Codes -- 128-183, 191-247, and 255 -- are
     currently reserved, and should be allocated with the IETF Consensus
     policy, which requires RFC publication (not necessarily
     standards-track).

 NEW:

     The remaining Reset Codes -- 128-183, 191-247, and 255 -- are
     currently reserved, and should be allocated with the Standards Action
     policy, which requires IESG review and approval and standards-track
     IETF RFC publication.
 
@@ Page 16, Section 10.2 @@

 OLD:

     The remaining option types -- 128-183, 191-247, and 255 -- are
     currently reserved, and should be allocated with the IETF Consensus
     policy, which requires RFC publication (not necessarily
     standards-track).

 NEW:

     The remaining option types -- 128-183, 191-247, and 255 -- are
     currently reserved, and should be allocated with the Standards Action
     policy, which requires IESG review and approval and standards-track
     IETF RFC publication.
 
@@ Page 16, Section 10.3 @@

 OLD:

     The remaining feature numbers -- 128-183, 191-247, and 255 -- are
     currently reserved, and should be allocated with the IETF Consensus
     policy, which requires RFC publication (not necessarily standards-
     track).

 NEW:

     The remaining feature numbers -- 128-183, 191-247, and 255 -- are
     currently reserved, and should be allocated with the Standards Action
     policy, which requires IESG review and approval and standards-track
     IETF RFC publication.