Hi, Thank you for this new version of the I-D, it has greatly improved and clarifies former loose zones. Please find my review below.
------ Abstract --- - s/traffic engineering paths (TE paths)/Traffic Engineering paths (TE paths)/ - I wonder about the expansion of "TE path" above: why not "Engineered" instead of "Engineering"? (This is global to the I-D, and beyond... RFC Editor's list includes both.) - s/label switched paths (LSPs)/Label Switched Paths (LSPs)/ ------ Status --- - "https://"; was introduced in -05, but has now disappeared. ------ 1. Introduction --- - s/Path Computation Element Protocol/Path Computation Element communication Protocol/ - OLD path setup type needs to be either explicitly indicated or implied in the appropriate PCEP messages (when necessary)... NEW path setup type needs to be explicitly indicated in the appropriate PCEP messages, unless RSVP-TE type is meant (omission implying this type)... ------ 3. Path Setup Type Capability TLV --- - s/Initialization phase/initialization phase/ - I though the discussion on the list was about using a bitmap to identify supported PSTs: any reason why it is now a list of raw octets? - The definition of length and padding mixes the words "octet" and "bytes", depending on the field (probably to due to text coming from RFC 5440). Consistency would be welcome (the comment appears to be applicable beyond this section). ------ 4. Path Setup Type TLV --- - Figure 2 explicitly includes the codepoint for the "Type" (28), the "Length" field should be treated similarly (4). - The last sentence of section 4 puzzles me. If the PATH-SETUP-TYPE TLV is not supported, the PCEP peer cares little if it was "recognized" or not. If both sub-cases are commonly handled by ignoring, an implementation always including the RSVP-TE PST will be able to interwork with an implementation knowing about the TLV without actually supporting it; the current text turns this situation into an error. (Note also that RFC 5440 does not distinguish unrecognized and unsupported in TLV processing rules.) - In case my previous comment does not fly, 3 more nits: * s/recognizes the TLV but does not support the TLV/recognizes the TLV but does not support its use/ * s/send PCErr/send a PCErr message/ * Error-Type is 2, would not 4 fit better? ------ 5. Operation --- - s/Initialization phase/initialization phase/ - s/MUST infer/MUST consider/ [explicit => nothing to infer] - The text says multiple times "unless the intended PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV". This is inconsistent with section 4: "It is RECOMMENDED that a PCEP speaker omits the TLV if the PST is RSVP-TE." Please choose between MAY and SHOULD, and align. ------ Cheers, Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
