Hi Brian,

Thank you for your reply.  We have noted your approval on the AUTH48 status 
page (https://www.rfc-editor.org/auth48/rfc9778). 

This concludes the AUTH48 process for this document. We will move this document 
forward in the publication process along with RFCs-to-be 9776 and 9777 when 
approved/complete.

Best regards,
RFC Editor/kc

> On Mar 17, 2025, at 7:26 AM, Brian Haberman <br...@innovationslab.net> wrote:
> 
> Hi Karen,
>     All looks good! No additional keywords to add.
> 
> Regards,
> Brian
> 
>> On Mar 14, 2025, at 6:34 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote:
>> 
>> Hi Brian,
>> 
>> Thank you for your reply.  We have updated our files accordingly. Please 
>> review and let us know if any further updates are needed or if you approve 
>> the document in its current form.
>> 
>> Additionally, if you would like to add any keywords (beyond those in the 
>> title) for use on https://www.rfc-editor.org/search, please let us know.
>> 
>> Note that we will update the references to RFCs-to-be 9776 and 9777 to be 
>> STDs prior to publication. 
>> 
>> --FILES--
>> The updated XML file is here:
>> https://www.rfc-editor.org/authors/rfc9778.xml
>> 
>> The updated output files are here:
>> https://www.rfc-editor.org/authors/rfc9778.txt
>> https://www.rfc-editor.org/authors/rfc9778.pdf
>> https://www.rfc-editor.org/authors/rfc9778.html
>> 
>> These diff files show all changes made during AUTH48:
>> https://www.rfc-editor.org/authors/rfc9778-auth48diff.html
>> https://www.rfc-editor.org/authors/rfc9778-auth48rfcdiff.html (side by side)
>> 
>> These diff files show all changes made to date:
>> https://www.rfc-editor.org/authors/rfc9778-diff.html
>> https://www.rfc-editor.org/authors/rfc9778-rfcdiff.html (side by side)
>> 
>> Note that it may be necessary for you to refresh your browser to view the 
>> most recent version. Please review the document carefully to ensure 
>> satisfaction as we do not make changes once it has been published as an RFC.
>> 
>> Please contact us with any further updates or with your approval of the 
>> document in its current form.  We will await approval from the author prior 
>> to moving forward in the publication process.
>> 
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9778
>> 
>> Thank you,
>> RFC Editor/kc
>> 
>> 
>>> On Mar 11, 2025, at 1:04 PM, Brian Haberman via auth48archive 
>>> <auth48archive@rfc-editor.org> wrote:
>>> 
>>> Responses to the RFC Editor questions are inline...
>>> 
>>>> On Mar 11, 2025, at 2:24 AM, rfc-edi...@rfc-editor.org wrote:
>>>> 
>>>> Brian,
>>>> 
>>>> Authors,
>>>> 
>>>> While reviewing this document during AUTH48, please resolve (as necessary) 
>>>> the following questions, which are also in the XML file.
>>>> 
>>>> 1) <!--[rfced] The short title that spans the header of the PDF file has
>>>> been updated as follows to more closely align with the document
>>>> title. Please let us know of any objections.
>>>> 
>>>> Original:
>>>> IGMP IANA
>>>> 
>>>> Current:
>>>> IANA Considerations for IGMP
>>>> -->
>>> 
>>> No objections.
>>> 
>>>> 
>>>> 
>>>> 2) <!--[rfced] This document obsoletes RFC 3228, which was BCP 57.  As 
>>>> such, we have assigned BCP 57 to this document.  Please let us know any 
>>>> changes are needed.  
>>>> 
>>>> See the complete list of BCPs here:
>>>> https://www.rfc-editor.org/bcps
>>>> -->
>>> 
>>> Looks good.
>>> 
>>>> 
>>>> 
>>>> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in
>>>> the title) for use on https://www.rfc-editor.org/search. -->
>>>> 
>>>> 
>>>> 4) <!-- [rfced] For ease of the reader, we suggest including the IANA 
>>>> registry name.  Do the types and codes get registered in the Internet 
>>>> Control Message Protocol (ICMP) Parameters registry 
>>>> <https://www.iana.org/assignments/icmp-parameters>?  However, we don't see 
>>>> "IETF Review" listed 
>>>> as the registration procedure for any of the registries on that page. 
>>>> 
>>>> Perhaps this refers to the "IGMP/MLD Extension Types" registry, which 
>>>> lists 
>>>> IETF Review and includes a range for Experimental Use? 
>>>> 
>>>> Original:
>>>> 2.1.2.  Multicast Listener Discovery
>>>> 
>>>> As with IGMP, the MLD header also contains Type and Code fields.
>>>> Assignment of those fields within the MLD header is defined in
>>>> [RFC4443] with a registration policy of IETF Review.
>>>> -->
>>> 
>>> The MLD-related tables are in the ICMPv6 Type registry
>>> https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2
>>> 
>>>> 
>>>> 
>>>> 5) <!--[rfced] For easy reference, would you like to add section numbers
>>>> to the following text? If so, please confirm that Sections 5.1
>>>> and 5.2 of [RFC9777] and Sections 4.1 and 4.2 of [RFC9776] are
>>>> correct. Note that there are two instances in the text.
>>>> 
>>>> Original:
>>>> The Flags Bit value in the registry above corresponds to the column header
>>>> in the packet format diagrams in [I-D.ietf-pim-3810bis] and
>>>> [I-D.ietf-pim-3376bis].
>>>> 
>>>> Perhaps:
>>>> The Flags Bit value in the registry above corresponds to the column header
>>>> in the packet format diagrams in Sections 5.1 and 5.2 of [RFC9777] and 
>>>> Sections 4.1 and 4.2 of [RFC9776].
>>>> -->
>>> 
>>> Yes, please add the section numbers (and those are the correct section 
>>> numbers).
>>>> 
>>>> 
>>>> 6) <!-- [rfced] Because the E-bit appears in both tables with a reference, 
>>>> the text that follows seems redundant.  Perhaps "The initial contents..." 
>>>> text can be removed? 
>>>> 
>>>>    | 0         |     E      | Extension   | RFC 9279  |
>>>> 
>>>> ... 
>>>> The initial contents of this requested registry should contain the
>>>> E-bit defined in [RFC9279].
>>>> 
>>>> 
>>>>    | 0         |     E      | Extension   | RFC 9279  |
>>>> 
>>>> ... 
>>>> The initial contents of this requested registry should contain the
>>>> E-bit defined in [RFC9279].
>>>> -->
>>> 
>>> Yes, that clause can be dropped.
>>> 
>>>> 
>>>> 
>>>> 7) <!-- [rfced] As RFCs 9776 and 9777 are being with this document, please 
>>>> consider whether the references should be to the individual RFCs or the 
>>>> STDs instead. 
>>>> —>
>>> 
>>> I think the references should be to the STDs.
>>> 
>>>> 
>>>> 
>>>> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the 
>>>> online Style Guide 
>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>> and let us know if any changes are needed.  Updates of this nature 
>>>> typically result in more precise language, which is helpful for readers.
>>>> 
>>>> Note that our script did not flag any words in particular, but this should 
>>>> still be reviewed as a best practice.
>>>> -->
>>> 
>>> This all seems good.
>>> 
>>> Regards,
>>> Brian
>>> 
>>>> 
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Mar 10, 2025, at 11:07 PM, rfc-edi...@rfc-editor.org wrote:
>>>> 
>>>> *****IMPORTANT*****
>>>> 
>>>> Updated 2025/03/10
>>>> 
>>>> 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
>>>> 
>>>> *  rfc-edi...@rfc-editor.org (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).
>>>> 
>>>> *  auth48archive@rfc-editor.org, 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, 
>>>>      auth48archive@rfc-editor.org 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/rfc9778.xml
>>>> https://www.rfc-editor.org/authors/rfc9778.html
>>>> https://www.rfc-editor.org/authors/rfc9778.pdf
>>>> https://www.rfc-editor.org/authors/rfc9778.txt
>>>> 
>>>> Diff file of the text:
>>>> https://www.rfc-editor.org/authors/rfc9778-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9778-rfcdiff.html (side by side)
>>>> 
>>>> Diff of the XML: 
>>>> https://www.rfc-editor.org/authors/rfc9778-xmldiff1.html
>>>> 
>>>> 
>>>> Tracking progress
>>>> -----------------
>>>> 
>>>> The details of the AUTH48 status of your document are here:
>>>> https://www.rfc-editor.org/auth48/rfc9778
>>>> 
>>>> Please let us know if you have any questions.  
>>>> 
>>>> Thank you for your cooperation,
>>>> 
>>>> RFC Editor
>>>> 
>>>> --------------------------------------
>>>> RFC 9778 (draft-ietf-pim-3228bis-07)
>>>> 
>>>> Title            : IANA Considerations for Internet Group Management 
>>>> Protocols
>>>> Author(s)        : B. Haberman
>>>> WG Chair(s)      : Stig Venaas, Mike McBride
>>>> 
>>>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde
>>>> 
>>>> 
>>> 
>>> -- 
>>> auth48archive mailing list -- auth48archive@rfc-editor.org
>>> To unsubscribe send an email to auth48archive-le...@rfc-editor.org
>> 
> 

-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org

Reply via email to