[Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-pce-app-07: (with COMMENT)

["Alvaro Retana" <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-stateful-pce-app-07: 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-stateful-pce-app/



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

This document mostly presents application scenarios, which (by reference)
serve as motivation for draft-ietf-pce-stateful-pce.  However, there are
a couple of places (in Section 4) where the operation defined in
draft-ietf-pce-stateful-pce is used as part of the considerations.  For
example (from 4.1):

   Stateless and stateful PCEs can co-exist in the same network and be
   in charge of path computation of different types.  To solve the
   problem of distinguishing between the two types of PCEs, either
   discovery or configuration may be used.  The capability negotiation
   in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE
   address is configured on the PCC.

I see a circular dependency between this document and
draft-ietf-pce-stateful-pce, where the considerations here are expected
to motivate the extensions, but the specific extensions are used to
discuss “generic issues with stateful PCE deployments”.

Given that draft-ietf-pce-stateful-pce is a Normative Reference, I would
rather see this document come back for IESG Evaluation with/after
draft-ietf-pce-stateful-pce.  Note that draft-ietf-pce-stateful-pce is
still (AFAICT) under consideration in the WG.


I am not making this comment a DISCUSS because I don’t think that it
raises to the appropriate level (as only some parts of the document seem
to have the dependency), and we’ll have to wait for
draft-ietf-pce-stateful-pce to be processed before publication anyway. 
However, I think that the application scenarios and motivation for future
extensions should be able to be described without referring to the
extensions themselves — I would then like the authors, Shepherd and the
responsible AD to consider whether it is possible for this document to
stand on its own, or whether we need to process it with the extensions
draft.  Given that draft-ietf-pce-stateful-pce is still in the WG, I
think it is important for us to talk about it as this point.  I noted in
the Shepherd’s writeup that this document used to be “originally included
in the base stateful PCE protocol specification” (which I assume is
draft-ietf-pce-stateful-pce).

To be clear: I am not opposing the publication of this document (even
though the content could have been part of draft-ietf-pce-stateful-pce),
I just think that in the current form it should be processed/published
*with* draft-ietf-pce-stateful-pce.


[Mechanisms from I-D.ietf-pce-stateful-sync-optimizations and
I-D.ietf-pce-pce-initiated-lsp are also mentioned in similar ways, and
those drafts are also in process in the WG.  I’m focusing on
draft-ietf-pce-stateful-pce above just to make the point.]