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
