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
