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

[Barry Leiba via Datatracker <[e-mail]>]

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."