Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network
RFC 5493

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: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    ccamp mailing list <ccamp@ops.ietf.org>, 
    ccamp chair <ccamp-chairs@tools.ietf.org>
Subject: Document Action: 'Requirements for the Conversion 
         Between Permanent Connections and Switched Connections in a 
         Generalized Multiprotocol Label Switching (GMPLS) Network' to 
         Informational RFC 

The IESG has approved the following document:

- 'Requirements for the Conversion Between Permanent Connections and 
   Switched Connections in a Generalized Multiprotocol Label Switching 
   (GMPLS) Network '
   <draft-ietf-ccamp-pc-and-sc-reqs-06.txt> as an Informational RFC

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-06.txt

Technical Summary

   From a Carrier perspective, the possibility of turning a Permanent
   Connection (PC) into a Soft Permanent Connection (SPC) and vice
   versa, without actually affecting Data Plane traffic being carried
   over it, is a valuable option.  In other terms, such operation can be
   seen as a way of transferring the ownership and control of an
   existing and in-use Data Plane connection between the Management
   Plane and the Control Plane, leaving its Data Plane state untouched.

   This informational document sets out the requirements for such  
   procedures within a Generalized Multiprotocol Label Switching 
   (GMPLS) network.

Working Group Summary

   There were no problems with consensus for this document.

   In the early stages there were some very strong opinions about the
   value of this work. Some vendors and operators did not believe that
   the function would be useful in the networks they build. However,
   over time, other vendors and operators strongly supported the
   function, and since it is described as an optional function in
   equipment and deployment, the working group did not object to this
   work proceeding. See proto writeup by Deborah Brungard. 

Document Quality

   This is a requirements specification, and cannot be implemented. 
   Note that work is already in progress within the CCAMP working group
   to develop protocol solutions.

Personnel

   Deborah Brungard is the Document Shepherd for this document. Ross
   Callon is the Responsible Area Director. There are no IANA
   actions for this document. 

RFC Editor Note

   Please move the "Conventions used in this document" to be at the
   end of section 1 (introduction), as section 1.1, and please replace
   its text with the following text:

   NEW
     Although this requirements document is an informational document not
     a protocol specification, the key words "MUST", "MUST NOT",
     "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
     "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
     interpreted as described in RFC 2119 [RFC2119] for clarity of
     requirement specification.

   In section 6, please make the following substitution:

   OLD
     If SNMP MIBs are used for configuration, then the Management Plane
     should support authentication for PC-SC configuration changes as
     specified in [RFC3414].

   NEW
     The Management Plane interactions MUST be supported through
     protocols that can offer adequate security mechanisms to secure
     the configuration and protect the operation of the devices that
     are managed. These mechanisms MUST include at least cryptographic
     security and the ability to ensure that the entity giving access to
     configuration parameters is properly configured to give access only
     to those principals (users) that have legitimate rights to
     read/create/change/delete the parameters. IETF standard management
     protocols (Netconf [RFC4741] and SNMPv3 [RFC3410]) offer these
     mechanisms.