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]
