Ballot for draft-ietf-pce-gmpls-pcep-extensions
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
Thank you for addressing my DISCUSS and COMMENT items.
I think Section 2.1.2 needs to better explain what happens when a PCC sends extensions but the recipient does not support them. Please respond to the Gen-ART review.
Thank you for addressing my Discuss points! I do have some additional comments on the -15. Section 2.3 I'm still a bit concerned that the references linked from Table 4 may not provide a clear description of what count as Traffic Parameters for our purposes (and how they are encoded), but not in a way that I can express more concretely. Perhaps this is made clear by some RSVP-TE documents with which I am not familiar. ection 2.5.1 root and other endpoints TLVs are the leaves. The root endpoint MUST be the same for all END-POINTS objects. If the root endpoint is not I'm not sure how broadly scoped this restriction is -- it is, e.g., per-LSP? Section 2.5.2.5 with L bit cleared. At most 2 LABEL_SET TLVs MAY be present with the O bit set, with at most one of these having the U bit set and at most one of these having the U bit cleared. For a given U bit value, if This went MUST->MAY in this rev, though I think it might be fine to just use a lowercase "may", since the requirements language doesn't map terribly well to the restriction we're making.
Hi, thanks for this document. I have a discuss point that shouldn't be difficult to resolve: Why do you define a flag field in the GMPLS-CAPABILITY TLV if you don't have any flag? I guess the easy answer is that there might be some in the future. If so, I tend to think that creating a registry for that field would be a good thing to do now. -m
Purely editorial comment: I would recommend to move most of the gap analysis of section 1 (actually most of the text of the whole section) into the appendix and only summarise the extensions specified in this doc instead. nit: sec 6: s/In order to protect against against the malicious PCE case/In order to protect against the malicious PCE case/ -> 2x against
* Section 2.5.2 "In this object type the order of the TLVs MUST be followed according to the object type definition." Not sure what this means. Can you clarify? * Section 2.7 "C-Type (8 bits): the C-Type of the included Label Object as defined in [RFC3471]." I could not find any references to C-Types in RFC3471. Shouldn't you be referring to RFC3473 instead? I have a similar comment for the Label field.