The IESG has approved the following document: - 'Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel' (draft-ietf-mpls-retire-ach-tlv-03.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact person is Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv/ Technical Summary The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the Associated Channel Header (ACH) between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated IANA registry. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There is a strong support for this document in the working group and it has been has been well reviewed. 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? Since this is removing an unused "feature" from RFC 5586 the responsible AD believes that the *absence* of implementations is required for approval of the draft - if there were implementations, we shouldn't approve the draft. The responsible AD believes (without practicing unlicensed law) that it's not possible to have IPR on not implementing part of an approved standards-track specification (and if IPR was claimed on not implementing parts of a standards-track specification, the prior art would be overwhelming). Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are <TO BE ADDED BY THE AD>.' Loa Andersson is the document shepherd. Spencer Dawkins is the responsible AD, since both Routing ADs are co-authors on this document.
