Last Call Review of draft-ietf-pce-stateful-pce-18
review-ietf-pce-stateful-pce-18-genart-lc-halpern-2017-02-16-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-pce-stateful-pce-??
Reviewer: Joel Halpern
Review Date: 2017-02-16
IETF LC End Date: 2017-02-28
IESG Telechat date: 2017-03-16

Summary:

Major issues:

Minor issues:
   At the end of section 5.4, the text talks about a PCE accepting status
   updates even if the  stateful capability has not been negotiated.  Which is
   fine.  But as written, the text seems to say that doing so means that the
   PCE will be able to "build and maintain an up to date view of the state of
   the PCC's LSPs".  However, if the capability has not been negotiated, I do
   not see how the PCE can count on getting full and timely state reports. 
   Trying to infer why a PCC is sending such a report in the absence of the
   agreement seems problematic.

    This comment may be a misunderstanding or mis-expectation on my part.  I
    would have expected one of the ways o using an active PCE is to have the
    PCE decide (under suitable circumstances) that an LSP is needed between two
    PCCs.  As far as I can tell, the text in section 5.8.2 and 5.8.3 prohibits
    that.  A PCE is only allowed to send an LSP Update Request (in a PCUpd
    message) for an LSP that has been delegated to it.  At that point I thought
    that a PCC could delegate a block of unsetup LSPs to the PCE.  But then
    looking at 5.8.2, the text states that for each delegation, the PCC must
    request an initial path.  That seems to prohibit delegating a block of LSPs
    for future updates.  Is the intention to prohibit the driving of LSP
    creation from the PCE?

    I have looked but I can not find the text explaining the significance and
    use of the Symbolic path name.  It is mandated by the draft.  There seems
    to be an implicit assumption taht it is needed by the PCE.  If the
    explanation of how or why it is needed is not present, it should be.

Nits/editorial comments:
    Should the text on the S bit in section 7.3 (the LSP Object definition)
    note that it should be set to 0 on all messages sent by the PCE?  Should
    that also be stated for the R bit?  And the O bits?

  Section 9.2 seems very odd.  It states that the IETF "SHOULD" do some
  additional work.  I understand why teh work is needed.  But this does not
  seem to match the RFC 2119 meaning of SHOULD as it does not apply to eitehr
  the implementor or the implementation.