MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
RFC 7212

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: 'MPLS Generic Associated Channel (G-ACh) Advertisement Protocol' to Proposed Standard (draft-ietf-mpls-gach-adv-08.txt)

The IESG has approved the following document:
- 'MPLS Generic Associated Channel (G-ACh) Advertisement Protocol'
  (draft-ietf-mpls-gach-adv-08.txt) as Proposed Standard

This document is the product of the Multiprotocol Label Switching Working
Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mpls-gach-adv/


Technical Summary

   The MPLS Generic Associated Channel (G-ACh) provides an auxiliary
   logical data channel associated with a Label Switched Path (LSP), a
   pseudowire, or a section (link) over which a variety of protocols may
   flow.  These protocols are commonly used to provide Operations,
   Administration, and Maintenance (OAM) mechanisms associated with the
   primary data channel.  This document specifies simple procedures by
   which an endpoint of an LSP, pseudowire, or section may inform the
   other endpoints of its capabilities and configuration parameters, or
   other application-specific information.  This information may then be
   used by the receiver to validate or adjust its local configuration,
   and by the network operator for diagnostic purposes.

Working Group Summary

  There is good support in the working group for this draft. There 
  were no significant controversies in progression of the document. 
  Last call comments were constructive technical comments and the 
  document has been updated accordingly. . 

Document Quality: 

  For this document we seem to have an chicken and egg problem. 
  We know of intended implementations, it seems that since the 
  implementation delta is rather small the implementers in this case 
  has decided to wait for the allocation of the ACh code point 
  before implementing. 

  The document received extensive (agressive?) review from the 
  responsible AD and has been updated to address all comments
  raised.

Personnel: 

  Loa Andersson (loa@pi.nu) is the document shepherd. 
  Adrian Farrel (adrian@olddog.co.uk) is the responsible AD. 

RFC Editor Note

Please update the 2119 boilerplate to include "NOT RECOMMENDED"

---

Section 6.1: 
OLD: "the following values MAY supported" 
NEW: "the following values MAY be supported"