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
