Hi Megan, It is not clear to me which exact change you are asking me to approve. The typo that Russ is referring to does not seem to appear in the Appendix if I look at the draft here:
https://www.rfc-editor.org/authors/rfc9977.html It appears in Sections 6 and 10 and not in the Appendix. If I look at the diffs, and specifically rfcdiff, I see a change from TBD to .57, not .47 to .57. And auth48rfcdiff does not show any such change. Thanks. > On May 8, 2026, at 10:47 AM, Megan Ferguson <[email protected]> > 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. > > 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 >> > Mahesh Jethanandani [email protected]
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
