Mahesh: The typo is in the Base64 encoded CMS blob.
Russ > On May 8, 2026, at 8:31 PM, Mahesh Jethanandani <[email protected]> > wrote: > > 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]
