Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!-- [rfced] Abstract a) We updated the text starting with "which does not..." as follows to improve readability; please review and let us know any concerns. Original: This document specifies Protocol Independent Multicast Light (PIM Light) and PIM Light Interface (PLI) which does not need PIM Hello message to accept PIM Join/Prune messages. PLI can signal multicast states over networks that can not support full PIM neighbor discovery, as an example BIER networks that are connecting two or more PIM domains. Perhaps: This document specifies Protocol Independent Multicast Light (PIM Light) and the PIM Light Interface (PLI). A PLI does not need a PIM Hello message to accept PIM Join/Prune messages, and it can signal multicast states over networks that cannot support full PIM neighbor discovery, such as Bit Index Explicit Replication (BIER) networks that connect two or more PIM domains. b) Should "protocol and procedures" be updated to just "procedures" as in the Introduction? Original: This document outlines the PIM Light protocol and procedures to ensure loop-free multicast traffic between two or more PIM Light routers. Perhaps: This document outlines PIM Light procedures to ensure loop-free multicast traffic between two or more PIM Light routers. --> 3) <!-- [rfced] This is a sentence fragment. How may we update to make a complete sentence? Also, please confirm that "network" is intended here; elsewhere in the document, we see "BIER domain" rather than "BIER network". Original: For example, in a Bit Index Explicit Replication (BIER) [RFC8279] networks connecting multiple PIM domains, where PIM Join/Prune messages are tunneled via BIER as specified in [draft-ietf-bier-pim-signaling]. Perhaps: An example is a Bit Index Explicit Replication (BIER) [RFC8279] network connecting multiple PIM domains, where PIM Join/Prune messages are tunneled via BIER as specified in [BIER-PIM]. Or: For example, in a Bit Index Explicit Replication (BIER) [RFC8279] network connecting multiple PIM domains, PIM Join/Prune messages are tunneled via BIER as specified in [draft-ietf-bier-pim-signaling]. --> 4) <!-- [rfced] Please clarify the text starting with "to ensure...". Also, is "reviver" correct? Or is "receiver" or something else intended? Original: As an example the implementation should ensure that DR election is done on upstream Redundant PIM routers that are at the edge of the PIM Light Domain to ensure a single Designated Router to forward the PIM Join message from reviver to the Source. Perhaps: As an example, the implementation should ensure that DR election is done on upstream redundant PIM routers that are at the edge of the PIM Light domain to ensure that a single DR forwards the PIM Join message from the receiver to the source. --> 5) <!-- [rfced] FYI - We reordered the list in Section 3.1 by type number as only one was out of order. --> 6) <!-- [rfced] Is the text starting with "from the..." needed here? Other entries in the list do not have such notes, and in the IANA registry (linked to in the text introducing this list), RFC 7761 is listed as a reference for type 3. See https://www.iana.org/assignments/pim-parameters/. Original: 1. type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types listed in [RFC7761]. Current: * type 3 (Join/Prune) (Note that this type is from the ALL-PIM- ROUTERS message types listed in [RFC7761].) Perhaps: * type 3 (Join/Prune) --> 7) <!-- [rfced] FYI - We updated "13" to "13.0" to match the registry at https://www.iana.org/assignments/pim-parameters/. Original: type 13 (PIM Packed Null-Register) Updated: type 13.0 (PIM Packed Null-Register) --> 8) <!-- [rfced] Is "unicast destination IP" correct here, or should it be "unicast destination IP addresses" (with "addresses")? Original: 7. Any future PIM message types that use unicast destination IP. Perhaps: * Any future PIM message types that use unicast destination IP addresses. --> 9) <!-- [rfced] Will readers know what both instances of "it" refer to in the text "it SHOULD NOT process a join message containing it"? Original: As such, PIM Light is unaware of its neighbor's capability to process join attributes and it SHOULD NOT process a join message containing it. Perhaps: As such, PIM Light is unaware of its neighbor's capability to process join attributes and SHOULD NOT process a Join message containing a join attribute. --> 10) <!-- [rfced] We note that the sentence below in Section 3.2.2 uses "PIM networks" but the figure uses "PIM domain". Are any updates needed? Original: For instance, in a BIER domain connecting two PIM networks, a PLI can be used between BIER edge routers solely for multicast state communication and transmit only PIM Join/Prune messages. Perhaps: For instance, in a BIER domain connecting two PIM domains, a PLI can be used between BIER edge routers solely for multicast state communication and transmit only PIM Join/Prune messages. --> 11) <!-- [rfced] Please clarify "An example DR election could be DR election". Original: An example DR election could be DR election between router D and F in above figure. Perhaps: For example, DR election could be between router D and F in above figure. --> 12) <!-- [rfced] In Sections 3.2.2 and 3.4, we recommend including text to introduce figure. In Section 3.2.2, perhaps the second paragraph can be moved before the figure and first sentence of that paragraph updated in one of the following ways. Original: For instance, in a BIER domain connecting two PIM networks, a PLI can be used between BIER edge routers solely for multicast state communication and transmit only PIM Join/Prune messages. Perhaps (add "as in the figure below"): For instance, in a BIER domain connecting two PIM networks as in the figure below, a PLI can be used between BIER edge routers solely for multicast state communication and transmit only PIM Join/Prune messages. Or (use two sentences): For instance, the figure below depicts a BIER domain connecting two PIM networks. A PLI can be used between BIER edge routers solely for multicast state communication and transmit only PIM Join/Prune messages. In Section 3.4, perhaps the last paragraph can be moved before the figure and updated as follows. Original: In another example, where the PLI is configured automatically between the BIER Edge Routers (BER), when the downstream BIER Edge Router (DBER) is no longer reachable on the upstream BIER Edge Router (UBER), the UBER which is also a PIM Light Router can prune the <S,G> advertised toward the source on the PIM domain to stop the transmission of the multicast stream. Perhaps: In another example, the PLI is configured automatically between the BIER Edge Routers (BERs) as in the figure below. When the downstream BIER Edge Router (DBER) is no longer reachable on the upstream BIER Edge Router (UBER), the UBER (which is also a PIM Light router) can prune the <S,G> advertised toward the source on the PIM domain to stop the transmission of the multicast stream. --> 13) <!-- [rfced] May we move the text "to prevent multicast stream duplication" as follows to improve readability? Original: If there are redundant PIM routers at the edge of the BIER domain, to prevent multicast stream duplication, they MUST establish PIM adjacency as per [RFC7761] to ensure DR election at the edge of BIER domain. Perhaps: If there are redundant PIM routers at the edge of the BIER domain, they MUST establish PIM adjacency as per [RFC7761] to prevent multicast stream duplication and to ensure DR election at the edge of the BIER domain. --> 14) <!-- [rfced] We updated this sentence as follows; please review and let us know any concerns. Original: If a router supports PIM Light, only when PLI is enabled on an interface, arriving Join/Prune messages MUST be processed, otherwise they MUST be dropped. Updated: If a router supports PIM Light, arriving Join/Prune messages MUST be processed only when a PLI is enabled on an interface; otherwise, they MUST be dropped. --> 15) <!-- [rfced] This sentence does not parse. We updated as follows. Let us know any concerns. Original: While on some logical interfaces PLI maybe enabled automatically or via an underlying mechanism, as an example the logical interface connecting two or more BIER edge routers in a BIER subdomain [draft-ietf-bier-pim-signaling]. Updated: PLI may be enabled automatically or via an underlying mechanism on some logical interfaces (for example, the logical interface connecting two or more BIER edge routers in a BIER subdomain [BIER-PIM]). --> 16) <!-- [rfced] We confirmed that port 8471 is correct in this sentence per the registry at https://www.iana.org/assignments/service-names-port-numbers. In the registry, we see that port 8471 is also for PORT with SCTP as the transport protocol. This sentence just mentions TCP, though SCTP is mentioned in the next sentence. Are any updates needed? Original: For TCP, PIM over reliable transport (PORT) uses port 8471 which is assigned by IANA. --> 17) <!-- [rfced] The first sentence below uses "MUST", but the second uses "must" (although it says "the same is true"). Please review and let us know if any updates are needed. Original: [RFC6559] mentions that when a router is configured to use PIM over TCP on a given interface, it MUST include the PIM-over-TCP-Capable Hello Option in its Hello messages for that interface. The same is true for SCTP and the router must include PIM-over-SCTP-Capable Hello Option in its Hello message on that interface. Perhaps: [RFC6559] mentions that when a router is configured to use PIM over TCP on a given interface, it MUST include the PIM-over-TCP-Capable Hello Option in its Hello messages for that interface. The same is true for SCTP; the router MUST include the PIM-over-SCTP-Capable Hello Option in its Hello message on that interface. --> 18) <!-- [rfced] Will readers understand "Connection ID IP address comparison"? What is being compared? Original: When the router is using SCTP, the Connection ID IP address comparison need not be done since the SCTP can handle call collision. --> 19) <!-- [rfced] This sentence in Section 3.5 explains that a Connection ID is an IPv4 or IPv6 address used to establish the SCTP or TCP connection: Original These Hello options contain a Connection ID which is an IPv4 or IPv6 address used to establish the SCTP or TCP connection. The sentence below appears in the next paragraph. Should the text starting with "Connection ID IPv4 or IPv6 addresses..." be updated for consistency with the previous text? Original: PIM Light lacks Hello messages, the PLI can be configured with the Connection ID IPv4 or IPv6 addresses used to establish the SCTP or TCP connection. Perhaps: Because PIM Light lacks Hello messages, the PLI can be configured with the Connection ID (i.e., the IPv4 or IPv6 address used to establish the SCTP or TCP connection). Or: Because PIM Light lacks Hello messages, the PLI can be configured with the Connection ID. --> 20) <!-- [rfced] Should "Source-Specific and Sparse Mode Join/Prune messages" here be updated to "PIM-SSM and PIM-SM Join/Prune messages"? Original: Furthermore, because PIM Light can be used for signaling Source- Specific and Sparse Mode Join/Prune messages, the security considerations outlined in [RFC7761] and [RFC4607] SHOULD be considered where appropriate. Perhaps: Furthermore, because PIM Light can be used for signaling PIM-SSM and PIM-SM Join/Prune messages, the security considerations outlined in [RFC7761] and [RFC4607] SHOULD be considered where appropriate. --> 21) <!-- [rfced] Terminology a) These terms are used inconsistently throughout the text. Should these be uniform? If so, please let us know which form is preferred. DR Election vs. DR election <S,G> vs. (S,G) b) We also note inconsistencies in the terms listed below. We chose the form on the right. Please let us know any objections. PIM Light Router vs. PIM Light router PIM Light Domain vs. PIM Light domain connection ID vs Connection ID Source vs. source join message vs. Join message join/prune message vs. Join/Prune message c) Should "join attribute" be capitalized per usage in RFC 5384? d) Article usage (e.g., "a" and "the") with "PIM Light Interface" and "PLI" was mixed. We added articles in some instances. Please review for correctness. --> 22) <!-- [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. --> Thank you. RFC Editor/rv On Feb 10, 2025, at 8:38 PM, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/02/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/rfc9739.xml https://www.rfc-editor.org/authors/rfc9739.html https://www.rfc-editor.org/authors/rfc9739.pdf https://www.rfc-editor.org/authors/rfc9739.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9739-diff.html https://www.rfc-editor.org/authors/rfc9739-rfcdiff.html (side by side) Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved): https://www.rfc-editor.org/authors/rfc9739-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9739-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9739 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9739 (draft-ietf-pim-light-11) Title : Protocol Independent Multicast Light (PIM Light) Author(s) : H. Bidgoli, S. Venaas, M. Mishra, Z. Zhang, M. McBride 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
