Tunnelling of Explicit Congestion Notification
draft-ietf-tsvwg-ecn-tunnel-10

A quick note.
In the Acknowledegements...

   The views expressed here are those of the
   author only.

I know what you mean with respect to your sponsor, but the views expressed here represent IETF consensus now, so this sentence is not accurate.

A few comments from Ari Keranen:

1. Introduction

   Nonetheless, the latest IPsec architecture [RFC4301] considered a
   bandwidth limit of 2 bits per packet on a covert channel made it a
   manageable risk.

Remove "made it"?

4. New ECN Tunnelling Rules

   an alternate congestion marking scheme used by a specific Diffserv
   PHB (see S.5 of [RFC3168] and [RFC4774]).

For consistency: s/S/Section/
(also in Section 7 and Appendix B1)

A fine document.  I've only got some non-blocking comments:

#1 - Sometimes RFC4301 and RFC3168 is used when describing the IPsec tunnels and non-IPsec tunnels and sometimes it is used to describe the actual document.  Could IPsec tunnels and non-IPsec tunnels be used instead when discussing the tunnels and [RFC4301] and [RFC3168] be used when describing the document?  I think it would make it clearer.

#2 - If there's one required mode and one optional, then I suggest in Section 4.1:

OLD:

a REQUIRED `normal mode' and a `compatibility mode'

NEW:

a REQUIRED `normal mode' and an OPTIONAL `compatibility mode'

#3 - The tables include codepoints and "drop". Can you add a NOTE that indicates "drop" in the tables is not a codepoint.

#4 - Section 4.2: 

 This is because the
 inner Not-ECT marking is set by transports that use drop as an
                                                         
                                    replace drop with "drop" ?

  indication of congestion and would not understand or respond to
  any other ECN codepoint [RFC4774].

#5 - Section 5.1 & 5.2, please indicate which sections are changed in 4301/3168.  It will aid readers who are familiar with those documents.   

#6 - Section 5.2:

The compatibility mode of encapsulation is identical to the
      encapsulation behaviour of the limited functionality mode of an
      RFC3168 ingress, except it is optional.
                                    ^^^^^^^^r/optional/OPTIONAL?

> In some circumstances (e.g. pseudowires, PCN), the whole path
> is divided into segments, each with its own congestion
> notification and feedback loop. 

The above reference to PWs assumes an agreed  documented MS-PW congestion architecture, whereas the most that exists is a few hints in RFC5659. The reference to PWs should be removed, or the text aligned with RFC5659.