Hi Warren, We have updated the draft according to your comments, please check. https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-stateful-pce-optional-11&url2=draft-ietf-pce-stateful-pce-optional-12&difftype=--html
Thanks, Cheng -----Original Message----- From: Warren Kumari via Datatracker <nore...@ietf.org> Sent: Monday, November 18, 2024 9:40 PM To: The IESG <i...@ietf.org> Cc: draft-ietf-pce-stateful-pce-optio...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; ops-...@ietf.org Subject: [Pce] Warren Kumari's No Objection on draft-ietf-pce-stateful-pce-optional-10: (with COMMENT) Warren Kumari has entered the following ballot position for draft-ietf-pce-stateful-pce-optional-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-optional/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Tianran Zhou for the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-pce-stateful-pce-optional-10-opsdir-lc-zhou-2024-10-07/ I found this document quite difficult to read, but that may be because I'm unfamiliar with PCE. I have some nits: 1:The behaviour for P and I flag in other messages defined in [RFC5440] and other extension was not specified. P: The behaviour for P and I flag in other messages defined in [RFC5440] and other extensions were not specified. C: I'm actually not sure what this sentence is trying to say -- is it that "the behavior for the flags, and also the behavior in other extensions" was not specified, or "the behavior of the flags which are specified in RFC5440 and other extensions" was not specified? [Cheng] We can delete the text. It does not bring too much information. Please see the latest revision to see if you are ok with that. 2: "In these cases, it would be useful to mark the objects as 'optional' and it could be ignored by the PCEP peer." P: "In these cases, it would be useful to mark the objects as 'optional', and they could be ignored by the PCEP peer." (I think). [Cheng]Agree. Updated. 3: "Thus, this document specifies how the already existing P and I flag in the PCEP common object header could be used during the stateful ..." P: "Thus, this document specifies how the already existing P and I flags in the PCEP common object header could be used during the stateful ..." (this occurs in many places in the document.) [Cheng]Updated accordingly. Thanks! 4: "In case the bit is unset, it indicates that the PCEP Speaker would not handle the P and I flags in the PCEP common object header for stateful PCE messages." P: "If the bit..." [Cheng]Thanks! 5: "The P flag for the mandatory objects such as the LSP and the ERO (Explicit Route Object) object (intended path) MUST be set in the PCRpt message. " P: "The P flag for the mandatory objects, such as the LSP and the ERO (Explicit Route Object) object (intended path), MUST be set in the PCRpt message." C: It's really hard to read without the commas. This occurs in multiple places in the documents. [Cheng]updated. 6: "On a PCEP session on which R bit was set by both peers, the PCC SHOULD set the P flag by default, " P: "On a PCEP session in which the R bit was set by both peers, the PCC SHOULD set the P flag by default, " [Cheng]Updated. 7: "In case PCC cannot accept this, it would react as per the processing rules of unacceptable update in [RFC8231]." P: "If the PCC cannot accept this, it would react as per the processing rules of unacceptable update in [RFC8231]." C: The "it would react" is very unclear -- is this "it MUST"? "SHOULD"? Why might the PCC not accept this? [Cheng]The potential unacceptable cases are described in RFC8231, and the rules are defined in section 5.8.3 of RFC8231. How about the following text? "If PCC cannot accept the update message, it MUST react as per the processing rules of unacceptable update in section 5.8.3 of RFC8231" _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
