Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel
RFC 7026

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    mpls mailing list <mpls@ietf.org>,
    mpls chair <mpls-chairs@tools.ietf.org>
Subject: Protocol Action: 'Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel' to Proposed Standard (draft-ietf-mpls-retire-ach-tlv-03.txt)

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.