[Pce] Alvaro Retana's No Objection on draft-ietf-pce-association-diversity-12: (with COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-association-diversity-12: 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-diversity/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) §5.1: I-D.ietf-pce-association-group is not explicit about the "capability
exchange mentioned in this piece of text:

                 This capability exchange for the Disjointness
   Association Type (TBD1) MUST be done before using the disjointness
   association.  Thus the PCEP speaker MUST include the Disjointness
   Association Type in the ASSOC-Type-List TLV before using the Disjoint
   Association Group (DAG) in PCEP messages.

It seems to me that the exchange implies sending and receiving the Assoc-type,
but then the second sentence implies sending to be enough.  What is the
expected behavior?  Please reword.

(2) §5.2 says, while defining the T flag, says that "if disjoint paths cannot
be found, PCE SHOULD return no path", but §5.6 reads:

   When the T flag is set (Strict disjointness requested), if
   disjointness cannot be ensured for one or more LSPs, the PCE MUST
   reply to a Path Computation Request (PCReq) with a Path Computation
   Reply (PCRep) message containing a NO-PATH object.

There is a conflict between the SHOULD and the MUST.

(3) TBD1 is used with 3 different names: "Disjoint Association Type (DAT)",
"Disjointness Association Type" and "Disjoint-group Association".  Please be
consistent.

(4) [nits]

s/DISJOINTNESS-CONFIGURATION-TLVSection 5.2/DISJOINTNESS-CONFIGURATION-TLV
(Section 5.2)

s/SHOULD NOT try to add/SHOULD NOT add

s/with example inA Section 5.5/with an example in Section 5.5

s/by Section 5.5either/by either

s/Setting P flag/Setting the P flag

s/case of network event/case of a network event