Path Computation Element (PCE) Communication Protocol Generic Requirements
draft-ietf-pce-comm-protocol-gen-reqs-07

Less concrete issues from Gen-ART review by Robert Sparks:

ISSUE 2:
  The extensibility requirements demand arbitrary objective
  functions. A discussion of the security implications of this
  requirement is needed. There are probably additional requirements
  on the protocol to be identified focusing on mitigating the risk
  of, for example, a PCC using complex objetives to intentionally drive
  a PCE into resource exhaustion. Does the protocol need to give the  PCE
  tools to say "I tried to do that, but it's turning out to be harder
  than my policies allow."? 

ISSUE 4:
  There are several requirements of PCEs that have been captured
  here as requirements of the PCECP. Section 6.1.15 requires that
  the protocol "scale well", where it really means that the system
  using the protocol scales well. The numbers in this section are
  capacity and performance numbers for a PCE, and they are useful
  when designing the PCECP to make sure the protocol itself makes
  achieving those numbers sane. This section should be reworded to
  make this obvious.

  Similarly, section 8 should separate requirements on the protocol
  from the motivational requirements on CPE implementations (2119
  words shouldn't be used in that motivation).

ISSUE 5 (Apologies if my lack of domain expertise led me to miss
         something obvious here):
  Section 6.3.3 requires the protocol to carry information about
  the state of the network to the PCE that would normally come from
  the TED. Does this not introduce security concerns? Could a PCC
  use this poison CPE calculations for other PCCs? If this capability
  exists, there needs to be discussion about how the data gets used
  by the PCE (does it cache it?), but that discussion doesn't belong
  in this document. I suggest at a minimum that some discussion of
  the ramifications of this capability be included in the security
  consideration section of this document.
ISSUE 7:
   The purpose of 6.2.1 is not clear. What is the real requirement
   being placed on the protocol, and how can we evaluate the protocol
   against that requirement. If there are no such explicit  requirements,
   I suggest this be rewritten as advice on where the protocol is  expected
   to be used and not use 2119 terms at all.
   I'm particularly puzzled about what impact operating in environments
   including
    "- packet and non-packet networks"
   is intended to have on the protocol itself.

Nits:
The draft passes the idnits checker (in spirit at least).
The checker complains about the reference to 2119 in the
boilerplate, and the unexpected use of
"Authors' and Contributors' Addresses".

These nits are in no particular order:

NIT 1:
  The references to I-Ds that are works in progress do not
  include draft names, Please add them.

NIT 2:
   Please expand PCE in the title.

NIT 3:
  Section 6.1.6 uses "notification message" which is not yet
  defined - a forward reference would be helpful.

NIT 3:
   Section 6.1.11 requires unsolicited notifications, but doesn't
   really define them. Are these reliable messages? Do they get
   responses?  More detail about what's really being required would
   make the document more useful.

NIT 4:
  The final requirement in 6.1.15 is redundant with requirements
  in both 6.1.8 and section 8. Consolodating those would make the
  document stronger.

NIT 5:
   I suggest deleting "easily" in section 6.1.14:
    The PCECP MUST be easily extensible -> The PCECP MUST be extensible

NIT 6:
  Sections 6.1.16 and .17 share some language that confuses me:
   "does not mean that the constraint must not be supported"
   and
   "does not mean that the objective function may not be supported"

  Is there a way to say this with fewer negations?

  You are trying to reinforce that these sets are extensible. Maybe
  you could just say that instead?

NIT 7:
  The first sentence of 6.2.2 has at least two discrete requirements
  embedded in it. It would be easier to evaluate against the eventual
  protocol definition if these were separated.

NIT 8:
  It's not clear to me what "resynchronization of information" means in
  section 6.3.2. Is there any way to add detail? Is it obvious to the
  community using this document what information is being  resynchronized?

NIT 9:
  Section 6.3.3, third paragraph. I suggest changing
  "large number of PCCs is going to simultaneously" to
  "large number of PCCs will simultaneously".

A couple of final comments that I didn't think worthy of
being called an issue or a nit:

The draft requires response aggregation, but doesn't discuss
the ramifications this will have on the reliability mechanisms
that you will either use from a selected transport or have to
build above it. Pointing out that there are non-trivial issues
here would probably be useful.

The security consideration section doesn't capture any thinking
your group may have put in so far towards threats from elements
that are part of the architecture. Capturing early thinking here
will go a long way.

1. From Section 8:

'PCECP operations MUST be modeled and controlled through appropriate MIB modules.'  


It looks to me that there are enough specific differences between PCCs and PCEs to lead to the need of defining separate MIB modules. I suggest that this is mentioned in Section 8.

3. 'The operator MUST be able to determine PCECP historical interactions and the success rate of requests using data from MIB modules.'

The way this phrase is written the use of capitalization does not seem justified. Maybe a beter text would be:

'The MIB modules MUST provide information that will allow an operator to PCECP historical interactions and the success rate of requests.'


3. 'The new MIB modules should also be used to provide notifications (traps) when thresholds are crossed or when important events occur.'

This is extremely vague and general for a requirement. I wsuggest that sepcific information be provided about what type of faults and events are critical and need to be reported in notifications. Maybe this paragraph needs to be merged with the last paragraph, where there is some mention about congestion and rate limitation indications.