Awesome, thanks for the update! On Tue, Sep 30, 2025 at 11:00 Alanna Paloma <[email protected]> wrote:
> All, > > We have noted Tommy’s and Nick’s approvals. With these, we have now > received all necessary approvals and consider AUTH48 complete: > https://www.rfc-editor.org/auth48/rfc9872 > > Thank you for your attention and guidance during the AUTH48 process. > We will move this document forward in the publication process at this time. > > Best Regards, > Alanna Paloma > RFC Production Center > > > On Sep 30, 2025, at 6:39 AM, Nick Buraglio <[email protected]> > wrote: > > > > Thanks all. I approve the text. > > > > nb > > > > On Mon, Sep 29, 2025 at 20:46 Tommy Jensen <[email protected]> > wrote: > > Hey Alanna, > > > > Thank you and everyone else for all the final stages work on this! > > > > I approve the updated text. > > > > Thanks, > > Tommy > > > > 2025-09-30T00:07:43Z Alanna Paloma <[email protected]>: > > > > > Hi Jen, > > > > > > Thank you for your approval. It has been noted on the AUTH48 status > page: > > > https://www.rfc-editor.org/auth48/rfc9872 > > > > > > Once we receive approvals from Nick and Tommy, we will move this > document forward in the publication process. > > > > > > Best regards, > > > Alanna Paloma > > > RFC Production Center > > > > > >> On Sep 29, 2025, at 4:48 PM, Jen Linkova <[email protected]> wrote: > > >> > > >> Hi Alanna, > > >> > > >> Thank you very much for making those changes. > > >> I approve the updated text. > > >> > > >> On Tue, Sep 30, 2025 at 4:55 AM Alanna Paloma > > >> <[email protected]> wrote: > > >>> > > >>> Hi Jen, > > >>> > > >>> Thank you for sending those additional changes. We have updated the > files accordingly. > > >>> > > >>> FYI - Per your request to add a citation to RFC 6146, we have added > a reference entry for it in the Informative References section. > > >>> > > >>> The files have been posted here (please refresh): > > >>> https://www.rfc-editor.org/authors/rfc9872.xml > > >>> https://www.rfc-editor.org/authors/rfc9872.txt > > >>> https://www.rfc-editor.org/authors/rfc9872.html > > >>> https://www.rfc-editor.org/authors/rfc9872.pdf > > >>> > > >>> The relevant diff files have been posted here: > > >>> https://www.rfc-editor.org/authors/rfc9872-diff.html (comprehensive > diff) > > >>> https://www.rfc-editor.org/authors/rfc9872-auth48diff.html (AUTH48 > changes) > > >>> https://www.rfc-editor.org/authors/rfc9872-auth48rfcdiff.html > (AUTH48 changes side by side) > > >>> https://www.rfc-editor.org/authors/rfc9872-lastdiff.html (last > version to this one) > > >>> https://www.rfc-editor.org/authors/rfc9872-lastrfcdiff.html > (rfcdiff between last version and this) > > >>> > > >>> We will await approvals from each party listed on the AUTH48 status > page 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/rfc9872 > > >>> > > >>> Thank you, > > >>> Alanna Paloma > > >>> RFC Production Center > > >>> > > >>>> On Sep 26, 2025, at 5:22 PM, Jen Linkova <[email protected]> wrote: > > >>>> > > >>>> Hi Alanna, > > >>>> > > >>>> Sorry for the delayed response, we (the authors) discussed the > changes > > >>>> and have a few more comments: > > >>>> > > >>>> 1) The short title update from " > > >>>> Original: > > >>>> Prefer RFC8781 > > >>>> > > >>>> Current: > > >>>> IPv6 Prefix Discovery > > >>>> > > >>>> IMHO “IPv6 Prefix” sounds confusing and a bit meaningless. Also, the > > >>>> proposed mechanism can be used in dual-stack networks, strictly > > >>>> speaking. > > >>>> Therefore we'd like to suggest: > > >>>> NEW: > > >>>> “NAT64 Prefix Discovery”. > > >>>> > > >>>> > > >>>> 2) > > >>>> CURRENT: > > >>>> PREF64: Pref64::/n or NAT64 prefix. An IPv6 prefix used for IPv6 > > >>>> address synthesis and for network addresses and protocols > translation > > >>>> from IPv6 clients to IPv4 servers using the algorithm defined in > > >>>> [RFC6052]. > > >>>> > > >>>> PREF64 definition saying “from IPv6 clients to IPv4 servers” isn’t > > >>>> strictly accurate, and the double use of addresses felt awkward > > >>>> compared to the straightforward definition in 8781: “An IPv6 prefix > > >>>> used for IPv6 address synthesis [RFC6146].” We should reuse the 8781 > > >>>> definition, especially given the close relationship between this > draft > > >>>> and 8781. > > >>>> So we are proposing: > > >>>> NEW: > > >>>> PREF64: Pref64::/n or NAT64 prefix. An IPv6 prefix used for IPv6 > > >>>> address synthesis [RFC6146]. > > >>>> > > >>>> 3) ORIGINAL: > > >>>> Fundamentally, the presence of the NAT64 and the exact value of the > > >>>> prefix used for the translation are network-specific attributes. > > >>>> > > >>>> Your comment was: " > > >>>> As "are network-specific attributes" seems to directly describe > "NAT64 > > >>>> and the exact values" rather than their presence, may we remove "the > > >>>> presence of" from this sentence?", > > >>>> > > >>>> so the text was changed to > > >>>> CURRENT: > > >>>> "Fundamentally, the NAT64 function and the exact value of the prefix > > >>>> used for the translation are network-specific attributes." > > >>>> > > >>>> However I'd disagree with a statement that "network-specific > > >>>> attributes" seems to directly describe "NAT64 and the exact values" > > >>>> rather than their presence“. > > >>>> > > >>>> It’s exactly the presence (or lack of thereof) which the device > needs > > >>>> to detect, and if there is NAT64 - then the specific prefix value. > > >>>> > > >>>> So I’d either keep the original, or propose > > >>>> NEW: > > >>>> The presence or absence of NAT64 functionality, as well as its > > >>>> associated prefix (if present), are network-dependent attributes. > > >>>> > > >>>> Thank you! > > >>>> > > >>>> On Fri, Sep 26, 2025 at 5:36 AM Alanna Paloma > > >>>> <[email protected]> wrote: > > >>>>> > > >>>>> Hi Nick, > > >>>>> > > >>>>> Thank you for your reply. We have updated as requested. > > >>>>> > > >>>>> FYI - Per your response to query 11, we have made additional > updates throughout the document to clarify the usage of RFC citation tags. > See these updates in the files below. > > >>>>> > > >>>>> The files have been posted here (please refresh): > > >>>>> https://www.rfc-editor.org/authors/rfc9872.xml > > >>>>> https://www.rfc-editor.org/authors/rfc9872.txt > > >>>>> https://www.rfc-editor.org/authors/rfc9872.html > > >>>>> https://www.rfc-editor.org/authors/rfc9872.pdf > > >>>>> > > >>>>> The relevant diff files have been posted here: > > >>>>> https://www.rfc-editor.org/authors/rfc9872-diff.html > (comprehensive diff) > > >>>>> https://www.rfc-editor.org/authors/rfc9872-auth48diff.html > (AUTH48 changes) > > >>>>> https://www.rfc-editor.org/authors/rfc9872-auth48rfcdiff.html > (AUTH48 changes 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/rfc9872 > > >>>>> > > >>>>> Thank you, > > >>>>> Alanna Paloma > > >>>>> RFC Production Center > > >>>>> > > >>>>>> … > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Cheers, Jen Linkova > > >>> > > >> > > >> > > >> -- > > >> Cheers, Jen Linkova > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
