Perfect; thanks, Rakesh. I appreciate your taking my comments into account.
Barry On Fri, Feb 5, 2021 at 1:08 PM Rakesh Gandhi <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
