[PWE3] Publication request for draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt
"Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> Thu, 26 July 2012 14:07 UTC
Return-Path: <matthew.bocci@alcatel-lucent.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACC421F8776; Thu, 26 Jul 2012 07:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.791
X-Spam-Level:
X-Spam-Status: No, score=-107.791 tagged_above=-999 required=5 tests=[AWL=-1.543, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HsOXim9IgZv; Thu, 26 Jul 2012 07:07:04 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 31ABE21F876E; Thu, 26 Jul 2012 07:07:03 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6QE70oA012037 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Jul 2012 16:07:00 +0200
Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.36]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 26 Jul 2012 16:07:00 +0200
From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
To: Stewart Bryant <stbryant@cisco.com>, The IESG <iesg-secretary@ietf.org>
Date: Thu, 26 Jul 2012 16:06:58 +0200
Thread-Topic: Publication request for draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt
Thread-Index: Ac1rN+wmpTaxik89TWCNclEXLjJ/uA==
Message-ID: <CC370D92.30A75%matthew.bocci@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CC370D9230A75matthewboccialcatellucentcom_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Cc: "pwe3@ietf.org" <pwe3@ietf.org>
Subject: [PWE3] Publication request for draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jul 2012 14:07:06 -0000
The PWE3 working group requests publication of draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt as a standards track RFC. Please find the document write-up below. Best regards, Matthew draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt Document Shepherd Write-Up (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. This is appropriate as the draft describes a set of procedures for interworking defect notifications between Ethernet attachment circuits and PWs that will have interoperability implications. The intended status is properly indicated. (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 document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects. Working Group Summary Solutions for mapping OAM messages related to defect notifications from attachement circuits to PWs for ATM, FR, and TDM services were specified in RFC6310. This RFC did not cover Ethernet attachment circuits because of a perception at the time that Ethernet OAM mechanisms were less widely deployed and their standardization was on-going. The WG decided to handle the Ethernet case in a separate draft. This was considered to be an important work item by the PWE3 working group, and there were a number of requests to roll this working into the draft that became RFC6310. However, ultimately the consensus was to progress the Ethernet case separately to not further delay RFC6310. The document received two working group last calls, the second as a result of IPR declaration 1781. The second WG last call resulted in the security section being improved, but no issues were raised about the IPR declaration. Document Quality Previous PW deployment surveys (see draft-ietf-pwe3-pw-vccv-impl-survey-results-00) have indicated that the majority of PWs are Ethernet, and therefore standardizing the interworking of defect notifications for emulated Ethernet services is expected to be of significant interest to the IETF and the operator community in general. There are believed to be numerous implementations and deployments of Ethernet OAM mechanisms referred to in this draft, including cases where the Ethernet service is supported over PWs and where OAM interworking is used. The document does not specify any MIB changes or additions which would need review. Personnel The document shepherd is Matthew Bocci (matthew.bocci@alcatel-lucent.com) The responsible Area Director is Stewart Bryant (stbryant@cisco.com) (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 shepherd reviewed the document and provided detailed technical and editorial comments. This were addressed by the authors before progressing the draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has received adequate review. The document has received significant review by the WG over a number of years and received a number of comments during WG last call. (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 further review required. (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. No specific concerns. (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. Each author listed in the Authors Addresses section has indicated that they are not aware of any IPR that has not been declared in accordance with BCP 78 and 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR declaration (1781) that was made after the original WG last call. The document was given a second WG last call as a result of this. There were no issues raised as a result of this. (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? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. It has been discussed over a period of a number of years, both in face to face IETF meetings and on the list. It has also been through two working group last calls with comments raised at each. (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.) None indicated. (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. Yes. There is one I-D nits warning related to some pages with too many lines. This results in I-D Nits generating an additional false comments. There are also a few spelling or gramatical errors. These should be fixed before publication. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no relevant formal review criteria. (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 is a downward normative reference to the published MetroEthernet Forum specification MEF16. It is reasonable to require conformance to MEF16 for any interworking between PW OAM and MEF16. (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. This document does not change the status of any existing RFCs. (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). There are no IANA actions. (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. There are no IANA actions. (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. There are no sections containing formal language that needs reviewing.
- [PWE3] Publication request for draft-ietf-pwe3-mp… Bocci, Matthew (Matthew)