Hi Eric/Rich, I am quoting my original comment on the IANA section once again below. I was looking for clarity about what are the "IANA actions for this document" vs "statement of fact of registries involved without any reference to IANA actions".
QUOTE 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? UNQUOTE I will leave it for the authors to work this with the IANA team and I think Amanda's suggestions make sense to me along the lines above. Coming to the RFC8126 guidance for bis document, yes there is a lot of latitude but with that results in a lot of variance across documents. I hope this is something that can be relooked at as part of the ianabis work. Thanks, Ketan On Mon, May 19, 2025 at 11:55 PM Amanda Baber <amanda.ba...@iana.org> wrote: > For the record, IANA’s OK with reproducing the original actions as long as > there’s a clearly-labeled subsection that lists the new actions. It could > be useful to also place the original actions under a heading like “RFC 8446 > Actions” or something, but the opening paragraph does explain what’s > happening here. > > > > The issue for us is that when one document obsoletes another, we’re > typically meant to replace all references in the IANA registries unless > there’s some reason to leave a registration out (typically, if it’s being > deprecated or obsoleted). > > > > We would also be OK with a line that said “All references to RFC X in the > IANA registries have been replaced with references to this document, except > for the following registrations:” or something along those lines, although > we generally prefer that any detailed instructions to applicants or > designated experts be carried over. > > > > Thanks, > > Amanda > > > > *From: *"Salz, Rich" <rsalz=40akamai....@dmarc.ietf.org> > *Date: *Monday, May 19, 2025 at 10:28 AM > *To: *Eric Rescorla <e...@rtfm.com>, Ketan Talaulikar < > ketant.i...@gmail.com> > *Cc: *The IESG <i...@ietf.org>, "draft-ietf-tls-rfc8446...@ietf.org" < > draft-ietf-tls-rfc8446...@ietf.org>, "tls-cha...@ietf.org" < > tls-cha...@ietf.org>, "tls@ietf.org" <tls@ietf.org> > *Subject: *[Ext] Re: [TLS] Re: Ketan Talaulikar's No Objection on > draft-ietf-tls-rfc8446bis-12: (with COMMENT) > > > > We often have the case where IANA is asked to do something and by the time > the RFC is published, they’ve already done it. In those situations we often > change “IANA is requested to …” to “IANA has …” This particular situation > is not different. If we obsolete 8446 and don’t carry the considerations > forward, completely, in this draft, it needlessly raises the questions of > (a) if 8446 is obsoleted, are structure and content of the existing > registries still in line with IETF consensus; or (b) do you mean to only > obsolete **those parts** of 8446 that don’t talk about the IANA > consideratons? > > > > I strongly agree with EKR, that having a single complete spec, rather than > a “diff spec” is an important thing to do here. It was also the WG view as > well. >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
