Hi Mike and Hooman, Thanks for the replies. I 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 5:44 PM, Hooman Bidgoli (Nokia) > <hooman.bidg...@nokia.com> wrote: > > Hi Rebecca > > My appreciate your help and edits! > > I am good with the document, approved. > > Regards > Hooman > > > -----Original Message----- > From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> > Sent: Wednesday, February 12, 2025 4:28 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; Gunter van de Velde (Nokia) > <gunter.van_de_ve...@nokia.com>; pim-...@ietf.org > Cc: RFC Editor <rfc-edi...@rfc-editor.org>; pim-cha...@ietf.org; > zhang.zh...@zte.com.cn; auth48archive@rfc-editor.org > Subject: [AD] 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, 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 talks >>>> HB> 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 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%7C20eb5efdb6c34 >>>> 817955f08dd4b931f11%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638 >>>> 749817917683416%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi >>>> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0 >>>> %7C%7C%7C&sdata=WdZ7WbxxiVTmXe%2FI2OeOacrmRWORjUU2alcgK4Mbflc%3D&res >>>> 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
