On Mon, May 19, 2025 at 10:08 AM Ketan Talaulikar <ketant.i...@gmail.com> wrote:
> Hi Eric, > > I am not sure which specific point of my comments are being referred to > here. I will assume it is (5) related to IANA. Please correct me if I am > wrong. > Both the IANA instructions *and* the updated headers. > My reading of RFC8126 takes me to different conclusions from what you've > said. In short, the IANA Considerations capture instructions for IANA to > perform on that specific document. If IANA has already done some actions on > the prior document that has been obsoleted by "this document", then "this > document" will perhaps only have action to update references from the > obsoleted document to this document. > > I refer to : https://datatracker.ietf.org/doc/html/rfc8126#section-1 and > more specifically https://datatracker.ietf.org/doc/html/rfc8126#section-8 > Which specific text are you referring to in S 8. The text I see mostly refers to updating the IANA text to refer to the current document, which I agree with. My objection is to eliding the changes that we made in RFC 8446 and only focusing on whatever changes are in this document. As I stated, this document will be in the RFC series forever, whereas the instructions to IANA are ephemeral, so having it focus on diffs from 8446 is unhelpful. I believe that 8126 gives us some latitude here: The main point is to make sure that the reference pointers are as useful and current as is reasonable, and authors should consider that as they write the IANA Considerations for the new document. As always: do the right thing, and there is flexibility to allow for that. -Ekr Thanks, > Ketan > > > On Mon, May 19, 2025 at 7:28 PM Eric Rescorla <e...@rtfm.com> wrote: > >> Hi Ketan, >> >> Thanks for your comments. >> >> I think it might be useful to discuss the general policy questions >> around this kind of minor bis update. As you know, TLS 1.3 is widely >> deployed and this document is not intended to provide an updated >> *protocol* but rather an updated *document*. In a more sensible world, >> we would perhaps publish it as "RFC 8446.1" and call it a day, but >> that option is not available to us, so instead it will be RFC 10446 or >> something. However, that doesn't change the situation, which is that >> we want this to be the new normative reference for TLS 1.3. >> >> To that end, just as the protocol mechanics are specified completely >> in this document rather than as a delta against RFC 8446, we should >> similarly fully specify the administrative actions (IANA, >> Obsoletes/Updates) rather than provide a delta against 8446. I'd be >> happy to provide an appendix clarifying the situation, but I think >> it's unfortunate to force ordinary readers to have to engage with the >> history of the document, when what they actually just want to know is >> what is TLS 1.3. This is particularly true for the IANA Considerations, >> which will survive long after IANA has done whatever it has to do; >> if there is some confusion on the IANA side, I think it would be better >> to clarify that out of band. >> >> -Ekr >> >> >> >> On Mon, May 19, 2025 at 6:15 AM Ketan Talaulikar via Datatracker < >> nore...@ietf.org> wrote: >> >>> Ketan Talaulikar has entered the following ballot position for >>> draft-ietf-tls-rfc8446bis-12: 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-tls-rfc8446bis/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Thanks to the authors, contributors, and the WG for the work on this >>> important >>> document. >>> >>> I have the following comments/suggestions to offer on this document. >>> >>> 1) In the abstract ... and this is assuming that this document is not >>> actually >>> obsoleting 8422 ... >>> >>> CURRENT >>> This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs >>> 5077, >>> 5246, 6961, 8422, and 8446. This document also specifies new >>> requirements for >>> TLS 1.2 implementations. >>> >>> SUGGEST >>> This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFC >>> 8446. >>> This document also specifies new requirements for TLS 1.2 >>> implementations. >>> >>> 2) Please state in the introduction section on what part of 8422 is being >>> updated by this document. >>> >>> 3) RFCs 5077, 5246 and 6961 were actually obsoleted by RFC 8446 and not >>> this >>> document. Please rephrase some of the references to those documents >>> saying that >>> they were obsoleted by RFC 8446 and not "this document". >>> >>> 4) Ref section 1.4 - does this document also not update RFC7627 with its >>> terminology change? >>> >>> 5) I found the IANA consideration section hard to follow in terms of >>> clarity on >>> what exactly is the action for IANA team from this document. Section >>> 11.1 has >>> clear actions but the parent section 11 is perhaps having some remnant >>> actions >>> from RFC8446 that might be confusing. If all that the section 11 talks >>> about is >>> something that IANA has already done, perhaps simply a description of >>> the IANA >>> registries pertaining to this document (previously pertaining to RFC8446) >>> without talking about any action that was done or to be done would be >>> more >>> clear? And then there is 11.1 for the actual IANA work/actions to be >>> done? >>> >>> 6) I believe there is an error with the reference to RFC8444. That one >>> is a >>> OSPF routing protocol extension and don't see how that comes into TLS >>> land. >>> >>> >>> >>>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
