Hi Deb, On Wed, Nov 20, 2024 at 11:15 PM Deb Cooley via Datatracker < nore...@ietf.org> wrote:
> 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.] > > Dhruv: Based on John's suggestion - https://mailarchive.ietf.org/arch/msg/pce/wkJu_i0F4z3sNLd5o2s9bEXP7LM/, the plan is to change it to MUST. > 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? > > Dhruv: I remember this being suggested but the Authors claimed that such nested logic for flags is quite common in PCEP RFCs. > 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. > > Dhruv: As stated in the other thread. "There are some details in Section 3.4 of RFC 8253 that might not be matching exactly to RFC 9325 - such as MUST for TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 in RFC 8253 where as RECOMMENDED in RFC 9325. And what you state is also true!" Thanks! Dhruv (as document shepherd)
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
