Tunnelling of Explicit Congestion Notification
RFC 6040
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Lars Eggert No Objection
(David Harrington; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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.
(Alexey Melnikov; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
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)
(Robert Sparks; former steering group member) (was No Record, No Objection) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss, No Objection) No Objection
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?
(Stewart Bryant; former steering group member) No Objection
> 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.
(Tim Polk; former steering group member) No Objection