Subject: [Pce] Fw: Please publish draft-ietf-pce-ds-te-02.txt

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 3 Nov 2008 17:47:11 -0000

FYI, this I-D is now with the AD for review.
Adrian
----- Original Message ----- 
From: "JP Vasseur" <[email-masked]>
To: "Ross Callon" <[email-masked]>; "The IESG" 
<[email-masked]>
Cc: "David Ward" <[email-masked]>; "Adrian Farrel" <[email-masked]>; 
"Siva Sivabalan (msiva)" <[email-masked]>
Sent: Monday, November 03, 2008 3:23 PM
Subject: Please publish draft-ietf-pce-ds-te-02.txt

> Proto-write-up for draft-ietf-pce-ds-te-02.txt
>
> Intended status : Standards Track
>
>> (1.a)  Who is the Document Shepherd for this document?  Has the
>>        Document Shepherd personally reviewed this version of the
>>        document and, in particular, does he or she believe this
>>        version is ready for forwarding to the IESG for publication?
>
> JP Vasseur is the document shepherd.
> He has personally reviewed the I-D and believes it is ready for
> forwarding to the IESG for publication.
>
>> (1.b)  Has the document had adequate review both from key WG members
>>        and from key non-WG members?  Does the Document Shepherd have
>>        any concerns about the depth or breadth of the reviews that
>>        have been performed?
>
> The I-D was well discussed when first posted and then got stable fairly
> quickly.
>
>> (1.c)  Does the Document Shepherd have concerns that the document
>>        needs more review from a particular or broader perspective,
>>        e.g., security, operational complexity, someone familiar with
>>        AAA, internationalization or XML?
>
> No concerns.
>
>> (1.d)  Does the Document Shepherd have any specific concerns or
>>        issues with this document that the Responsible Area Director
>>        and/or the IESG should be aware of?  For example, perhaps he
>>        or she is uncomfortable with certain parts of the document, or
>>        has concerns whether there really is a need for it.  In any
>>        event, if the WG has discussed those issues and has indicated
>>        that it still wishes to advance the document, detail those
>>        concerns here.  Has an IPR disclosure related to this document
>>        been filed?  If so, please include a reference to the
>>        disclosure and summarize the WG discussion and conclusion on
>>        this issue.
>
> No issue specific issues.
>
> No IPR disclosures filed.
>
>> (1.e)  How solid is the WG consensus behind this document?  Does it
>>        represent the strong concurrence of a few individuals, with
>>        others being silent, or does the WG as a whole understand and
>>        agree with it?
>
> Good consensus, the document specifies fairly straightforward protocol
> extensions.
>
>> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>>        discontent?  If so, please summarise the areas of conflict in
>>        separate email messages to the Responsible Area Director.  (It
>>        should be in a separate email because this questionnaire is
>>        entered into the ID Tracker.)
>
> No threats. No discontent.
>
>> (1.g)  Has the Document Shepherd personally verified that the
>>        document satisfies all ID nits?  (See
>>        http://www.ietf.org/ID-Checklist.html and
>>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>>        not enough; this check needs to be thorough.  Has the document
>>        met all formal review criteria it needs to, such as the MIB
>>        Doctor, media type and URI type reviews?
>
> All checks made.
>
>> (1.h)  Has the document split its references into normative and
>>        informative?
>
> Yes.
>
> Are there normative references to documents that
>>        are not ready for advancement or are otherwise in an unclear
>>        state?  If such normative references exist, what is the
>>        strategy for their completion?  Are there normative references
>>        that are downward references, as described in [RFC3967]?  If
>>        so, list these downward references to support the Area
>>        Director in the Last Call procedure for them [RFC3967].
>
> No downward reference.
>
>> (1.i)  Has the Document Shepherd verified that the document IANA
>>        consideration section exists and is consistent with the body
>>        of the document?  If the document specifies protocol
>>        extensions, are reservations requested in appropriate IANA
>>        registries?  Are the IANA registries clearly identified?  If
>>        the document creates a new registry, does it define the
>>        proposed initial contents of the registry and an allocation
>>        procedure for future registrations?  Does it suggest a
>>        reasonable name for the new registry?  See [RFC2434].  If the
>>        document describes an Expert Review process has Shepherd
>>        conferred with the Responsible Area Director so that the IESG
>>        can appoint the needed Expert during the IESG Evaluation?
>
> The document requests extensions to the PCEP IANA registries.
> The IANA section looks good.
>
>> (1.j)  Has the Document Shepherd verified that sections of the
>>        document that are written in a formal language, such as XML
>>        code, BNF rules, MIB definitions, etc., validate correctly in
>>        an automated checker?
>
> A reference to draft-farrel-rtg-common-bnf is included in the document for
> the BNF used in this document.
>
> [OBJ-ORD] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
>             in Various Protocol Specifications", draft-farrel-rtg-
>             common-bnf-07.txt, November 2008.
>
>
> No tool has been used for verification.
>
>> (1.k)  The IESG approval announcement includes a Document
>>        Announcement Write-Up.  Please provide such a Document
>>        Announcement Write-Up.  Recent examples can be found in the
>>        "Action" announcements for approved documents.  The approval
>>        announcement contains the following sections:
>>
>>        Technical Summary
>>           Relevant content can frequently be found in the abstract
>>           and/or introduction of the document.  If not, this may be
>>           an indication that there are deficiencies in the abstract
>>           or introduction.
>
>   The Internet Draft [PCEP-ID] specifies the Path Computation Element
>   communication Protocol (PCEP) for communications between a Path
>   Computation Client (PCC) and a Path Computation Element (PCE), or
>   between two PCEs, in compliance with [RFC4657].
>
>   Differentiated Service aware MPLS Traffic Engineering (DS-TE)
>   addresses the fundamental requirement to be able to enforce different
>   bandwidth constraints for different classes of traffic. It describes
>   mechanisms to achieve per-class traffic engineering, rather than on
>   an aggregate basis across all classes by enforcing Bandwidth
>   Constraints (BCs) on different classes. Requirements for DS-TE and
>   the associated protocol extensions are specified in [RFC3564] and
>   [RFC4124] respectively.
>
>   As per [RFC4657], PCEP must support traffic class-type as an MPLS TE
>   specific constraint. However, in the present form, PCEP [PCEP-ID]
>   does not have the capability to specify the class-type in the path
>   computation request.
>
>   In this document, we define a new PCEP object called CLASSTYPE which
>   carries the class-type of the TE LSP in the path computation request.
>   During path computation, a PCE uses the class-type to identify the
>   bandwidth constraint of the TE-LSP.
>
>>        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
>>           rough?
>
> Good support and no controversy.
>
>>        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?
>
> No known implementation of the I-D but several mentioned that they were
> planning to implement the protocol extensions specifies in the document.
> Furthermore, the protocol extensions are very straightforward.
>
> Thanks.
>
> JP.
> 

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce