Tunnelling of Explicit Congestion Notification
RFC 6040

Note: This ballot was opened for revision 10 and is now closed.

(David Harrington) Yes

(Jari Arkko) No Objection

Comment (2010-08-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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)

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2010-08-24 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

> 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.

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

Comment (2010-08-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Russ Housley) No Objection

(Alexey Melnikov) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) (was No Record, No Objection) No Objection

(Sean Turner) (was Discuss, No Objection) No Objection

Comment (2010-08-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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:


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


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.