Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
RFC 7150

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>,
    pce mailing list <pce@ietf.org>,
    pce chair <pce-chairs@tools.ietf.org>
Subject: Protocol Action: 'Conveying Vendor-Specific Constraints in the Path Computation Element communication Protocol' to Proposed Standard (draft-ietf-pce-vendor-constraints-11.txt)

The IESG has approved the following document:
- 'Conveying Vendor-Specific Constraints in the Path Computation Element
   communication Protocol'
  (draft-ietf-pce-vendor-constraints-11.txt) as Proposed Standard

This document is the product of the Path Computation Element Working
Group.

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-pce-vendor-constraints/


Technical Summary

   The Path Computation Element Protocol (PCEP) is used to convey path
   computation requests and responses between Path Computation Clients
   (PCCs) and Path Computation Elements (PCEs), and also between
   cooperating PCEs.  In PCEP the path computation requests carry
   details of the constraints and objective functions that the PCC
   wishes the PCE to apply in its computation.

   This document defines a facility to carry vendor-specific information
   in PCEP using a dedicated object and a new Type-Length-Variable that
   can be carried in any existing PCEP object.

Working Group Summary

   No strong controversy on the document, but the comment about 
   the actual need of defining proprietary fields within a standard 
   protocol came up several times.

Document Quality

  Some implementations claim to use the extensions defined in the I-D.

Personnel

  Julien Meuric is the Document Shepherd.
  Stewart Bryant is the Responsible Area Director.

RFC Editor Note

Section 1
New text at the end of the section

NEW
   It should be noted that by the very definition of "vendor-specific",
   the inclusion of either a Vendor Information object or the VENDOR-
   INFORMATION-TLV implies an inability to interoperate at a functional
   level with implementations from other vendors unless there is some
   cooperation agreement between vendors.  Sections 2.1 and 3.1 discuss
   backward compatibility which indicates how these protocol constructs 
   are handled by implementations that either do not support them at 
   all, while text in Sections 2 and 3 describes how implementations 
   handle the constructs if they understand them, but do not support the
   embedded Enterprise Number that indicates to which vendor the 
   constructs apply.

   When vendor-specific information is used by an implementation, the
   vendor is encouraged to document the meaning of the information to
   encourage wider use and implementation.  In particular, when there is
   more general interest in a vendor-specific extension, the vendor is
   encouraged to bring it to the IETF for standardisation as a regular
   protocol construct moving it out of the vendor-specific space.
END
---
Section 9
OLD
   Thanks to Meral Shirazipour, Ramon Casellas, Cyril Margaria, Dhruv
   Dhody, and Julien Meuric for review and comments.
NEW
   Thanks to Meral Shirazipour, Ramon Casellas, Cyril Margaria, Dhruv
   Dhody, Julien Meuric, and Robert Sparks for review and comments.
END