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
