Hi Karen,
All looks good! No additional keywords to add.
Regards,
Brian
> On Mar 14, 2025, at 6:34 PM, Karen Moore <[email protected]> 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
>> <[email protected]> wrote:
>>
>> Responses to the RFC Editor questions are inline...
>>
>>> On Mar 11, 2025, at 2:24 AM, [email protected] 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, [email protected] 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
>>>
>>> * [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/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 -- [email protected]
>> To unsubscribe send an email to [email protected]
>
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
