Re: [Pce] Thinking about draft-dhody-pce-pceps-tls13
I also submitted a CR to fix my spelling mistake :) spt > On Oct 14, 2022, at 19:23, Dhruv Dhody wrote: > > 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 wrote: > Wfm, thnx > > -Original Message- > From: Russ Housley > Sent: 14 October 2022 14:58 > To: Adrian Farrel > 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 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 > > Sent: 14 October 2022 13:46 > > To: Adrian Farrel > > 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 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
Re: [Pce] Thinking about draft-dhody-pce-pceps-tls13
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 wrote: > Wfm, thnx > > -Original Message- > From: Russ Housley > Sent: 14 October 2022 14:58 > To: Adrian Farrel > 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 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 > > Sent: 14 October 2022 13:46 > > To: Adrian Farrel > > 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 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
Re: [Pce] Thinking about draft-dhody-pce-pceps-tls13
Wfm, thnx -Original Message- From: Russ Housley Sent: 14 October 2022 14:58 To: Adrian Farrel 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 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 > Sent: 14 October 2022 13:46 > To: Adrian Farrel > 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 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
Re: [Pce] 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 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 > Sent: 14 October 2022 13:46 > To: Adrian Farrel > 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 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
Re: [Pce] Thinking about draft-dhody-pce-pceps-tls13
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 Sent: 14 October 2022 13:46 To: Adrian Farrel 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 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
Re: [Pce] 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 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] Thinking about draft-dhody-pce-pceps-tls13
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
