Hi! I performed an AD review of draft-ietf-pce-stateful-pce-vendor-07. To help load balance AD document queues, I'll be taking over as responsible AD.
Thanks for this document. My feedback is below: ** Is there a reason why this document does not formally updated RFC8231 and RFC8281 given the text in Section 2? ** Section 2. I’m not confident in my understanding of RFC5511 models. Where is the reference or explanation of this value: <VENDOR-INFORMATION> in this document? ** Section 2. Consider provide specific section references when OLD/NEW text is provided. OLD The format of the PCRpt message (with [RFC8231] as the base) is updated as follows: NEW The format of the PCRpt message (with Section 6.1 of [RFC8231] as the base) is updated as follows: -- OLD The format of the PCUpd message (with [RFC8231] as the base) is updated as follows: NEW The format of the PCUpd message (with Section 6.2 of [RFC8231] as the base) is updated as follows: -- OLD The format of the PCInitiate message (with [RFC8281] as the base) is updated as follows: NEW The format of the PCInitiate message (with Section 5.1 of [RFC8281] as the base) is updated as follows: ** Section 2. Per the definition of PCInitiate, RFC8281 included the text “<Common Header> is defined in RFC 5440”. Should that be used here? ** Section 4.2 Any standard YANG module will not include details of vendor-specific information. What is a “standard” YANG module? ** Section 4.6 Section 6.6 of [RFC7470] highlights how the presence of additional vendor-specific information in PCEP messages may congest the operations and how to detect and handle it. A similar approach SHOULD be considered for Stateful PCEP messages and for a PCE. What does it mean when an approach “SHOULD be considered”? SHOULD is already conveying that this behavior is optional. Can the desired behavior please be more tangibly described? Regards, Roman _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
