I approve. Russ
> On Jan 21, 2026, at 10:47 AM, Alanna Paloma <[email protected]> > wrote: > > Hi Sean, > > Thank you for your approval. It has been noted on the AUTH48 status page: > https://www.rfc-editor.org/auth48/rfc9918 > > Once we receive approvals from Mahesh (AD) and Russ, we will move this > document forward in the publication process. > > Best regards, > Alanna Paloma > RFC Production Center > >> On Jan 21, 2026, at 5:43 AM, Sean Turner <[email protected]> wrote: >> >> Based on these diffs I approve. >> >> spt >> >>> On Jan 20, 2026, at 14:55, Alanna Paloma <[email protected]> >>> wrote: >>> >>> Hi Authors and Mahesh (AD)*, >>> >>> *Mahesh - As the AD, please review and approve of the added 2119/8174 >>> keyword in the sentence below (Section 1). >>> >>> Original: >>> NOTE: Implementations that support TLS 1.3 >>> [I-D.ietf-tls-rfc8446bis] should refer to TLS 1.3 >>> [I-D.ietf-tls-rfc8446bis] in Sections 4 and 5 of [RFC7589]. >>> >>> Current: >>> NOTE: Implementations that support TLS 1.3 [RFC9846] >>> SHOULD also follow Sections 4 and 5 of [RFC7589]. >>> >>> See this diff file: >>> https://www.rfc-editor.org/authors/rfc9918-auth48diff.html >>> >>> >>> Authors - Thank you for your reply. We have updated the document >>> accordingly. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9918.txt >>> https://www.rfc-editor.org/authors/rfc9918.pdf >>> https://www.rfc-editor.org/authors/rfc9918.html >>> https://www.rfc-editor.org/authors/rfc9918.xml >>> >>> The relevant diff files are posted here: >>> https://www.rfc-editor.org/authors/rfc9918-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9918-auth48diff.html (AUTH48 changes) >>> https://www.rfc-editor.org/authors/rfc9918-auth48rfcdiff.html (AUTH48 >>> changes side by side) >>> >>> Please review the document carefully as documents do not change once >>> published as RFCs. >>> >>> We will await any further changes you may have and approvals from each >>> author and *Mahesh prior to moving forward in the publication process. >>> >>> Please see the AUTH48 status page for this document here: >>> https://www.rfc-editor.org/auth48/rfc9918 >>> >>> Thank you, >>> Alanna Paloma >>> RFC Production Center >>> >>>> On Jan 20, 2026, at 7:15 AM, Sean Turner <[email protected]> wrote: >>>> >>>> Alana, >>>> >>>> Hi! >>>> >>>> More below.. and my new ones follow: >>>> >>>> 1) Minor nit: >>>> >>>> OLD: >>>> >>>> data, which is also known as 0-RTT data. It also updates "netconf- >>>> tls", the IANA-registered port number entry, to refer to this >>>> >>>> NEW: >>>> >>>> data, which is also known as 0-RTT data. It also updates >>>> "netconf-tls", the IANA-registered port number entry, to refer to this >>>> >>>> 2) Tweak to make it match others: >>>> >>>> OLD: >>>> >>>> This document specifies that >>>> NETCONF implementations that support TLS 1.3 MUST NOT use early data. >>>> >>>> NEW: >>>> >>>> This document specifies that >>>> NETCONF implementations that support TLS 1.3 or later MUST NOT use early >>>> data. >>>> >>>> spt >>>> >>>>> On Jan 16, 2026, at 15:34, Alanna Paloma <[email protected]> >>>>> wrote: >>>>> >>>>> Hi Russ, >>>>> >>>>> Thank you for your reply. >>>>> >>>>> The files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9918.xml >>>>> https://www.rfc-editor.org/authors/rfc9918.txt >>>>> https://www.rfc-editor.org/authors/rfc9918.html >>>>> https://www.rfc-editor.org/authors/rfc9918.pdf >>>>> >>>>> The relevant diff files have been posted here: >>>>> https://www.rfc-editor.org/authors/rfc9918-diff.html (comprehensive diff) >>>>> https://www.rfc-editor.org/authors/rfc9918-rfcdiff.html (side by side) >>>>> >>>>> Please review the document carefully and contact us with any further >>>>> updates you may have. Note that we do not make changes once a document >>>>> is published as an RFC. >>>>> >>>>> We will await approvals from each party listed on the AUTH48 status page >>>>> below prior to moving this document forward in the publication process. >>>>> >>>>> For the AUTH48 status of this document, please see: >>>>> https://www.rfc-editor.org/auth48/rfc9918 >>>>> >>>>> Thank you, >>>>> Alanna Paloma >>>>> RFC Production Center >>>>> >>>>>> On Jan 16, 2026, at 11:02 AM, Russ Housley <[email protected]> wrote: >>>>>> >>>>>> Dear RFC Editor: >>>>>> >>>>>>> 1) <!--[rfced] As [RFC9846] was cited twice in this sentence, >>>>>>> we have removed the second instance. Please review and let us know >>>>>>> if you prefer otherwise. >>>>>>> >>>>>>> Original: >>>>>>> | NOTE: Implementations that support TLS 1.3 >>>>>>> | [I-D.ietf-tls-rfc8446bis] should refer to TLS 1.3 >>>>>>> | [I-D.ietf-tls-rfc8446bis] in Sections 4 and 5 of [RFC7589]. >>>>>>> >>>>>>> Current: >>>>>>> | NOTE: Implementations that support TLS 1.3 [RFC9846] >>>>>>> | should refer to TLS 1.3 in Sections 4 and 5 of [RFC7589]. >>>>>>> --> >>>>>> >>>>>> The proposed rewording looks fine to me. >>>> >>>> Can we tweak this note to be: >>>> >>>> NOTE: Implementations that support TLS 1.3 [RFC9846] >>>> SHOULD also follow Sections 4 and 5 of [RFC7589]. >>>> >>>>>>> 2) <!--[rfced] FYI - We have added an expansion for the following >>>>>>> abbreviation >>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>>>>> expansion in the document carefully to ensure correctness. >>>>>>> >>>>>>> Network Configuration Protocol (NETCONF) >>>>>>> --> >>>>>> >>>>>> The looks fine to me. >>>> >>>> ditto >>>> >>>>>>> 3) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>>>> online >>>>>>> Style Guide >>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>>> and let us know if any changes are needed. Updates of this nature >>>>>>> typically >>>>>>> result in more precise language, which is helpful for readers. >>>>>>> >>>>>>> Note that our script did not flag any words in particular, but this >>>>>>> should >>>>>>> still be reviewed as a best practice. >>>>>>> --> >>>>>> >>>>>> I do not see any concerns. >>>> >>>> ditto >>>> >>>>>> Russ >>>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
