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 <> Mon, 19 August 2013 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71D7811E82A6; Mon, 19 Aug 2013 09:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.465
X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nwlZvyzZC6qM; Mon, 19 Aug 2013 09:28:52 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 8B6A411E82BA; Mon, 19 Aug 2013 09:28:39 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
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)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.70.p1
Message-ID: <>
Date: Mon, 19 Aug 2013 09:28:39 -0700
Cc: mpls mailing list <>, mpls chair <>, RFC Editor <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Aug 2013 16:28:53 -0000

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

The IESG contact person is Spencer Dawkins.

A URL of this Internet Draft is:

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

  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 

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


   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.