SUBSTANTIVE DIFFERENCES 
BETWEEN draft-ietf-dccp-ccid2-10 AND RFC 4341
===========================================================================

These changes were collected from mail sent to the RFC Editor.  We have
removed a large number of changes that only concerned formatting or
grammar.


Section 4, 1st par (correction: the client might send more than one
Request, and according to rfc4340, all should have application data)

OLD
    Vector, 1)" from the receiver, except possibly for data included on
    the initial DCCP-Request packet.

NEW
    Vector, 1)" from the receiver, except that it MAY send data on DCCP-
					  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Request packets.
    ^^^^^^^^^^^^^^^



Section 5, 1st par after "Transmit timeouts" list item (add explicit
mention of an important case, left implicit before)
 
OLD
    True duplicate acknowledgements, for example, MUST NOT affect pipe.

NEW (add second sentence)
    True duplicate acknowledgements, for example, MUST NOT affect pipe.
    The sender also MUST NOT decrement pipe again upon receiving
    acknowledgement of a packet previously inferred as lost.



Section 6, 1st par (reference correction, and technical clarification:
reiterate language from rfc4340)

OLD
    entire Acknowledgement Window; see [RFC4340] (Section 11.4.2).

NEW (make change and add new final sentence)
    entire Acknowledgement Window; see [RFC4340], Section 11.4.2.  
						^^^^^^^^^^^^^^^^
    Any Data Dropped options SHOULD likewise cover the receiver's entire
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Acknowledgement Window.
    ^^^^^^^^^^^^^^^^^^^^^^^



Section 6.1.1, 3rd par (clarification)

OLD 
    A receiver that implements its own acknowledgement congestion control
    SHOULD NOT reduce

NEW
    A receiver that implements its own acknowledgement congestion control
    independent of Ack Ratio SHOULD NOT reduce
    ^^^^^^^^^^^^^^^^^^^^^^^^