Re: [Pce] Barry Leiba's No Objection on draft-ietf-pce-association-bidir-11: (with COMMENT)

Perfect; thanks, Rakesh.  I appreciate your taking my comments into account.

Barry

On Fri, Feb 5, 2021 at 1:08 PM Rakesh Gandhi <rgandhi.ietf@gmail.com> wrote:
>
> Thanks Barry for the review.
> Agree with your proposed text. Attaching the files with the changes that I will upload.
>
> Thanks,
> Rakesh
>
>
> On Tue, Feb 2, 2021 at 1:23 PM Barry Leiba via Datatracker <noreply@ietf.org> wrote:
>>
>> Barry Leiba has entered the following ballot position for
>> draft-ietf-pce-association-bidir-11: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-pce-association-bidir/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thanks for an easy read.  I just have two very small comments:
>>
>> — Abstract —
>>
>>    The Path Computation Element Communication Protocol (PCEP) provides
>>    mechanisms for Path Computation Elements (PCEs) to perform path
>>    computations in response to Path Computation Clients (PCCs) requests.
>>    The Stateful PCE extensions allow stateful control of Multiprotocol
>>    Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
>>    (LSPs) using PCEP.
>>
>> Hm.  I’m not clear here: Does this have something to do with path computation?
>>
>> He-he... seriously, I understand the repetition, given the expansion of the
>> abbreviations.  What I wonder is whether it’s necessary to put all those terms
>> into the Abstract, given that the expansion of "PCEP" already includes "path
>> computation element".  What do you think about shortening the Abstract thus?:
>>
>> SUGGESTION
>>    This document defines Path Computation Element Communication Protocol
>>    (PCEP) extensions for grouping two unidirectional MPLS-TE Label
>>    Switched Paths (LSPs), one in each direction in the network, into an
>>    Associated Bidirectional LSP.  The mechanisms defined in this
>>    document can be applied using a Stateful PCE for both PCE-Initiated
>>    and PCC-Initiated LSPs, as well as when using a Stateless PCE.  The
>>    procedures defined are applicable to the LSPs using RSVP-TE for
>>    signaling.
>> END
>>
>> I note that "MPLS-TE", "PCE", and "RSVP-TE" are all in the RFC Editor’s list of
>> abbreviations that don’t need expansion... though, of course, you can put the
>> expansions back in if you prefer.  I also note that "PCC" is not, but I think
>> it would be awkward to include the expansion of "PCC" here, so maybe we can
>> manage without it in the Abstract.
>>
>> — Section 3.1 —
>>
>>    Both endpoint nodes act as a PCC.
>>
>> Nit: "Both" is plural, so either "Both endpoint nodes act as PCCs." or "Each
>> endpoint node acts as a PCC."
>>
>>
>>
>> _______________________________________________
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce