Document:  draft-ietf-pce-comm-protocol-gen-reqs-06.txt 
Reviewer: Robert Sparks [rjsparks@nostrum.com]
Review Date:  Tuesday 5/23/2006 6:58 PM CST
IESG Telechat Date:  Thursday, 25 May 2006

===============================================
Summary: This draft is on the right track but has open issues
          to resolve before publication.
===============================================

This draft is well written and is accessible to readers, like
myself, who are not routing (particularly MPLS) experts.


The current version has some rough edges that I feel need attention
before publication. They are listed here in priority order. These
are followed by a few nits that should also be addressed.

ISSUE 1:
   The summary of requirements in section 6.4 are inconsistant with
   the requirements in the document.

    Example: 6.4 contains:
         Functionality added to PCECP if transport
         protocol provides it                      SHOULD NOT 6.1.8
      while 6.1.8 says
	Functionality MUST NOT be added to the PCECP where
         the chosen transport protocol already provides it.

    Example: 6.4 contains:
         Maintain PCC-PCE session                 NON-RQMT   6.1.2
      but 6.1.2 is silent on maintaining sessions

   I have not done an exhaustive comparison of the table vs the text.
   This is what I found spot-checking a few. A more thorough  
reconcilliation
   is needed.

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 3:
   There is an incorporation of MUST requirements by incomplete
   reference in section 6.1.14:
     "The PCECP MUST support the requirements specified in the
      application-specific requirements documents."
   But it's not clear what these requirements documents are. There
   is a list in the preceeding paragraph, but only a subset of the
   elements in that list have concrete references.

   One possible resolution is to state that the protocol must be
   extensible, explicitly call out the kinds of extensibility (adding
   to the first paragraph of 6.1.14 perhaps) and calling out these
   other documents as examples of the users of the extensibility  
mechanism
   instead of directly requiring support of their requirements here.

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 6 (not as major as the above, but should still be addressed):
   There are several places where 2119 terms are used where they
   shouldn't be. The large difference in the number of occurances of
   MUST outside section 6.4 and inside section 6.4 points to this and
   could be used as a mechanism to help find these places.
     Examples from 6.1.4:
       A list of core objective functions that MUST be supported by the
       PCECP is supplied in Section 6.1.17. Specification of objective
       functions MUST be future-proofed as described in Section 6.1.14.

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.