SUBSTANTIVE DIFFERENCES 
BETWEEN draft-ietf-dccp-ccid3-09 AND draft-ietf-dccp-ccid3-10+
===========================================================================

An editorial error ("less that") was found in draft version 09 by gen-art.
The more significant substantive error was reported by Sara Landstro"m.
Please note that the substantive fix is not present in the -11 draft.

@@ Page 32, Section 10.3 @@

 OLD:

     RFC 3448 (Sections 6.1 and 6.2) specifies that the TFRC receiver sends
     a feedback packet when the new loss event rate p is less that the old
     value.

 NEW:

     RFC 3448 (Sections 6.1 and 6.2) specifies that the TFRC receiver sends
     a feedback packet when the new loss event rate p is greater than the
     old value.


This change (in the -11 draft) was requested by gen-art.

@@ Page 22, Section 8.1 @@

 OLD:

     This value is set to 0 at the beginning of the transmission, and
     generally increased by 1 every quarter of a round-trip time, as
     described in RFC 3448 (Section 3.2.1).

 NEW:

     This value is set to 0 at the beginning of the transmission, and
     generally increased by 1 every quarter of a round-trip time, as
     described in RFC 3448 (Section 3.2.1).  Window counters use circular
     arithmetic modulo 16 for all operations, including comparisons; see
     [DCCP] (Section 3.1) for more information on circular arithmetic.



The following changes to IANA Considerations were requested by Allison as
part of IESG review.

@@ Page 34, Section 12 @@
 
 OLD:
 
     CCID 3 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 3 also introduces three sets of numbers whose values should be
     allocated by IANA, namely CCID 3-specific Reset Codes, option types,
     and feature numbers.  These ranges will prevent any future
     CCID 3-specific allocations from polluting DCCP's corresponding
     global namespaces; see [DCCP] (Section 10.3).  However, we note that
     this document makes no particular allocations from the Reset Code
     range, except for experimental and testing use [RFC 3692].  We refer
     to the Standards Action policy outlined in RFC 2434.
 
@@ Page 34, Section 12.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 34, Section 12.2 @@

 OLD:

     The remaining option types -- 128-183, 191, 195-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, 195-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 34, Section 12.3 @@

 OLD:

     The remaining feature numbers -- 128-183, 191, 193-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, 193-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.