[auth48] Re: AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for your review

["Hooman Bidgoli (Nokia)" <[e-mail]>]

Hi Stig

I am ok with your suggestions.

With regards to the security note, I think you are right as the old PIM SSM RFC spells out that SSM does not introduce new security considerations for IP multicast.

Thanks
Hooman


-----Original Message-----
From: Stig Venaas (svenaas) <[e-mail]>
Sent: Tuesday, February 11, 2025 7:16 PM
To: Hooman Bidgoli (Nokia) <[e-mail]>; [e-mail]; [e-mail]; Mankamana Mishra (mankamis) <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; Gunter van de Velde (Nokia) <[e-mail]>; [e-mail]
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.



Hi RFC Editor and Hooman

Please see my comments inline.

> -----Original Message-----
> From: Hooman Bidgoli (Nokia) <[e-mail]>
> Sent: Tuesday, February 11, 2025 3:10 PM
> To: [e-mail]; [e-mail]; Mankamana Mishra
> (mankamis) <[e-mail]>; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> Gunter van de Velde (Nokia) <[e-mail]>;
> 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: [e-mail] <[e-mail]>
> Sent: Monday, February 10, 2025 11:45 PM
> To: Hooman Bidgoli (Nokia) <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Gunter van de Velde (Nokia)
> <[e-mail]>; [e-mail]
> 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 ALL-PIM-ROUTERS"
> HB> 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://www/
> .rfc-%2F&data=05%7C02%7Chooman.bidgoli%40nokia.com%7C8ef05603108d4cb02
> 19308dd4afa6ed2%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638749162
> 122677027%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu
> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&
> sdata=Ro3%2Fvaz4wAG3kyB3i1%2FjaIzM%2FlVrx%2FjDo8m4IA1J%2FcY%3D&reserve
> d=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, [e-mail] 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
>
>   *  [e-mail] (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).
>
>   *  [e-mail], 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,
>        [e-mail] 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