Hi Huub and authors of draft-betts-itu-oam-ach-code-point, Thanks for issuing a publication request and supplying the Secretariat with a write-up. The document is entered in the datatracker and you can see its status at http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ You suggested me as the sponsoring AD, so I will do the first steps to see how we should progress the draft. My process is from here on is as follows: - Review draft and shepherd write-up - Ask any questions and request a draft update if necessary - Consult the MPLS WG chairs and IESG about whether this needs to be run through the MPLS WG and whether RFC 4929 applies - Issue IETF last call if applicable Please note that I am travelling for the next two weeks at the ITU-T SG15 meeting, so my ability to process this work will be reduced: I also have to continue to do normal AD work-load, and the output of IETF working groups takes precedence over AD sponsored documents. Thanks, Adrian > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Huub > helvoort > Sent: 01 December 2011 21:17 > To: Adrian Farrel > Cc: draft-betts-itu-oam-ach-code-point@xxxxxxxxxxxxxx; The IESG; Ietf@xxxxxxxx > Subject: Request to publish draft-betts-itu-oam-ach-code-point-01.txt > > Document Writeup for draft-betts-itu-oam-ach-code-point-01.txt > > As required by RFC-to-be draft-iesg-sponsoring-guidelines, this is the > current template for the Document Shepherd Write-Up for individual > submissions via the IESG. > > Changes are expected over time. This version is dated February 5, 2007. > > -- > > (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? > > Huub van Helvoort (Huub.van.Helvoort@xxxxxxxxxx) > Yes, I have reviewed the document and I believe it is ready for > forwarding to the IESG to be published. > > (1.b) Has the document had adequate review both from key members of > the interested community and others? Does the Document Shepherd > have any concerns about the depth or breadth of the reviews that > have been performed? > > The document was first posted on 16th October; no discussion has taken > place on any email lists. However, this draft is addressing a well know > issue that was first brought to the attention of the IETF in a request > from the director of the ITU-T in June 2010 requesting the assignment of > an ACh code point that would be used to run Ethernet based OAM on > MPLS-TP networks. The draft requests IANA to assign a code point from > the registry of Pseudowire Associated Channel Types. It does not make > any proposals to modify the MPLS data plane forwarding behaviour or of > the any IETF defined protocols. Therefore, review by the MPLS WG is not > required. > > (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? > > No. The purpose of the document is clear and the scope is limited to the > assignment of a code point for (restricted) use by the ITU-T. > > (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 interested community has discussed those issues and has > indicated that it still wishes to advance the document, detail > those concerns here. > > The issue of supporting an alternative set of OAM mechanisms for MPLS-TP > based on Ethernet OAM has been widely discussed without reaching any > firm conclusion. Note that more than 350,000 nodes have now been > deployed with Ethernet based OAM using a code point from the > experimental range. > > (1.e) How solid is the consensus of the interested community behind > this document? Does it represent the strong concurrence of a few > individuals, with others being silent, or does the interested > community as a whole understand and agree with it? > > This draft is requesting the assignment of an ACh code point that will > be used to run Ethernet based OAM on MPLS-TP networks. This protocol > has been defined in the ITU-T and should not be considered to be a MPLS > protocol and therefore should not subject to the provisions of RFC 4929. > This request is supported by a significant number of network operators. > However, discussion on the IETF list during the last call of > draft-sprecher-mpls-tp-oam-considerations indicates that other do not > support the view that aa alternative Ethernet based OAM mechanism is > required. > > (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.) > > None indicated, however see the discussion on the IETF list during the > last call of draft-sprecher-mpls-tp-oam-considerations. > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts > Checklist <http://www.ietf.org/id-info/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? > > No ID_nits found; the draft does not define a MIB or any protocols. > > (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]. > > The split is appropriate; the only normative references are to published > RFCs without any downwards references. > > (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 suggested a reasonable name for the new > registry? See [I-D.narten-iana-considerations-rfc2434bis]. 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? > > The IANA consideration section exists and is consistent. > > (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? > > There are no sections that use formal language. > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Writeup? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > > Relevant content can frequently be found in the abstract and/or > introduction of the document. If not, this may be an > indication that there are deficiencies in the abstract or > introduction. > > This document assigns an Associated Channel Type code point for carrying > Ethernet based Operations, Administration, and Management messages in > the MPLS Generic Associated Channel (G-ACh). > > Working Group Summary > > Was there anything in the discussion in the interested > community that is worth noting? For example, was there > controversy about particular points or were there decisions > where the consensus was particularly rough? Was the document > considered in any WG, and if so, why was it not adopted as a > work item there? > > This document is an individual submission via AD sponsorship aiming to > gain IETF consensus. It is not the product of a working group. > > This document assigns an Associated Channel Type code point for carrying > Ethernet based Operations, Administration, and Management messages in > the MPLS Generic Associated Channel (G-ACh). These OAM messages will be > used as an alternative mechanism to support OAM functions in a MPLS-TP > network. To date more than 350,000 nodes have been deployed using this > mechanism using a code point from the experimental range. > > This document does not contain technical details of OAM for MPLS-TP > networks, and does not make any comment on the judgement of the working > groups in their technical decisions. The document is concerned with the > wider issue of IETF policy and process. > > It is the opinion of the document shepherd that discussion of this > document on the working group lists would be a distraction from the > technical protocol work that the working groups need to do. > > Document Quality > > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to implement > the specification? Are there any reviewers that merit special > mention as having done a thorough review, e.g., one that > resulted in important changes or a conclusion that the document > had no substantive issues? If there was a MIB Doctor, Media > Type or other expert review, what was its course (briefly)? In > the case of a Media Type review, on what date was the request > posted? > > The Ethernet based OAM protocol that will run behind this code point has > been implemented by at least four vendors and more than 350,000 nodes > have been deployed. Multi-vendor inter-operability test have been > completed successfully. The draft does not specify a MIB or provides > any protocol details. > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf