I somehow cannot find any traces of this email thread in my Outlook hence the
late response. Thanks to Gunter for forwarding me this email.
A few nits:
In certain scenarios, it is desirable to establish multicast states
between two adjacent Layer 3 routers without forming a PIM
neighborship.
We should remove the "adjacent layer 3" wording from the above. The very use
case that led to this document involves routers *indirectly* connected by a
BIER domain (which are composed of layer 3 routers) - we want to signal PIM
states among non-adjacent routers over this PLI.
For the following:
Since a PLI does not process PIM Hello messages, it also does not
support the Join Attribute option in PIM Hello as specified in
[RFC5384]. 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.
"process" is more on the receiving side. I think we're only talking about
"sending" here, so should change the second "process" to "send".
There are two cases in which a PLI can send and process a Join
Attribute:
Remove "and process"?
* The Join Attribute must be configured with an appropriate Join
Attribute type that the PLI is capable of processing as per the
"PIM Join Attribute Types" registry [IANA-PIM-Attr-Types].
The above bullet does not read well. Perhaps change it to the following?
* The neighbors on the PLI are known, by means outside of the scope
of this document, to be capable of processing the attribute.
The following:
... 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.
Could be changed to the following:
Join/Prune messages not received from a PIM neighbor MUST be
dropped unless PLI is enabled on the interface.
Other than that, I approve the changes.
Thanks.
Jeffrey
Juniper Business Use Only
-----Original Message-----
From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org>
Sent: Thursday, February 20, 2025 4:18 PM
To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; 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
Cc: pim-...@ietf.org; RFC Editor <rfc-edi...@rfc-editor.org>;
pim-cha...@ietf.org; ext-zhang.zh...@zte.com.cn <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
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 Gunter and authors,
Gunter - Thanks for the response. We have marked your approval on the AUTH48
status page for this document (see
https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9739__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGob2FS0M2$
).
All - Once Zhaohui Zhang approves the document, we can move forward in the
publication process.
Best regards,
RFC Editor/rv
> On Feb 19, 2025, at 10:03 PM, Gunter van de Velde (Nokia)
> <gunter.van_de_ve...@nokia.com> wrote:
>
> Hi,
>
> Yes, approved.
>
> My apologies for the delayed response. It got lost in a mountain of emails
> and I accidently classified it overly fast.
>
> G/
>
> -----Original Message-----
> From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org>
> Sent: Thursday, February 13, 2025 8:35 AM
> To: Mankamana Mishra (mankamis) <manka...@cisco.com>; Hooman Bidgoli
> (Nokia) <hooman.bidg...@nokia.com>; Stig Venaas (svenaas)
> <sven...@cisco.com>; s...@cisco.com; zzh...@juniper.com;
> michael.mcbr...@futurewei.com; Gunter van de Velde (Nokia)
> <gunter.van_de_ve...@nokia.com>
> Cc: pim-...@ietf.org; RFC Editor <rfc-edi...@rfc-editor.org>;
> pim-cha...@ietf.org; zhang.zh...@zte.com.cn;
> auth48archive@rfc-editor.org
> Subject: Re: [AD] AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for
> your review
>
> [You don't often get email from rvanrhee...@staff.rfc-editor.org.
> Learn why this is important at
> https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentificat
> ion__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUu
> LYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoZMRyV68$ ]
>
> 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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9739__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGob2FS0M2$
> .
>
> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739-auth48diff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGodJHBqhy$
>> .
>>
>> - 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc973
>> 9.xml__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094
>> vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoX9fU1EN$
>>
>> Updated output files:
>>
>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc973
>> 9.txt__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094
>> vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoQZE_-m0$
>>
>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc973
>> 9.pdf__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094
>> vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoQPsWOFq$
>>
>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc973
>> 9.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN09
>> 4vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoe_rSGpp$
>>
>> Diff file showing changes made during AUTH48:
>>
>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc973
>> 9-auth48diff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lB
>> kMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGodJHBqhy$
>>
>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc973
>> 9-auth48rfcdiff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb4
>> 7lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGof4pp-QQ$
>> (side by side)
>>
>> Diff files showing all changes:
>>
>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc973
>> 9-diff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNz
>> LaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoa6vP28h$
>>
>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc973
>> 9-rfcdiff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMd
>> MNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoRukIEpY$ (side by
>> side)
>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc973
>> 9-alt-diff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkM
>> dMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGocKQwNI7$ (shows
>> changes where text is moved or deleted)
>>
>> For the AUTH48 status of this document, please see:
>>
>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9739
>> __;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLY
>> UPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGob2FS0M2$
>>
>> 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://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentific
>>> ation__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN09
>>> 4vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoZMRyV68$ ]
>>>
>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97
>>> 39.xml__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN0
>>> 94vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoX9fU1EN$
>>>
>>> Updated output files:
>>>
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97
>>> 39.txt__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN0
>>> 94vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoQZE_-m0$
>>>
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97
>>> 39.pdf__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN0
>>> 94vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoQPsWOFq$
>>>
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97
>>> 39.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN
>>> 094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoe_rSGpp$
>>>
>>> Diff file showing changes made during AUTH48:
>>>
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97
>>> 39-auth48diff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47
>>> lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGodJHBqhy$
>>>
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97
>>> 39-auth48rfcdiff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDH
>>> b47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGof4pp-QQ$
>>> (side by side)
>>>
>>> Diff files showing all changes:
>>>
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97
>>> 39-diff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdM
>>> NzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoa6vP28h$
>>>
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97
>>> 39-rfcdiff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBk
>>> MdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoRukIEpY$ (side
>>> by side)
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97
>>> 39-alt-diff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lB
>>> kMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGocKQwNI7$
>>> (shows changes where text is moved or deleted)
>>>
>>> For the AUTH48 status of this document, please see:
>>>
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc973
>>> 9__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUu
>>> LYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGob2FS0M2$
>>>
>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!
>>>>> NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUP
>>>>> oCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoXt4g21m$ . -->
>>>>>
>>>>>
>>>>> 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://urldefense.com/v3/__https://eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.iana.org*2Fassignments*2Fpim-parameters*2F&data=05*7C02*7Cgunter.van_de_velde*40nokia.com*7Ce04cb0dd87754afdbba808dd51f40aa4*7C5d4717519675428d917b70f44f9630b0*7C0*7C0*7C638756831209717459*7CUnknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C0*7C*7C*7C&sdata=zJrRMvh77erna*2B*2FvEuiqwFc*2FmI8hmx8yus5AVfxnpFw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoQwYW7S0$
>>>>> .
>>>>>
>>>>> 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://urldefense.com/v3/__https://eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.iana.org*2Fassignments*2Fpim-parameters*2F&data=05*7C02*7Cgunter.van_de_velde*40nokia.com*7Ce04cb0dd87754afdbba808dd51f40aa4*7C5d4717519675428d917b70f44f9630b0*7C0*7C0*7C638756831209752667*7CUnknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C0*7C*7C*7C&sdata=Vd3nxOSp9AkXlq14*2Ff*2B48VxeIkxFVeINF6MnC95IGEU*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoSDbHT5w$
>>>>> .
>>>>>
>>>>> 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://urldefense.com/v3/__https://eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.iana.org*2Fassignments*2Fservice-names-port-numbers&data=05*7C02*7Cgunter.van_de_velde*40nokia.com*7Ce04cb0dd87754afdbba808dd51f40aa4*7C5d4717519675428d917b70f44f9630b0*7C0*7C0*7C638756831209768118*7CUnknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C0*7C*7C*7C&sdata=HdnEtAxw8FKGE8jp7n3jOnb*2F6c1bjkaNA3qlfDEu9qc*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoXd_yJVO$
>>>>> .
>>>>> 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://urldefense.com/v3/__https://w/__;!!NEt6yMaO-gk!BjYVaQwQLx
>>>>> 4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0
>>>>> nNKSIPpAKlkGoZ9iq5GD$
>>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGodBPMlIq$
>>>>> ).
>>>>>
>>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGocdQMZmG$
>>>>> ).
>>>>>
>>>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoT9HjFnF$
>>>>> >.
>>>>>
>>>>> * 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/
>>>>> ietf-announce/yb6lpIGh-__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2
>>>>> vcDHb47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoSk-
>>>>> tp2d$
>>>>> 4Q9l2USxIAe6P8O4Zc
>>>>>
>>>>> * The archive itself:
>>>>>
>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/brow
>>>>> se/auth48archive/__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb4
>>>>> 7lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoZh_WjQo$
>>>>>
>>>>> * 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
>>>>> 9739.xml__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNz
>>>>> LaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoX9fU1EN$
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
>>>>> 9739.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMN
>>>>> zLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoe_rSGpp$
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
>>>>> 9739.pdf__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNz
>>>>> LaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoQPsWOFq$
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
>>>>> 9739.txt__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNz
>>>>> LaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoQZE_-m0$
>>>>>
>>>>> Diff file of the text:
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
>>>>> 9739-diff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lB
>>>>> kMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoa6vP28h$
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
>>>>> 9739-rfcdiff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb4
>>>>> 7lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoRukIEpY$
>>>>> (side by
>>>>> side)
>>>>>
>>>>> Alt-diff of the text (allows you to more easily view changes where
>>>>> text has been deleted or moved):
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
>>>>> 9739-alt-diff.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb
>>>>> 47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGocKQwNI7$
>>>>>
>>>>> Diff of the XML:
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
>>>>> 9739-xmldiff1.html__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb
>>>>> 47lBkMdMNzLaN094vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGoePtTVts$
>>>>>
>>>>>
>>>>> Tracking progress
>>>>> -----------------
>>>>>
>>>>> The details of the AUTH48 status of your document are here:
>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9
>>>>> 739__;!!NEt6yMaO-gk!BjYVaQwQLx4ecMZmEcDP0kZ2c2vcDHb47lBkMdMNzLaN09
>>>>> 4vUuLYUPoCUDRqUEXJkxxl4hAV4mw0nNKSIPpAKlkGob2FS0M2$
>>>>>
>>>>> 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
