Subject: Request to publish draft-ietf-tsvwg-ecn-tunnel-08 by the TSVWG.

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 06 May 2010 13:21:40 +0100

This note includes a request to publish a document by the TSVWG to the 
TSV ADs. The current version of this document is:

http://tools.ietf.org/html/draft-ietf-tsvwg-ecn-tunnel-08

Thanks to all who participated in reviewing and contributing text to 
this draft!

Best wishes,

Gorry Fairhurst

----

As required by RFC 4858, this is the current template for the Document 
Shepherd Write-Up.

This version is dated September 17, 2008.

   (1.a) Who is the Document Shepherd for this document? Has the
         Document Shepherd personally reviewed this version of the
         document and, in particular, does he or she believe this
         version is ready for forwarding to the IESG for publication?

Gorry Fairhurst, TSVWG Chair

   (1.b) Has the document had adequate review both from key WG members
         and from key non-WG members? Does the Document Shepherd have
         any concerns about the depth or breadth of the reviews that
         have been performed?

Yes. This document has been presented in TSVWG, and received comments 
and feedback. It has also been presented to the IPsec community. The 
WGLC was also copied to PCN, where some of the draft text originated.

   (1.c) Does the Document Shepherd have concerns that the document
         needs more review from a particular or broader perspective,
         e.g., security, operational complexity, someone familiar with
         AAA, internationalization or XML?

This needs SecDir review, since this updates IPsec. A Secdir review was 
requested during WGLC, but none emerged. It is expected that appropriate 
security reviews will be sought by the AD.

   (1.d) Does the Document Shepherd have any specific concerns or
         issues 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. Has an IPR disclosure related to this document
         been filed? If so, please include a reference to the
         disclosure and summarize the WG discussion and conclusion on
         this issue.

No.

   (1.e) 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?

There is good consensus to progress ECN work, and support for this 
particular work item.

   (1.f) 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
         entered into the ID Tracker.)

No.

   (1.g) Has the Document Shepherd personally verified that the
         document satisfies all ID nits? (See the Internet-Drafts
         Checklist and http://tools.ietf.org/tools/idnits/).
         Boilerplate checks are
         not enough; this check needs to be thorough. Has the document
         met all formal review criteria it needs to, such as the MIB
         Doctor, media type and URI type reviews?

OK.
Some sections need to be removed prior to publication, as marked.

   (1.h) Has the document split its references into normative and
         informative? 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
         strategy for their completion? Are there normative references
         that are downward references, as described in [RFC3967]? If
         so, list these downward references to support the Area
         Director in the Last Call procedure for them [RFC3967].

Yes.

   (1.i) Has the Document Shepherd verified that the document IANA
         consideration section exists and is consistent with the body
         of the document? If the document specifies protocol
         extensions, are reservations requested in appropriate IANA
         registries? Are the IANA registries clearly identified? If
         the document creates a new registry, does it define the
         proposed initial contents of the registry and an allocation
         procedure for future registrations? Does it suggest a
         reasonable name for the new registry? See [RFC5226]. If the
         document describes an Expert Review process has Shepherd
         conferred with the Responsible Area Director so that the IESG
         can appoint the needed Expert during the IESG Evaluation?

This memo includes no request to IANA.

   (1.j) Has the Document Shepherd verified that sections of the
         document that are written in a formal language, such as XML
         code, BNF rules, MIB definitions, etc., validate correctly in
         an automated checker?

Not applicable.

   (1.k) 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 document redefines how the explicit congestion notification (ECN) 
field of the IP header should be constructed on entry to and exit from 
any IP in IP tunnel.  It updates RFC3168, aligning this with RFC4301 for 
IPsec ECN processing.  It also updates RFC4301 to add new behaviours for 
previously unused combinations of inner and outer header. This update is 
thought to benefit work on PCN and align IP tunnel behaviour with that 
of IPSec.

      Working Group Summary

The WG contributed to this work and participated in review of this 
document. It has the support of the TSVWG.

      Document Quality

There are no implementation reports for this specification, but 
interoperability issues were discussed in the WG and the current 
specification is thought ready for deployment. Most of the final 
discussion was on good engineering practice for the future use of the 
ECN codepoints. David Black assisted in performing this review and in 
review of the normative wording.