Re: [Pce] Murray Kucherawy's No Objection on draft-ietf-pce-pceps-tls13-03: (with COMMENT)
Hi Murray, On Thu, Jan 4, 2024 at 11:30 AM Murray Kucherawy via Datatracker < nore...@ietf.org> wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-pce-pceps-tls13-03: 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-pceps-tls13/ > > > > -- > COMMENT: > -- > > Further to Eric's comment, I'm completely confused by question #4 of the > shepherd writeup. While the document claims there are no implementations > known, the shepherd writeup says there's at least one (and it was easy), > and > makes another "Yes" remark that I don't understand. > > > Dhruv: The shepherd writeup mentions this email response on the mailing list - https://mailarchive.ietf.org/arch/msg/pce/dLdcUan2psssBUgzCtXPluEr_ok/ that mentions some implementation experience. When we asked to include that information in the implementation section we did not get a confirmation back. Soo that's that :) We could update the implementation section to say - OLD: At the time of posting the -02 version of this document, there are no known implementations of this mechanism. NEW: At the time of posting the -04 version of this document, there are no known implementations of this mechanism. It is believed that one vendor has implementation, but these plans are too vague to make any further assertions. END Thanks! Dhruv ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Murray Kucherawy's No Objection on draft-ietf-pce-pceps-tls13-03: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-pce-pceps-tls13-03: 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-pceps-tls13/ -- COMMENT: -- Further to Eric's comment, I'm completely confused by question #4 of the shepherd writeup. While the document claims there are no implementations known, the shepherd writeup says there's at least one (and it was easy), and makes another "Yes" remark that I don't understand. Forwarding a comment from Orie Steele, incoming ART Area Director: Noting the comment on 0-RTT / early data regarding secrecy, and the comment on https://datatracker.ietf.org/doc/html/rfc8253#section-3.4 * Negotiation of a ciphersuite providing for confidentiality is RECOMMENDED. I'm not an expert on PCEPS, but I wonder why the need for the note at all given PCEPs only recommends confidentiality, and the requirement above states early data is forbidden. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Murray Kucherawy's No Objection on draft-ietf-pce-pceps-tls13-03: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-pce-pceps-tls13-03: 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-pceps-tls13/ -- COMMENT: -- Further to Eric's comment, I'm completely confused by question #4 of the shepherd writeup. While the document claims there are no implementations known, the shepherd writeup says there's at least one (and it was easy), and makes another "Yes" remark that I don't understand. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Paul Wouters' Yes on draft-ietf-pce-pceps-tls13-03: (with COMMENT)
> On Jan 3, 2024, at 17:13, Paul Wouters via Datatracker > wrote: > > Paul Wouters has entered the following ballot position for > draft-ietf-pce-pceps-tls13-03: Yes > > 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-pceps-tls13/ > > > > -- > COMMENT: > -- > > Implementations that support multiple versions of the TLS protocol MUST > prefer to negotiate the latest version of the TLS protocol. > > I'm a little confused why this needs to be stated as an update, as this is a > general requirement of TLS (or any versioned protocol really) I hear this phrase all the time: There is no document that specifies how to do protocol X with Y. You can reply that the “normal” updates procedure addresses this issue, but 99 times out of 100 times you’re going to get a quizzical look. This statement closeout that discussion. > It might be useful to point to > https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.1 that deals with > how > to negotiate allowing TLS 1.2 when also supporting and preferring TLS 1.3. I mean if everybody read and remembered all the detail … More seriously, without this document there are some I believe that wouldn’t ever have read RFC 8446 and happy move along. I can add a ref to 4.2.1; see the following PR: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/20 Cheers, spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-pceps-tls13-03: (with COMMENT)
> On Jan 2, 2024, at 08:58, Dhruv Dhody wrote: > > Hi Èric, > > Happy 2024! > > On Tue, Jan 2, 2024 at 6:03 PM Éric Vyncke via Datatracker > wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-pce-pceps-tls13-03: 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-pceps-tls13/ > > > > -- > COMMENT: > -- > > > # Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05 > > Thank you for the work put into this document. It was an easy and simple read > for my first document review in 2024! > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education). > > Special thanks to Andrew Stone for the shepherd's detailed write-up including > the WG consensus and the justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > # COMMENTS (non-blocking) > > ## Section 1 > > Is it a `Editor's Note:` or a "Note to the IESG" or a "Note to the RFC > Editor" ? > > Dhruv: It was an Editor's note while we were working on the I-D. At this > stage perhaps we can just remove the note now and stick it out with the fate > of RFC8446bis (which is in the post-WGLC stage). Sean and Russ should chime > in if they disagree :) I was a note to everybody ;) Well technically the audience changed as we marched through the process. It can safely be deleted post IESG comments: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/18 > ## Section 3 > > `MUST prefer to negotiate the latest version` is of course the preferred > behavior for the initiator, but should the document clearly specify that the > responser "MUST select the latest version" ? (please bear with me as English > is > not my primary language). > > Dhruv: FWIW I see the phrase usage in RFC 9325 as well as in the netconf tls > 1.3 I-D which was in a recent IESG telechat! ¯\_(ツ)_/¯ Yes it’s in 9325 and negotiate is a two way thing. > ## Section 6 > > I wonder about the usefulness of an implementation section having `there are > no > known implementations of this mechanism.` > > Dhruv: PCE WG set out an Implementation Section Policy listed at > https://wiki.ietf.org/group/pce/ImplementationPolicy > We wanted the WG and the IETF community to be aware of known implementations > (or lack thereof) at the time of approval, at publication the section is > anyway removed. Yep will remove this when we get to the RFC editor queue. Cheers, spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Paul Wouters' Yes on draft-ietf-pce-pceps-tls13-03: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-pce-pceps-tls13-03: Yes 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-pceps-tls13/ -- COMMENT: -- Implementations that support multiple versions of the TLS protocol MUST prefer to negotiate the latest version of the TLS protocol. I'm a little confused why this needs to be stated as an update, as this is a general requirement of TLS (or any versioned protocol really) It might be useful to point to https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.1 that deals with how to negotiate allowing TLS 1.2 when also supporting and preferring TLS 1.3. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
