Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation
draft-ietf-tsvwg-ecn-experimentation-08

Received changes through RFC Editor sync (created alias RFC 8311, changed abstract to 'This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints.  It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss.  This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas.  An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates.  In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622.  This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.', changed pages to 20, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-01-12, changed IESG state to RFC Published, created updates relation between draft-ietf-tsvwg-ecn-experimentation and RFC 3168, created updates relation between draft-ietf-tsvwg-ecn-experimentation and RFC 4341, created updates relation between draft-ietf-tsvwg-ecn-experimentation and RFC 4342, created updates relation between draft-ietf-tsvwg-ecn-experimentation and RFC 5622, created updates relation between draft-ietf-tsvwg-ecn-experimentation and RFC 6679)

[Ballot discuss]
Below is Sue Hares' OPS DIR review. I would like to DISCUSS some points. I'm of two minds.
On one side, I read:

      The scope of this memo is limited to these three areas of
      experimentation.  This memo expresses no view on the likely outcomes
      of the proposed experiments and does not specify the experiments in
      detail.  Additional experiments in these areas are possible, e.g., on
      use of ECN to support deployment of a protocol similar to DCTCP
      [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is
      limited to data center environments.  The purpose of this memo is to
      remove constraints in standards track RFCs that stand in the way of
      these areas of experimentation.

On the other side:

  An Experimental RFC MUST be published for any protocol
  or mechanism that takes advantage of any of these enabling updates.

Btw, the MUST is just plain wrong, as Ben mentioned.
So, if you go in the direction of providing requirements for the experiments (as opposed to just removing the specification constraints), then I agree with Sue. The document title goes in the direction: if it would say something such as "Removing constraints to the ECN experimentation", that would be a different story.


Reviewer: Susan Hares
Review result: Has Issues

This is an OPS-DIR Review which focus the work on issues in deployed technology
based on this RFC.

Summary: Has issues as guide to experimental RFC .  To me these operational
issues General comment: Thank you david for addressing this Area.  Better ECN
control is critical to many portions of the network.
                                  My comments on this draft are because I
                                  really hope you can do quality experiments.

How this might be resolved: if there is a operational guidelines section (or
separate document), that covered: a) how to set-up and determine if a ECT(1)
experiment success or fails b) how to manage your ECT(1) experiment in your
network. c) how to manage and detect if your ECT experiment is running into
problems with other IETF technology (TRILL, MPLS VPNs, IPVPNs, BIER and NV03
technology). d) Recommending a monitoring structure (e.g. yang modules,
netconf/restconf and monitoring tools0

Major issues:

#1 There is nothing in this document which provide guidelines to the authors of
experimental RFCs based in this draft on specific ways to
    monitor the ECN experiments, report the ECN experimental data, or disable
    the experimental data.  If the success or failure of an experiment is
    based on "popular vote" determined by deployment, then say state this
    point.  I personally would object to that
  because you cannot tell if a limited experiment in a specific location (E.g.
  a data center) might be successful in another location.

  If the success or failure of an experimental RFC is based on a specific set
  of criteria for ECN, then it would be good to give an operational suggestion
  on how to: a) design an experiment, b) run an experiment and collect data,
  and c) report ths
data in order to standardize the ECN experiments using ECT(1).

page 10 section 4.2 last 2 paragraphs in sentence, hinted that you have an
experiment in mind without specifying the experiment's success or failure
criteria other than popular vote.  Is this true?  if it is, this is
problematic.  If I misunderstood your text, then please
have someone re-read the text.

I have read lots of papers on ECN.

2) No discussion was given on how the TCP layer experimentation would impact
routing layer handdlng of ECN.

For example, the trill WG has the draft draft-ietf-trill-ecn-support.
Automated tunnel set-up for MPLS VPNS or IP VPNS may look at the ECN ECT(0)  or
ECT(1).  TRILL's ECN supports the layer-2 within the data centers.  Some IP
VPNS or MPLS VPNS may be needed for the data-center to business site
or data-center backup traffic.

As written, this draft allows loosening of the RFC3168 draft but does not
provide guidelines  for network interaction.

3)  Some networks also use the diff-service markings to guide traffic in the
network.
    This document does not suggest an operational check list on how to design
    an experiment that supports or does not support these markings.

4) Modern operational IETF protocols and data modules for automating the
tracking of these experiments should be suggests

[Ballot comment]
And again, I can only agree with Sue's comment below, as stressed by Ekr and Ben also.
However, this point was answered by Spencer and Mirja, so let's move on.


Editorial:
Some reviews have hinted that the text is repeats several sets of language. 
People have found this lacked clarity.  One wonders why the authors did not
simply provide a set of bis documents for RFC3168, RFC6679, RFC 4341, RFC4342,
and RFC5622 if it is just updating the language in the specifications.

This document tries to be both revision of the specifications and the
architectural guidelines for experiments.  The dual nature does not lead to
clarity on either subject.

[Ballot comment]
Substantive:

General:

I agree with Ekr's comment specifying RFC updates as text"patches" is confusing and unfriendly to the reader. While I don't necessarily agree that we should do bis drafts instead, I hope people will remember that we never actually render an "updated" RFC with the patches applied. I think this sort of thing would be easier to understand if we just spoke of the changes at a conceptual level and avoid getting wrapped around changing specific words to other specific words.  I don't expect that to change with this particular draft, but I think the IESG should consider some guidance here. (And I fully recognize that a lot of update drafts in ART do the same thing.)


-1, first paragraph: "An Experimental RFC MUST be published for any protocol
  or mechanism that takes advantage of any of these enabling updates."

This seems like an odd use of 2119 language, at least for something other than a BCP.  Furthermore, I don't think this paragraph is the real authority on the matter, since there is much more precise text scattered through the draft about this particular requirement. Therefore, I suggest removing the 2119 language and stating this descriptively. (e.g. "Mechanisms that take advantage of these updates are to be specified in experimental RFCs.")

Speaking of which, there are several references to requiring experimental RFCs. Are those expected to be IETF stream RFCs?


-5, first "patch":
Are there existing implementations that would become noncompliant with the new text?

-9, 1st paragraph: "As a process memo that only removes limitations on proposed
  experiments, there are no protocol security considerations."
I am skeptical that removing limitations from experiments can be assumed to be security neutral on its face. Please consider documenting the thought process that led to that conclusion.

Editorial:
-1, 2nd paragraph: " There is no need to make changes for protocols ...
I'm a bit confused--those hypothetical standards track RFCs will need to make the sort of changes that this paragraph says are not needed. Is the point that _this_ document does not need to make those changes?

-2, Congestion Response Difference: "As discussed further in
      Section 4.1, an ECN congestion indication communicates a higher
      likelihood that a shorter queue exists at the network bottleneck
      node by comparison to a packet drop that indicates congestion
      [I-D.ietf-tcpm-alternativebackoff-ecn]."

I'm not sure what is being compared here. Is it a high chance of shorter queue, or higher chance of a short queue?

-- (same paragraph): "(next bullet)"
There are no bullets.

-2, Congestion Marking Difference:
The first sentence is hard to parse. Please consider breaking it into simpler sentences.

-3, first paragraph: "As specified in RFC 3168, ... [stuff]... , as specified in experimental
  RFC 3540 [RFC3540].
This is hard to parse. In particular, I have trouble deciphering which part is supposed to be specified in 3168 vs 3540.

-- 2nd paragraph: "but might equally have been due to re-
  marking of the ECN field by an erroneous middlebox or router."
I think "erroneous" modified "re-marking" rather than "middlebox or router".

-4.2, 1st paragraph: "... prevent the aggressive low latency traffic starving conventional
  traffic ...  "
Is there a missing "from" between "traffic" and "starving"  Or maybe an "of" after "starving"?

[Ballot comment]
Substantive:

General:

I agree with Ekr's comment specifying RFC updates as text"patches" is confusing and unfriendly to the reader. While I don't necessarily agree that we should do bis drafts instead, I hope people will remember that we never actually render an "updated" RFC with the patches applied. I think this sort of thing would be easier to understand if we just spoke of the changes at a conceptual level and avoid getting wrapped around changing specific words to other specific words.  I don't expect that to change with this particular draft, but I think the IESG should consider some guidance here. (And I fully recognize that a lot of update drafts in ART do the same thing.)

Speaking of which, there are several references to requiring experimental RFCs. Are those expected to be IETF stream RFCs?

-1, first paragraph: "An Experimental RFC MUST be published for any protocol
  or mechanism that takes advantage of any of these enabling updates."

This seems like an odd use of 2119 language, at least for something other than a BCP.  Furthermore, I don't think this paragraph is the real authority on the matter, since there is much more precise text scattered through the draft about this particular requirement. Therefore, I suggest removing the 2119 language and stating this descriptively. (e.g. "Mechanisms that take advantage of these updates are to be specified in experimental RFCs.")

-5, first "patch":
Are there existing implementations that would become noncompliant with the new text?

-9, 1st paragraph: "As a process memo that only removes limitations on proposed
  experiments, there are no protocol security considerations."
I am skeptical that removing limitations from experiments can be assumed to be security neutral on its face. Please consider documenting the thought process that led to that conclusion.

Editorial:
-1, 2nd paragraph: " There is no need to make changes for protocols ...
I'm a bit confused--those hypothetical standards track RFCs will need to make the sort of changes that this paragraph says are not needed. Is the point that _this_ document does not need to make those changes?

-2, Congestion Response Difference: "As discussed further in
      Section 4.1, an ECN congestion indication communicates a higher
      likelihood that a shorter queue exists at the network bottleneck
      node by comparison to a packet drop that indicates congestion
      [I-D.ietf-tcpm-alternativebackoff-ecn]."

I'm not sure what is being compared here. Is it a high chance of shorter queue, or higher chance of a short queue?

-- (same paragraph): "(next bullet)"
There are no bullets.

-2, Congestion Marking Difference:
The first sentence is hard to parse. Please consider breaking it into simpler sentences.

-3, first paragraph: "As specified in RFC 3168, ... [stuff]... , as specified in experimental
  RFC 3540 [RFC3540].
This is hard to parse. In particular, I have trouble deciphering which part is supposed to be specified in 3168 vs 3540.

-- 2nd paragraph: "but might equally have been due to re-
  marking of the ECN field by an erroneous middlebox or router."
I think "erroneous" modified "re-marking" rather than "middlebox or router".

-4.2, 1st paragraph: "... prevent the aggressive low latency traffic starving conventional
  traffic ...  "
Is there a missing "from" between "traffic" and "starving"  Or maybe an "of" after "starving"?

[Ballot comment]
Section 3 ends with the following text:

  Additional minor changes remove other mentions of the ECN nonce and
  implications that ECT(1) is intended for use by the ECN nonce; the
  specific text updates are omitted for brevity.

I'm not sure I follow what's meant here. Is this basically saying "there are other, less substantive edits required to RFC 3168, but those changes are left as an exercise for the reader"?

[Sorry for the additional noise, but I noticed one more issue that you'll want to correct]

Section 9 says "See Appendix B.1 of [I-D.ietf-tsvwg-ecn-l4s-id] for discussion of alternatives to the ECN nonce." I beleive that this should refer to Appendix C.1 rather than Appendix B.1.

[Ballot comment]
Section 3 ends with the following text:

  Additional minor changes remove other mentions of the ECN nonce and
  implications that ECT(1) is intended for use by the ECN nonce; the
  specific text updates are omitted for brevity.

I'm not sure I follow what's meant here. Is this basically saying "there are other, less substantive edits required to RFC 3168, but those changes are left as an exercise for the reader"?

[Ballot comment]
1) section 2 actually seems a bit redundant to me but I guess that not a problem. I guess I would also be okay with the doc if section 2 would not be there, but maybe this overview actually helps others who are less familiar with ECN.

2) I guess it could actually be helpful to include a tiny bit of reasoning why the ECN Nonce experiment is concluded instead of just saying that it was never deployed and further point to an appendix of a draft (which is actually appendix C and not B.1 I believe). I know this was discussed, but having one sentence saying something in the lines like this is probably not to hard: "The experiment is concludes with the result that ECN Nonce does not provide a reliable integrity protection as the other end can always pretend to not support this optional feature."

3) This sentence is a bit unclear:
"In addition, until the conclusion of the L4S experiment, use of
  ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to
  allocate ECT(1) exclusively for L4S usage if the L4S experiment is
  successful."
I guess the L4S exp RFC would use ECT(1), so the sentence to not really make sense to me. Also given that there is no RFC for L4S yet, we actually don't know if there is finally community/group consensus to publish that RFC. I guess it actually to early to say something like this. I know why you want to have this sentence in there, but from the processing point of view that does not seems to be the correct thing to do and it might be better to just remove it.
Otherwise, if you want to  keep it or something similar but maybe less specific, following up on the feedback provided by IANA, the TCP flag should probably be just marked as reserved with reference to this RFC.

4) I'm not certain about this part:
"An exception to this requirement occurs in
      responding to an ongoing attack.  For example, as part of the
      response, it may be appropriate to drop more ECT-marked TCP SYN
      packets than TCP SYN packets marked with not-ECT. "
Maybe it's to late here and that's the reason I don't get it, but what would be the reason to rather drop ETC marked SYNs? Can you explain? I do understand that there is no reason to not drop ECT-marked SYNs in an attack situation (meaning don't try to mark, drop immediately) but I don't understand why you should drop ECT-marked SYNs preferentially? If the assumption is that attacker would more likely use ECN than non-attackers because the will usually not be dropped but marked, I'm uncertain if that is true and still not sure if the above recommendation is appropriate. In any case I think this needs at least more explanation in the document.

5) As a side note on this sentence:
"Random ECT values MUST NOT be used, as that may expose RTP to
      differences in network treatment of traffic marked with ECT(1) and
      ECT(0) and differences in associated endpoint congestion
      responses, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]."
I think random marking is anyway not a good idea because this is sometimes used (incorrectly) as input for ECMP. Therefore I actually think the reference to the l4s draft is actually not needed here.

[Ballot comment]
Having a document which is sort of a verbal patch on another document is pretty hard to read. I recognize that this seems to be customary in some areas, so I'm not marking this as DISCUSS, but I really wish you would do a bis instead.


INLINE COMMENTS
Line 98
  This memo updates RFC 3168 [RFC3168] which specifies Explicit
  Congestion Notification (ECN) as a replacement for packet drops as
  indicators of network congestion.  It relaxes restrictions in RFC
Replacement or additional indicator?


Line 164
      that for congestion indicated by ECN, a different sender
      congestion response (e.g., reduce the response so that the sender
      backs off by a smaller amount) may be appropriate by comparison to
nit: reducing


Line 170
      couples the backoff change to Congestion Marking Differences
      changes (next bullet).  This is at variance with RFC 3168's
      requirement that a sender's congestion control response to ECN
I'm having a lot of trouble reading this sentence. It seems like you are comparing the ECN response to a lost response, but these other two drafts also are about a less aggressive response. Perhaps this would be clearer as:

"indicated by loss. Two examples of such a reduced response are..."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-tsvwg-ecn-experimentation-05. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Transmission Control Protocol (TCP) Header Flags registry located at:

https://www.iana.org/assignments/tcp-header-flags/

The registry entry for bit 7 - the NS (Nonce Sum) bit - will be removed.

An annotation to the registry will be added to state that bit 7 was used by Historic RFC 3540 as the NS (Nonce Sum) bit.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-09-19):

From: The IESG
To: IETF-Announce
CC: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, draft-ietf-tsvwg-ecn-experimentation@ietf.org, spencerdawkins.ietf@gmail.com, Gorry Fairhurst , tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Explicit Congestion Notification (ECN) Experimentation) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Explicit Congestion
Notification (ECN) Experimentation'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-09-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This memo updates RFC 3168, which specifies Explicit Congestion
  Notification (ECN) as a replacement for packet drops as indicators of
  network congestion.  It relaxes restrictions in RFC 3168 that would
  otherwise hinder experimentation towards benefits beyond just removal
  of loss.  This memo summarizes the anticipated areas of
  experimentation and updates RFC 3168 to enable experimentation in
  these areas.  An Experimental RFC is required to take advantage of
  any of these enabling updates.  In addition, this memo makes related
  updates to the ECN specifications for RTP in RFC 6679 and for DCCP in
  RFC 4341, RFC 4342 and RFC 5622.  This memo also records the
  conclusion of the ECN Nonce experiment in RFC 3540, and provides the
  rationale for reclassification of RFC 3540 as Historic; this
  reclassification enables new experimental use of the ECT(1)
  codepoint.

Please note that this is a second Last Call, necessary because the first Last
Call announcement omitted notification of a normative downref to
RFC 3540, the document being moved to Historic.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5622: Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) (Experimental - IETF stream)
    rfc3540: Robust Explicit Congestion Notification (ECN)  Signaling with Nonces (Experimental - IETF stream)

The following Last Call announcement was sent out (ends 2017-09-14):

From: The IESG
To: IETF-Announce
CC: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, draft-ietf-tsvwg-ecn-experimentation@ietf.org, spencerdawkins.ietf@gmail.com, Gorry Fairhurst , tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Explicit Congestion Notification (ECN) Experimentation) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Explicit Congestion
Notification (ECN) Experimentation'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-09-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This memo updates RFC 3168, which specifies Explicit Congestion
  Notification (ECN) as a replacement for packet drops as indicators of
  network congestion.  It relaxes restrictions in RFC 3168 that would
  otherwise hinder experimentation towards benefits beyond just removal
  of loss.  This memo summarizes the anticipated areas of
  experimentation and updates RFC 3168 to enable experimentation in
  these areas.  An Experimental RFC is required to take advantage of
  any of these enabling updates.  In addition, this memo makes related
  updates to the ECN specifications for RTP in RFC 6679 and for DCCP in
  RFC 4341, RFC 4342 and RFC 5622.  This memo also records the
  conclusion of the ECN Nonce experiment in RFC 3540, and provides the
  rationale for reclassification of RFC 3540 as Historic; this
  reclassification enables new experimental use of the ECT(1)
  codepoint.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5622: Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) (Experimental - IETF stream)

Explicit Congestion Notification (ECN) Experimentation

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.
This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards Track, PS.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This memo updates RFC 3168, which specifies Explicit Congestion
  Notification (ECN) as a replacement for packet drops as indicators of
  network congestion.  It relaxes restrictions in RFC 3168 that would
  otherwise hinder experimentation towards benefits beyond just removal
  of loss.  The memo summarizes the anticipated areas of
  experimentation and updates RFC 3168 to enable experimentation in
  these areas.  An Experimental RFC is required to take advantage of
  any of these enabling updates.  In addition, this memo makes related
  updates to the ECN specifications for RTP in RFC 6679 and for DCCP in
  RFC 4341, RFC 4342 and RFC 5622.  The memo also records the
  conclusion of the ECN Nonce experiment in RFC 3540, and provides the
  rationale for reclassification of RFC 3540 as Historic; this
  reclassification enables new experimental use of the ECT(1)
  codepoint.

Working Group Summary:

The document was adopted by the working group to enable two specific pieces of work - ABE (now in TCPM) and L4S (now a working group item in TSVWG). Both these items of work curently have experimental status, yet seek to modify the ECN specification produced by TSVWG - specifically to obsolete the ECN NONCE. This topic has been discussed in TSVWG over many years and it is finally the consensus that the experiment has concluded and that the ECN NONCE specification is no longer recommended for deployment.

Document Quality: The document is ready to publish.

Personnel:

Who is the Document Shepherd?  Gorry Fairhurst

Who is the Responsible Area Director? Spencer Dawkins

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has received significant review by several people in TSVWG - both as an individual submission and as as WG draft, including detailed feedback from M Welzl and B Briscoe. Minor updates were made in response to last call comments and this document is therefore ready to proceed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. This draft has been reviewed many times.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes. The author confirms that he knows of no IPR for this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures known.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document has been presented to the WG and there was consensus on the document during WGLC. Minor issues were raised, and changes have been incorporated in this revision of the ID.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are two downrefs in this draft that is intended to become a proposed status RFC:
- This draft explains the end of the ECN Nonce experiment described in RFC 3540, and hence normatively references RFC 3540.
- DCCP sender ECN behavior needs to be updated in 3 RFCs, one of which is Experimental - RFC 5622.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

After analysis of the deployment and purpose of ECM NONCE, this doc is the supporting RFC for a change of RFC3540 (EXP) status to Historic.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
This memo does not make a request to IANA.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This memo does not include a request for a new registry to IANA.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

None.

Explicit Congestion Notification (ECN) Experimentation

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.
This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards Track, PS.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This memo updates RFC 3168, which specifies Explicit Congestion
  Notification (ECN) as a replacement for packet drops as indicators of
  network congestion.  It relaxes restrictions in RFC 3168 that would
  otherwise hinder experimentation towards benefits beyond just removal
  of loss.  The memo summarizes the anticipated areas of
  experimentation and updates RFC 3168 to enable experimentation in
  these areas.  An Experimental RFC is required to take advantage of
  any of these enabling updates.  In addition, this memo makes related
  updates to the ECN specifications for RTP in RFC 6679 and for DCCP in
  RFC 4341, RFC 4342 and RFC 5622.  The memo also records the
  conclusion of the ECN Nonce experiment in RFC 3540, and provides the
  rationale for reclassification of RFC 3540 as Historic; this
  reclassification enables new experimental use of the ECT(1)
  codepoint.

Working Group Summary:

The document was adopted by the working group to enable two specific pieces of work - ABE (now in TCPM) and L4S (now a working group item in TSVWG). Both these items of work curently have experimental status, yet seek to modify the ECN specification produced by TSVWG - specifically to obsolete the ECN NONCE. This topic has been discussed in TSVWG over many years and it is finally the consensus that the experiment has concluded and that the ECN NONCE specification is no longer recommended for deployment.

Document Quality: The document is ready to publish.

Personnel:

Who is the Document Shepherd?  Gorry Fairhurst

Who is the Responsible Area Director? Spencer Dawkins

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has received significant review by several people in TSVWG - both as an individual submission and as as WG draft, including detailed feedback from M Welzl and B Briscoe. Minor updates were made in response to last call comments and this document is therefore ready to proceed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. This draft has been reviewed many times.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes. The author confirms that he knows of no IPR for this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures known.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document has been presented to the WG and there was consensus on the document during WGLC. Minor issues were raised, and changes have been incorporated in this revision of the ID.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

None.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
This memo does not make a request to IANA.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This memo does not include a request for a new registry to IANA.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

None.

The WGLC has concluded for this ID, with comments. A revised ID has been published that reflects current WG Consensus.

The document shepherd (Gorry) will now prepare a write-up.