Deb Cooley 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: ---------------------------------------------------------------------- Section 3.2.1: It seems like the use of the R flag changes how the PCE handles the P flag. I'm not sure SHOULD (or BCP14 language) is optimal in this section. Does the PCE try hard to respect the P flag, but if it can't, then it ignores it? This sounds more like 'best effort'. I can't tell if this also might apply to the case where the 'PCC SHOULD set the P flag by default'. [note: I'm well outside of my expertise area here, I'm just trying to interpret what is here in a logical fashion.] Sections 3.2 and 3.3: Would a small table with P, R, and I flags against PCC, PCE, and maybe the various extensions/message types might help? Section 4: The last () is a bit puzzling. It might need some explanation. Is there something specific that is anticipated? RFC8253 is old enough that TLS1.3 wasn't published yet, but RFC 9325 obviously covers both TLS 1.2 and 1.3. _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
