Hi Gunter and authors, Gunter - Thanks for the response. We have marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9739).
All - Once Zhaohui Zhang approves the document, we can move forward in the publication process. Best regards, RFC Editor/rv > On Feb 19, 2025, at 10:03 PM, Gunter van de Velde (Nokia) > <gunter.van_de_ve...@nokia.com> wrote: > > Hi, > > Yes, approved. > > My apologies for the delayed response. It got lost in a mountain of emails > and I accidently classified it overly fast. > > G/ > > -----Original Message----- > From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> > Sent: Thursday, February 13, 2025 8:35 AM > To: Mankamana Mishra (mankamis) <manka...@cisco.com>; Hooman Bidgoli (Nokia) > <hooman.bidg...@nokia.com>; Stig Venaas (svenaas) <sven...@cisco.com>; > s...@cisco.com; zzh...@juniper.com; michael.mcbr...@futurewei.com; Gunter van > de Velde (Nokia) <gunter.van_de_ve...@nokia.com> > Cc: pim-...@ietf.org; RFC Editor <rfc-edi...@rfc-editor.org>; > pim-cha...@ietf.org; zhang.zh...@zte.com.cn; auth48archive@rfc-editor.org > Subject: Re: [AD] AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for your > review > > [You don't often get email from rvanrhee...@staff.rfc-editor.org. Learn why > this is important at https://aka.ms/LearnAboutSenderIdentification ] > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > Hi Stig and Mankamana, > > We have marked your approvals on the AUTH48 status page for this document. > See https://www.rfc-editor.org/auth48/rfc9739. > > Best regards, > RFC Editor/rv > > > >> On Feb 12, 2025, at 4:17 PM, Mankamana Mishra (mankamis) >> <manka...@cisco.com> wrote: >> >> I approve the change . Looks good to me . >> From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> >> Sent: Wednesday, February 12, 2025 10:28:14 PM >> To: Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com>; Mankamana >> Mishra (mankamis) <manka...@cisco.com>; Stig Venaas (svenaas) >> <sven...@cisco.com>; s...@cisco.com <s...@cisco.com>; >> zzh...@juniper.com <zzh...@juniper.com>; michael.mcbr...@futurewei.com >> <michael.mcbr...@futurewei.com>; Gunter van de Velde (Nokia) >> <gunter.van_de_ve...@nokia.com>; pim-...@ietf.org <pim-...@ietf.org> >> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; pim-cha...@ietf.org >> <pim-cha...@ietf.org>; zhang.zh...@zte.com.cn <zhang.zh...@zte.com.cn>; >> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> >> Subject: [AD] Re: AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for your >> review Hi Hooman, other authors, and AD*, >> >> Hooman - Thanks for the quick reply. All of our questions have been >> addressed. >> >> All authors - Please review the document carefully to ensure satisfaction as >> we do not make changes once it has been published as an RFC. Contact us with >> any further updates or with your approval of the document in its current >> form. We will await approvals from each author prior to moving forward in >> the publication process. >> >> *Gunter, as AD, please review and approve the following changes, which are >> above editorial. These are best viewed in this diff file: >> https://www.rfc-editor.org/authors/rfc9739-auth48diff.html. >> >> - Change from “must” to “MUST” in last sentence of first paragraph in >> Section 3.5 (corresponds with “MUST” in previous sentence) >> - Change in last sentence of second paragraph in Section 3.5 >> - Change in second paragraph in Section 5 (author explanation: I think >> we should remove "PIM-SSM and" here. PIM-SM Join/Prune messages are >> also used both for SSM and not SSM and the security implications are >> the same.) >> >> — FILES (please refresh) — >> >> Updated XML file: >> https://www.rfc-editor.org/authors/rfc9739.xml >> >> Updated output files: >> https://www.rfc-editor.org/authors/rfc9739.txt >> https://www.rfc-editor.org/authors/rfc9739.pdf >> https://www.rfc-editor.org/authors/rfc9739.html >> >> Diff file showing changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9739-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9739-auth48rfcdiff.html (side >> by side) >> >> Diff files showing all changes: >> https://www.rfc-editor.org/authors/rfc9739-diff.html >> https://www.rfc-editor.org/authors/rfc9739-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9739-alt-diff.html (shows >> changes where text is moved or deleted) >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9739 >> >> Thank you, >> >> RFC Editor/rv >> >> >> >>> On Feb 12, 2025, at 12:59 PM, Hooman Bidgoli (Nokia) >>> <hooman.bidg...@nokia.com> wrote: >>> >>> Hello >>> >>> Inline >>> >>> Thanks >>> Hooman >>> >>> -----Original Message----- >>> From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> >>> Sent: Wednesday, February 12, 2025 1:29 PM >>> To: Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com>; Mankamana >>> Mishra (mankamis) <mankamis=40cisco....@dmarc.ietf.org>; Stig Venaas >>> (svenaas) <sven...@cisco.com>; s...@cisco.com; zzh...@juniper.com; >>> michael.mcbr...@futurewei.com >>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; pim-...@ietf.org; >>> pim-cha...@ietf.org; zhang.zh...@zte.com.cn; Gunter van de Velde >>> (Nokia) <gunter.van_de_ve...@nokia.com>; >>> auth48archive@rfc-editor.org; Rebecca VanRheenen >>> <rvanrhee...@staff.rfc-editor.org> >>> Subject: Re: AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for >>> your review >>> >>> [You don't often get email from rvanrhee...@staff.rfc-editor.org. >>> Learn why this is important at >>> https://aka.ms/LearnAboutSenderIdentification ] >>> >>> CAUTION: This is an external email. Please be very careful when clicking >>> links or opening attachments. See the URL nok.it/ext for additional >>> information. >>> >>> >>> >>> Hi Hooman, Stig, and Mankamana, >>> >>> Thank you for your replies; we have updated the document accordingly (see >>> files below). We have two followup questions: >>> >>> A) Please confirm “network” is okay in these sentences. We ask because we >>> see "BIER domain" (rather than “BIER network”) elsewhere in the document. >>> >>> Current: >>> ...such as Bit Index Explicit Replication (BIER) networks that >>> connect two or more PIM domains. >>> ... >>> 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]. >>> >>> HB> I think in this paragraph it is fine to say BIER network connecting >>> multiple PIM domains. >>> >>> B) The following was missed in question #21. Should the capitalization of >>> this term be consistent? If so, let us know which form to use. >>> >>> DR Election vs. DR election >>> HB> lol this is a though one 😊 looking at RFC 7761 it is "DR election" 90% >>> of time but one location it says "DR Election" >>> HB> lets go with "DR election" please >>> >>> — FILES (please refresh) — >>> >>> HB> sorry what do you mean by refresh? Is there action here for the >>> authors? Or we should just review it. >>> Updated XML file: >>> https://www.rfc-editor.org/authors/rfc9739.xml >>> >>> Updated output files: >>> https://www.rfc-editor.org/authors/rfc9739.txt >>> https://www.rfc-editor.org/authors/rfc9739.pdf >>> https://www.rfc-editor.org/authors/rfc9739.html >>> >>> Diff file showing changes made during AUTH48: >>> https://www.rfc-editor.org/authors/rfc9739-auth48diff.html >>> https://www.rfc-editor.org/authors/rfc9739-auth48rfcdiff.html >>> (side by side) >>> >>> Diff files showing all changes: >>> https://www.rfc-editor.org/authors/rfc9739-diff.html >>> https://www.rfc-editor.org/authors/rfc9739-rfcdiff.html (side by side) >>> https://www.rfc-editor.org/authors/rfc9739-alt-diff.html (shows >>> changes where text is moved or deleted) >>> >>> For the AUTH48 status of this document, please see: >>> https://www.rfc-editor.org/auth48/rfc9739 >>> >>> Thank you, >>> >>> RFC Editor/rv >>> >>> >>> >>>> On Feb 11, 2025, at 5:00 PM, Mankamana Mishra (mankamis) >>>> <mankamis=40cisco....@dmarc.ietf.org> wrote: >>>> >>>> Changes looks good to me. From: Stig Venaas (svenaas) >>>> <sven...@cisco.com> >>>> Date: Tuesday, February 11, 2025 at 4:15 PM >>>> To: Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com>, >>>> rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, >>>> s...@cisco.com <s...@cisco.com>, Mankamana Mishra (mankamis) >>>> <manka...@cisco.com>, zzh...@juniper.com <zzh...@juniper.com>, >>>> michael.mcbr...@futurewei.com <michael.mcbr...@futurewei.com> >>>> Cc: pim-...@ietf.org <pim-...@ietf.org>, pim-cha...@ietf.org >>>> <pim-cha...@ietf.org>, zhang.zh...@zte.com.cn >>>> <zhang.zh...@zte.com.cn>, Gunter van de Velde (Nokia) >>>> <gunter.van_de_ve...@nokia.com>, auth48archive@rfc-editor.org >>>> <auth48archive@rfc-editor.org> >>>> Subject: RE: AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for >>>> your review Hi RFC Editor and Hooman >>>> >>>> Please see my comments inline. >>>> >>>>> -----Original Message----- >>>>> From: Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com> >>>>> Sent: Tuesday, February 11, 2025 3:10 PM >>>>> To: rfc-edi...@rfc-editor.org; s...@cisco.com; Mankamana Mishra >>>>> (mankamis) <manka...@cisco.com>; zzh...@juniper.com; >>>>> michael.mcbr...@futurewei.com >>>>> Cc: pim-...@ietf.org; pim-cha...@ietf.org; zhang.zh...@zte.com.cn; >>>>> Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; >>>>> auth48archive@rfc- editor.org >>>>> Subject: RE: AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for >>>>> your review >>>>> Importance: High >>>>> >>>>> Hi All >>>>> >>>>> My comments Inline, thanks for detail suggestions! >>>>> Co-authors any comments on my suggestions pls? >>>>> >>>>> Do I need to submit a version 12 of draft with the changes? >>>>> >>>>> Thanks >>>>> Hooman >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>> Sent: Monday, February 10, 2025 11:45 PM >>>>> To: Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com>; >>>>> s...@cisco.com; manka...@cisco.com; zzh...@juniper.com; >>>>> michael.mcbr...@futurewei.com >>>>> Cc: rfc-edi...@rfc-editor.org; pim-...@ietf.org; >>>>> pim-cha...@ietf.org; zhang.zh...@zte.com.cn; Gunter van de Velde >>>>> (Nokia) <gunter.van_de_ve...@nokia.com>; >>>>> auth48archive@rfc-editor.org >>>>> Subject: Re: AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for >>>>> your review >>>>> >>>>> >>>>> CAUTION: This is an external email. Please be very careful when >>>>> clicking links or opening attachments. See the URL nok.it/ext for >>>>> additional information. >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> HB> ok with this. >>>>> >>>>> >>>>> 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. >>>>> HB> my vote is to keep it as protocol and procedures. The doc >>>>> HB> talks about >>>>> both. >>>>> --> >>>>> >>>>> >>>>> 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]. >>>>> >>>>> HB> This text looks good. >>>>> >>>>> 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. >>>>> HB> looks good. >>>>> --> >>>>> >>>>> >>>>> 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) >>>>> >>>>> HB> I agree I am not sure why we are saying "from the >>>>> HB> ALL-PIM-ROUTERS" as >>>>> that is a multicast address. >>>>> HB> I am ok with type 3 (Join/Prune). Unless there is a counter thought. >>>>> --> >>>>> >>>>> >>>>> 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) >>>>> HB> ok >>>>> --> >>>> >>>> This really must be 13.0 but it still says 13 in the new version and diffs >>>> provided. >>>> >>>>> >>>>> 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. >>>>> HB> ok with this suggestion. >>>>> --> >>>> >>>> A given message will have only a single destination, so it seems a bit odd >>>> to me to use plural here. Maybe it can says "Any future PIM message types >>>> where the destination is a unicast IP address"? >>>> >>>> >>>>> 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. >>>>> HB> ok with suggestion >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> HB> ok with suggestions >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> HB> ok with suggestion >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> HB> I can see how it is better to have both paragraphs after each >>>>> HB> other >>>>> followed by the figure. >>>>> HB> I suggest: >>>>> HB> For instance, in a BIER domain connecting two PIM domains >>>>> HB> 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. >>>>> >>>>> 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. >>>>> >>>>> HB> following the previous example ok with this suggestion. >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> >>>>> HB> ok with suggestion. >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> >>>>> HB> Ok >>>>> --> >>>>> >>>>> >>>>> 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]). >>>>> >>>>> HB> I suggest the following >>>>> >>>>> In some cases, PKI maybe enabled automatically via an underlying >>>>> mechanisms on some logical interface. For example, in a BIER >>>>> domain a logical interface can connect two or more BIER edge >>>>> routers as per >>>>> [draft-ietf-bier- pim-signaling]. >>>>> --> >>>> >>>> I think this should be: >>>> In some cases, PLI maybe enabled automatically via an underlying >>>> mechanism on a logical interface. For example, in a BIER domain, a >>>> logical interface can connect two or more BIER edge routers as per >>>> [draft-ietf-bier- pim-signaling]. >>>> >>>>> 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. >>>>> >>>>> HB> here is a new suggestion for 16 and 17 >>>>> [RFC6559] defines a reliable transport mechanism called PIM over >>>>> reliable transport (PORT) for PIM transmission >>>>> of Join/Prune messages, using either TCP or SCTP as transport >>>>> protocol. Both TCP and SCTP use destination port number of 8471. >>>>> SCTP is explained in [RFC9260], and it is >>>>> used as a second option for PORT. [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. >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> >>>>> HB> here is suggestion for better read >>>>> >>>>> These Hello options contain a Connection ID which is an IPv4 or IPv6 >>>>> address used to establish the SCTP or TCP connection. For PORT using >>>>> TCP, the connection ID is used for determining which peer is doing an >>>>> active transport open to the neighbor and which peer is doing passive >>>>> transport open, as per section 4 of [RFC6559. When the router is using >>>>> SCTP, >>>>> the Connection ID is not used to determine the active and >>>>> passive peer since the SCTP protocol 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). >>>>> HB> ok with this option. >>>>> >>>>> 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. >>>>> HB> ok with this >>>> >>>> I think we should remove "PIM-SSM and" here. PIM-SM Join/Prune messages >>>> are also used both for SSM and not SSM and the security implications are >>>> the same. Hence, I think it should just say: >>>> >>>> Furthermore, because PIM Light can be used for signaling PIM-SM >>>> Join/Prune messages, the security considerations outlined in [RFC7761] and >>>> [RFC4607] SHOULD be considered where appropriate. >>>> >>>> Hooman/authors, do you see any specific implications to SSM? I don't see >>>> any, but if you do, I suggest adding that in a separate sentence. >>>> >>>> That is my last comment. I'm fine with all the suggested changes and >>>> Hooman's comments otherwise. >>>> >>>> Thanks, >>>> Stig >>>> >>>>> --> >>>>> >>>>> >>>>> 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) >>>>> >>>>> HB> thanks! They should be (S,G) every where. >>>>> >>>>> 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 >>>>> >>>>> HB> agreed thanks! >>>>> >>>>> c) Should "join attribute" be capitalized per usage in RFC 5384? >>>>> >>>>> HB> yes it should. >>>>> >>>>> 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://w/ >>>>> ww.rfc-%2F&data=05%7C02%7Chooman.bidgoli%40nokia.com%7C20eb5efdb6c >>>>> 34 >>>>> 817955f08dd4b931f11%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C6 >>>>> 38 >>>>> 749817917683416%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl >>>>> Yi >>>>> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 >>>>> C0 >>>>> %7C%7C%7C&sdata=WdZ7WbxxiVTmXe%2FI2OeOacrmRWORjUU2alcgK4Mbflc%3D&r >>>>> es >>>>> erved=0 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
