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
