Explicit Congestion Marking in MPLS
draft-ietf-tsvwg-ecn-mpls-02

[Ballot comment]
Note that I have some concerns in the wording and general structure of the doc and am working w/ the authors. I'd expect to see a revised draft in a couple weeks.

Most issues are working out issues of the history of this space and subsequent word choice and explanatory text.

(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?

The document Shepherd is Lars Eggert . I have
personally reviewed this document and believe it to be ready for publication.

(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?

The document has been reviewed in both the TSVWG and MPLS working groups by
ECN and MPLS experts.

(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?
     
The document has had adequate review.

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

I have no such concerns.

(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?
     
WG consensus is clear but not overly strong. (It rarely is in TSVWG.)     

(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.)
     
Nothing of the sort.     

(1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html 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?

The document has no nits.

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

References are in order.

(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 [RFC2434].  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?

IANA considerations are in order.

(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?

The document has no such sections.

(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

          RFC 3270 defines how to support the Diffserv architecture in MPLS
          networks, including how to encode Diffserv Code Points (DSCPs) in
          an MPLS header.  RFC 3270 makes no statement about how Explicit
          Congestion Notification (ECN) marking might be encoded in the
          MPLS header.  This draft defines how an operator might define
          some of the EXP codepoints for explicit congestion notification,
          without precluding other uses.

      Working Group Summary

          This document touches on subjects that fall into both the MPLS
          and TSVWG working groups. The agreement between the WGs was that
          the work would occur in TSVWG due to its expertise with ECN,
          with a joint Last Call in both working groups. This approach was
          followed.

      Document Quality

          This document has been reviewed in both the MPLS and TSVWG working
          groups. The document shepherd is not aware of any existing
          implementations.

      Personnal
     
          Lars Eggert  reviewed this document for
          the IESG.