Subject: [Pce] Eric Rescorla's No Objection on draft-ietf-pce-pce-initiated-lsp-10: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Aug 2017 16:10:32 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-pce-pce-initiated-lsp-10: 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-pce-initiated-lsp/

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

Document: draft-ietf-pce-pce-initiated-lsp-10.txt

Note: I reviewed this document on my experimental Phabricator instance.
You can see the comments inline at:

  https://mozphab-ietf.devsvcdev.mozaws.net/D20

It may just be my unfamiliarity with this system, but it's not clear
to me what the security model is here for the delegation. As I
understand this document the PCC just tells the PCE that it has
delegated the LSP to it, and then the PCE can make the LSP via the
normal procedures. But what is it that tells the rest of the system
that the PCC is allowed to manage that LSP. I didn't get that out of
this document or out of a cursory look at RFC 8051.

INLINE COMMENTS
Line 162
   A possible use case is a software-driven network, where applications
   request network resources and paths from the network infrastructure.
NIT: isn't the term here "software-defined network"

Line 218
   all state related to the LSP and sends a PCRpt for the removed state.
   See details in Section 5.4.
A diagram would sure help here.

Line 263
   Unassigned bits are considered reserved.  They MUST be set to 0 on
   transmission and MUST be ignored on receipt.
As I understand this text, you are merely adding a new code point to flags. I'm
not sure it's necessary to reproduce the PDU, but if you do, you should clarify
that th only change you are making is adding a new field. Perhaps on line 249
"It is reproduced here with the addition of the new I bit"

Line 278
   and the LSP objects, and MAY contain other objects, as discussed
   later in this section.
Is the syntax here supposed to be ABNF? If so, you need a citation to the
syntax".

Line 337
      create an LSP.  If set to 1, it indicates a request to remove an
      LSP.
I have the same comment here about repeating PDU.

Line 436
   The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included
   here for easy reference.
This is good text, and is what I would encourage the other places you replicate
PDUs from other documents.