w/ [dc] in front..... On Thu, Nov 21, 2024 at 1:55 AM Dhruv Dhody <d...@dhruvdhody.com> wrote:
> 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. > [dc] ok. > > > >> 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. > > [dc] common in the RFCs, sure. But clear and easy to implement correctly? IDK... > > >> 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. > [dc] see my comments 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
