Thanks Russ & Adrian! I have updated the working copy with this commit -> https://github.com/dhruvdhody/draft-dhody-pce-pceps-tls13/commit/05027a5251a0290bd8c960b2c03aa2b13ae01c79
Dhruv On Fri, Oct 14, 2022 at 8:10 PM Adrian Farrel <adr...@olddog.co.uk> wrote: > Wfm, thnx > > -----Original Message----- > From: Russ Housley <hous...@vigilsec.com> > Sent: 14 October 2022 14:58 > To: Adrian Farrel <adr...@olddog.co.uk> > Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org > Subject: Re: Thinking about draft-dhody-pce-pceps-tls13 > > Maybe the phrase should be: PCEP implementations that support TLS 1.3 MUST > ... > > Russ > > > On Oct 14, 2022, at 9:28 AM, Adrian Farrel <adr...@olddog.co.uk> wrote: > > > > Thanks, Rus. > > > > What I didn't express well (don't write emails when you have been doing > hard > > concentration work for 9.5 hours straight!) is that it is possible to > think > > that this work is telling all PCEP implementations what they must do. I > have > > spoken to one person who was very worried that this was updating what > their > > existing implementation would need to do. > > > > I'm clear that the intention is to describe what PCEPS implementations > that > > support TLS 1.3 are supposed to do, and that doesn't have any knock-on > for > > other work, but, yes, a very simple addition of "of this specification" > > makes all the concerns go away. > > > > Cheers, > > Adrian > > > > -----Original Message----- > > From: Russ Housley <hous...@vigilsec.com> > > Sent: 14 October 2022 13:46 > > To: Adrian Farrel <adr...@olddog.co.uk> > > Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org > > Subject: Re: Thinking about draft-dhody-pce-pceps-tls13 > > > > Adrian: > > > > TLS 1.2 does not have early data, and the algorithm registries arefor TLS > > 1.2 and TLS 1.3 are separate, o I do not think there is confusion. That > > said, I do not object to adding the phrase. > > > > Russ > > > >> On Oct 13, 2022, at 5:42 PM, Adrian Farrel <adr...@olddog.co.uk> wrote: > >> > >> Hi, > >> > >> Thanks for kicking off work to get PCEP able to work with TLS1.3. > >> > >> This is important. > >> > >> However... :-) > >> > >> I think it would be helpful to clarify that statements about what > >> implementations must or must not do (etc.) should be scoped as > >> "implementations of this document." That is, you are not constraining > PCEP > >> implementations in general, and I don't even thing you are constraining > >> TLS1.2 PCEP implementations. Well, if it was your intent to do > otherwise, > >> you really need to be clear that you are updating the base specs, but I > > hope > >> you're not. > >> > >> Further, I am worried about the use of draft-ietf-tls-rfc8446bis as a > >> normative reference. I understand that the long term intention is that > > that > >> draft will obsolete RFC 8446, but it seems to be moving slowly (if at > all > > - > >> it has expired). I think that implementers wanting to apply TLS1.3 to > > their > >> PCEP code will want to pick up TLS1.3 implementations that are stable > > (i.e., > >> based on RFCs). Now, by the time this draft gets to completion, it is > > quite > >> possible that 8446bis will have completed, and the draft can be updated > to > >> reference it and pick any additional points it makes. On the other hand, > > if > >> this draft makes it to the RFC Editor queue before 8446bis is complete, > I > >> don't think you'd want it to sit around, and a subsequent bis can be > made > >> when 8446bis becomes an RFC. > >> > >> What do you think? > >> > >> Cheers, > >> Adrian > >> > >> > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
