Thank you. It looks ready to go. Russ
> On May 12, 2026, at 12:15 PM, Megan Ferguson <[email protected]> > wrote: > > Russ, > > Got it! I just wrapped this into the current version, so it will appear in > diffs with the last round of changes. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9977.txt > https://www.rfc-editor.org/authors/rfc9977.pdf > https://www.rfc-editor.org/authors/rfc9977.html > https://www.rfc-editor.org/authors/rfc9977.xml > > The diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9977-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9977-rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9977-auth48diff.html (AUTH48 only) > https://www.rfc-editor.org/authors/rfc9977-auth48rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9977-lastdiff.html > https://www.rfc-editor.org/authors/rfc9977-lastrfcdiff.html (side by side) > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9977 > > Thank you. > > Megan Ferguson > RFC Production Center > >> On May 12, 2026, at 7:18 AM, Russ Housley <[email protected]> wrote: >> >> Megan: >> >> In the example appendix, I missed the line with "Error: Spurious zero bits >> in bitstring." Please delete that line. It is a problem with the tool, not >> the example. >> >> Russ >> >>> On May 11, 2026, at 6:42 PM, Megan Ferguson >>> <[email protected]> wrote: >>> >>> Authors (and *Mahesh), >>> >>> [*Mahesh - did the pointer Russ sent help you out? Let us know if you need >>> anything else on this.] >>> >>> Thank you for your replies. We have updated as requested and reposted the >>> files. >>> >>> A further question that came up when removing the added figure numbering: >>> should <artwork> throughout the document actually be in <sourcecode> with >>> type=x509? See >>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types for more >>> information. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9977.txt >>> https://www.rfc-editor.org/authors/rfc9977.pdf >>> https://www.rfc-editor.org/authors/rfc9977.html >>> https://www.rfc-editor.org/authors/rfc9977.xml >>> >>> The diff files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9977-diff.html (comprehensive) >>> https://www.rfc-editor.org/authors/rfc9977-rfcdiff.html (side by side) >>> >>> https://www.rfc-editor.org/authors/rfc9977-auth48diff.html (AUTH48 only) >>> https://www.rfc-editor.org/authors/rfc9977-auth48rfcdiff.html (side by side) >>> >>> https://www.rfc-editor.org/authors/rfc9977-lastdiff.html >>> https://www.rfc-editor.org/authors/rfc9977-lastrfcdiff.html (side by side) >>> >>> The AUTH48 status page for this document is available here: >>> https://www.rfc-editor.org/auth48/rfc9977 >>> >>> Thank you. >>> >>> Megan Ferguson >>> RFC Production Center >>> >>>> On May 11, 2026, at 8:08 AM, Oliver Gasser <[email protected]> wrote: >>>> >>>> Dear Megan, >>>> >>>> On 5/8/26 7:47 PM, Megan Ferguson wrote: >>>>> All, >>>>> *AD - please review and approve the updates to the “Example” Appendix >>>>> addressing the following update from Russ: >>>>>> I found an error in the example in the appendix. There is a typo in the >>>>>> content type object identifier. it is using 1.2.840.113549.1.9.16.1.47; >>>>>> it should be 1.2.840.113549.1.9.16.1.57. >>>>> Thank you for your replies and guidance. We have updated the document as >>>>> requested thus far. Please note that we made a few slight tweaks, so be >>>>> sure to review carefully and let us know if any further changes are >>>>> necessary. (Russ - note that the Appendix now has figure numbering - >>>>> please let me know if you’d like us to strip them out again, add a title >>>>> to them, or leave them as they currently appear). >>>>> We had two further questions: >>>>> 1) With regard to question 3, we see some differing opinions in your >>>>> responses: >>>>>>>> 3) <!--[rfced] We had a few questions about the following text: >>>>>>>> Original: >>>>>>>> Prefix length files can contain sub-prefixes entries of a parent >>>>>>>> prefix, which needs to be taken into account when processing these >>>>>>>> files. >>>>>>>> a) Please confirm the use of the plural "sub-prefixes". >>>>>>>> Perhaps: >>>>>>>> Prefix length files can contain sub-prefix entries of a parent >>>>>>>> prefix,.. >>>>> Randy: common term, ok >>>>>>>> b) Might this sentence be rephrased as: >>>>>>>> Perhaps: >>>>>>>> Prefix length files can contain sub-prefix entries of a parent prefix; >>>>>>>> this needs to be taken into account when processing these files. >>>>>>>> —> >>>>>>> >>>>>>> Oliver: Option b) reads better to me. >>>>> Russ: I think a) reads well, but my co-authors ought to weigh in on this >>>>> one. >>>>> Randy: i do not see value in the added text. the whole document describes >>>>> things which should be taken into account >>>>> [rfced] Apologies if our question was unclear. Our main issue with the >>>>> text is that "sub-prefixes entries” seems problematic with them both >>>>> being plural and wanted to confirm this was not a possessive relationship >>>>> missing an apostrophe or something. We suggested (b) simply because the >>>>> relative pronoun “which” was carrying a heavy load for the reader (all of >>>>> the text before it). However, Randy’s comment seems to imply that even >>>>> the original text might not need the text after the comma. >>>>> Please confer amongst yourselves and let us know what you decide. >>>> >>>> We've confirmed among the four authors that we will go with option b) >>>> without any other changes to the text. >>>> >>>>> 2) Looking at the following text: >>>>> Original: >>>>> At the time of publishing this document, the registry data published >>>>> by ARIN are not the same RPSL as that of the other registries (see >>>>> [RFC7485] for a survey of the WHOIS Tower of Babel);… >>>>> We don’t see mention of the exact phrase "WHOIS Tower of Babel" in RFC >>>>> 7485. The only mention of that exact phrasing we see in the RFC Series >>>>> is in RFC 9632. Please confirm that the citation and/or the text >>>>> surrounding it appears as intended. >>>>> The files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9977.txt >>>>> https://www.rfc-editor.org/authors/rfc9977.pdf >>>>> https://www.rfc-editor.org/authors/rfc9977.html >>>>> https://www.rfc-editor.org/authors/rfc9977.xml >>>>> The diff files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9977-diff.html (comprehensive) >>>>> https://www.rfc-editor.org/authors/rfc9977-rfcdiff.html (side by side) >>>>> https://www.rfc-editor.org/authors/rfc9977-auth48diff.html (AUTH48 only) >>>>> https://www.rfc-editor.org/authors/rfc9977-auth48rfcdiff.html (side by >>>>> side) >>>>> The AUTH48 status page for this document is available here: >>>>> https://www.rfc-editor.org/auth48/rfc9977 >>>>> Thank you. >>>>> Megan Ferguson >>>>> RFC Production Center >>>>>> On May 8, 2026, at 4:25 AM, Oliver Gasser >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> On 5/6/26 10:38 PM, [email protected] wrote: >>>>>>> 2) <!--[rfced] Please clarify the antecedent of "this": >>>>>>> Original: >>>>>>> In all places Carrier-Grade NAT or CGN is used in this document, this >>>>>>> applies to proxies as well. >>>>>>> --> >>>>>> >>>>>> Either of the fixes proposed by Russ and Randy read well to me. >>>>>> >>>>>>> 3) <!--[rfced] We had a few questions about the following text: >>>>>>> Original: >>>>>>> Prefix length files can contain sub-prefixes entries of a parent >>>>>>> prefix, which needs to be taken into account when processing these >>>>>>> files. >>>>>>> a) Please confirm the use of the plural "sub-prefixes". >>>>>>> Perhaps: >>>>>>> Prefix length files can contain sub-prefix entries of a parent >>>>>>> prefix,.. >>>>>>> b) Might this sentence be rephrased as: >>>>>>> Perhaps: >>>>>>> Prefix length files can contain sub-prefix entries of a parent prefix; >>>>>>> this needs to be taken into account when processing these files. >>>>>>> --> >>>>>> >>>>>> Option b) reads better to me. >>>>>> >>>>>> >>>>>>> 7) <!-- [rfced] Regarding reference entries [INET6NUM] and [INETNUM]: >>>>>>> The original URLs for [INET6NUM] and [INETNUM] point to a page with an >>>>>>> "Sorry, we can't seem to find the page you're looking for" error >>>>>>> message. >>>>>>> We found the following URL that seems to contain the information from >>>>>>> the original URLs: >>>>>>> https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects >>>>>>> Is this the appropriate URL for these references? >>>>>>> --> >>>>>> >>>>>> Yes, that's the appropriate URL. Given that the URL contains >>>>>> descriptions for both the intetnum: and inetnum6: DB class, I suggest to >>>>>> update the text as follows: >>>>>> >>>>>> Original: >>>>>> >>>>>> The reader may find [INETNUM] and [INET6NUM] informative, and certainly >>>>>> more verbose, descriptions of the inetnum: database classes. >>>>>> >>>>>> New: >>>>>> >>>>>> The reader may find [DBOBJECTS] informative, and certainly more verbose, >>>>>> descriptions of the inetnum: and inet6num: database classes. >>>>>> >>>>>> >>>>>> [DBOBJECTS] should then replace [INET6NUM] and [INETNUM] in the >>>>>> references. >>>>>> >>>>>> >>>>>>> 8) <!-- [rfced] Regarding reference entry [PREFIXLEN-FINDER:] Please >>>>>>> review. References to GitHub >>>>>>> repositories require a commit hash (see: >>>>>>> https://www.rfc-editor.org/styleguide/part2/#ref_repo). The original >>>>>>> date for this reference - June 2021 - does not appear in this >>>>>>> repositories commit history >>>>>>> (https://github.com/massimocandela/prefixlen-finder/commits/main/). May >>>>>>> we update this reference to use the most recent commit date and commit >>>>>>> hash? >>>>>>> Current: >>>>>>> [PREFIXLEN-FINDER] >>>>>>> "prefixlen-finder", June 2021, >>>>>>> <https://github.com/massimocandela/prefixlen-finder>. >>>>>>> Perhaps: >>>>>>> [PREFIXLEN-FINDER] >>>>>>> "prefixlen-finder", commit fa70e6b, 3 June 2025, >>>>>>> <https://github.com/massimocandela/prefixlen-finder>. >>>>>>> --> >>>>>> >>>>>> >>>>>> >>>>>>> 10) <!--[rfced] We had the following questions/comments related to >>>>>>> terminology used throughout the document: >>>>>>> a) we have used the hyphenated end-site throughout; please let us know >>>>>>> any objections. >>>>>>> --> >>>>>> >>>>>> Fine by me as well. >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Oliver >>>>>> >>>>>>> Thank you. >>>>>>> Megan Ferguson >>>>>>> RFC Production Center >>>>>>> *****IMPORTANT***** >>>>>>> Updated 2026/05/06 >>>>>>> RFC Author(s): >>>>>>> -------------- >>>>>>> Instructions for Completing AUTH48 >>>>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>>> If an author is no longer available, there are several remedies >>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>>> your approval. >>>>>>> Planning your review >>>>>>> --------------------- >>>>>>> Please review the following aspects of your document: >>>>>>> * RFC Editor questions >>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>> that have been included in the XML file as comments marked as >>>>>>> follows: >>>>>>> <!-- [rfced] ... --> >>>>>>> These questions will also be sent in a subsequent email. >>>>>>> * Changes submitted by coauthors >>>>>>> Please ensure that you review any changes submitted by your >>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>> agree to changes submitted by your coauthors. >>>>>>> * Content >>>>>>> Please review the full content of the document, as this cannot >>>>>>> change once the RFC is published. Please pay particular attention to: >>>>>>> - IANA considerations updates (if applicable) >>>>>>> - contact information >>>>>>> - references >>>>>>> * Copyright notices and legends >>>>>>> Please review the copyright notice and legends as defined in >>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>> (TLP – https://trustee.ietf.org/license-info). >>>>>>> * Semantic markup >>>>>>> Please review the markup in the XML file to ensure that elements of >>>>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>>>> and <artwork> are set correctly. See details at >>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>>> * Formatted output >>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>> formatted output, as generated from the markup in the XML file, is >>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>> limitations compared to the PDF and HTML. >>>>>>> Submitting changes >>>>>>> ------------------ >>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>>>> the parties CCed on this message need to see your changes. The parties >>>>>>> include: >>>>>>> * your coauthors >>>>>>> * [email protected] (the RPC team) >>>>>>> * other document participants, depending on the stream (e.g., >>>>>>> IETF Stream participants are your working group chairs, the >>>>>>> responsible ADs, and the document shepherd). >>>>>>> * [email protected], which is a new archival mailing >>>>>>> list >>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>> list: >>>>>>> * More info: >>>>>>> >>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>>>> * The archive itself: >>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>>>> If needed, please add a note at the top of the message that you >>>>>>> have dropped the address. When the discussion is concluded, >>>>>>> [email protected] will be re-added to the CC list and >>>>>>> its addition will be noted at the top of the message. >>>>>>> You may submit your changes in one of two ways: >>>>>>> An update to the provided XML file >>>>>>> — OR — >>>>>>> An explicit list of changes in this format >>>>>>> Section # (or indicate Global) >>>>>>> OLD: >>>>>>> old text >>>>>>> NEW: >>>>>>> new text >>>>>>> You do not need to reply with both an updated XML file and an explicit >>>>>>> list of changes, as either form is sufficient. >>>>>>> We will ask a stream manager to review and approve any changes that seem >>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of >>>>>>> text, >>>>>>> and technical changes. Information about stream managers can be found >>>>>>> in >>>>>>> the FAQ. Editorial changes do not require approval from a stream >>>>>>> manager. >>>>>>> Approving for publication >>>>>>> -------------------------- >>>>>>> To approve your RFC for publication, please reply to this email stating >>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>> Files >>>>>>> ----- >>>>>>> The files are available here: >>>>>>> https://www.rfc-editor.org/authors/rfc9977.xml >>>>>>> https://www.rfc-editor.org/authors/rfc9977.html >>>>>>> https://www.rfc-editor.org/authors/rfc9977.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9977.txt >>>>>>> Diff file of the text: >>>>>>> https://www.rfc-editor.org/authors/rfc9977-diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9977-rfcdiff.html (side by side) >>>>>>> Diff of the XML: >>>>>>> https://www.rfc-editor.org/authors/rfc9977-xmldiff1.html >>>>>>> Tracking progress >>>>>>> ----------------- >>>>>>> The details of the AUTH48 status of your document are here: >>>>>>> https://www.rfc-editor.org/auth48/rfc9977 >>>>>>> Please let us know if you have any questions. >>>>>>> Thank you for your cooperation, >>>>>>> RFC Editor >>>>>>> -------------------------------------- >>>>>>> RFC9977 (draft-ietf-opsawg-prefix-lengths-14) >>>>>>> Title : Publishing End-Site Prefix Lengths >>>>>>> Author(s) : O. Gasser, R. Bush, M. Candela, R. Housley >>>>>>> WG Chair(s) : Joe Clarke, Benoît Claise >>>>>>> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani >>>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
