Hi Rebecca, Please mark my approval as well.
thank you! mike On Wed, Feb 12, 2025 at 5:35 PM Rebecca VanRheenen < rvanrhee...@staff.rfc-editor.org> wrote: > 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 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
