Document: draft-ietf-pce-of-05
Reviewer: Robert Sparks
Review Date: 18 Dec 2008
IETF LC End Date: 23 Dec 2008
IESG Telechat date: not known


Summary: Mostly Ready but some nits


Comments:

The security consideration section is pretty light (particularly given how long this set of documents appears to have been cooking). Are there really no additional considerations over what's in [PCEP] introduced by this document? A couple of sentences further supporting that (if it's the case) would go a long way.

This is probably a naive question, but what happens if a PCC sets the OF flag in a request, doesn't provide a OF object, and the OF object in the response has a function code the client has never heard of before? (If this is clear, where in the document suite is it captured?)

Also (and to check my understanding of how extensibility of the flags field in the RP object is supposed to work) - it's possible for the OF flag to be set in a request but for the response to not contain an OF object (if the PCE doesn't know about the extension in this draft it MUST ignore the non-zero flag bit according to the definitions on page 30 of [PCEP]). Should this document explicitly mention this case?

This draft uses RBNF (draft-farrel-rtg-common-bnf). The proto writeup indicates that no tool was used to verify the RBNF in the draft. Has there been a careful review by a human? (There isn't much of it, but enough for a typo or dangling reference to slip in).

I'm probably being dense, but I can't make the literal "0x200" in the definition of the OF flag make sense. It doesn't seem to have anywhere to go in the registry that [PCEP] creates. Additionally, that registry asks for a "Capability Description" and this document only provides a "Name" (of OF).

Section 8.2 is, if I read it correctly, a note that more standards work needs to happen, not that an implementer needs to do something. I suggest not using 2119 language here.

The rest of these comments are minor:

- The abstract does not capture that the document defines/registers objective functions/metric types

- There's an extra closing parenthesis in the function on Objective Function Code 3: r(Lpi)) <-here

- It would make IANA's job easier to point to the registries this document is adding values to (rather than creating) by the name. For instance, 6.2.3 of this document could say the "PCEP-ERROR Object registry" (assuming that's the name that [PCEP] is trying to get IANA to use for the registry it creates in its section 9.12. The [PCEP] document itself might benefit from being more explicit with registry names it suggests to IANA.