Subject: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pcep-extensions-15: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 12 Nov 2019 15:56:32 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-gmpls-pcep-extensions-15: 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-gmpls-pcep-extensions/

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

Thank you for addressing my Discuss points!

I do have some additional comments on the -15.

Section 2.3

I'm still a bit concerned that the references linked from Table 4 may not
provide a clear description of what count as Traffic Parameters for our
purposes (and how they are encoded), but not in a way that I can express
more concretely.  Perhaps this is made clear by some RSVP-TE documents
with which I am not familiar.

ection 2.5.1

   root and other endpoints TLVs are the leaves.  The root endpoint MUST
   be the same for all END-POINTS objects.  If the root endpoint is not

I'm not sure how broadly scoped this restriction is -- it is, e.g., per-LSP?

Section 2.5.2.5

   with L bit cleared.  At most 2 LABEL_SET TLVs MAY be present with the
   O bit set, with at most one of these having the U bit set and at most
   one of these having the U bit cleared.  For a given U bit value, if

This went MUST->MAY in this rev, though I think it might be fine to just use
a lowercase "may", since the requirements language doesn't map terribly well
to the restriction we're making.