Hi Stig, No worries at all! Thank you for your review - we have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9798>. We will wait to hear from Prasad as well before continuing on.
Thank you, RFC Editor/sg > On Jun 16, 2025, at 2:54 PM, Stig Venaas (svenaas) <sven...@cisco.com> wrote: > > Hi Sandy > > I'm sorry, I should have tried to reload last time. > > Changes look good, I approve, I think it is ready for publication. > > Thanks, > Stig > >> -----Original Message----- >> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> >> Sent: Monday, June 16, 2025 2:50 PM >> To: Stig Venaas (svenaas) <sven...@cisco.com> >> Cc: Vengada Prasad Govindan (venggovi) >> <venggovi=40cisco....@dmarc.ietf.org>; RFC Editor <rfc-editor@rfc- >> editor.org>; pim-...@ietf.org; pim-cha...@ietf.org; mmcbri...@gmail.com; >> gunter.van_de_ve...@nokia.com; auth48archive@rfc-editor.org >> Subject: Re: AUTH48: RFC-to-be 9798 <draft-ietf-pim-jp-extensions-lisp-09> >> for your review >> Importance: High >> >> Hi Stig, >> >> Thanks for letting me know. I reposted the files again - note that you may >> need to refresh to view the most current file. >> >> https://www.rfc-editor.org/authors/rfc9798.xml >> https://www.rfc-editor.org/authors/rfc9798.txt >> https://www.rfc-editor.org/authors/rfc9798.pdf >> https://www.rfc-editor.org/authors/rfc9798.html >> >> Diffs highlighting the most recent updates only: >> https://www.rfc-editor.org/authors/rfc9798-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9798-lastrfcdiff.html (side by side) >> >> AUTH48 diffs: >> https://www.rfc-editor.org/authors/rfc9798-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9798-auth48rfcdiff.html (side by >> side) >> >> Comprehensive diffs: >> https://www.rfc-editor.org/authors/rfc9798-diff.html >> https://www.rfc-editor.org/authors/rfc9798-rfcdiff.html (side by side) >> >> Please review and let us know if any updates are needed or if you approve the >> RFC for publication. >> >> Thank you, >> RFC Editor/sg >> >> >> >>> On Jun 16, 2025, at 2:11 PM, Stig Venaas (svenaas) <sven...@cisco.com> >> wrote: >>> >>> Hi Sandy >>> >>> Looking at the diff file and also the complete txt file, I don't see any >>> changes >> here. >>> >>> Stig >>> >>>> -----Original Message----- >>>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> >>>> Sent: Monday, June 16, 2025 11:28 AM >>>> To: Vengada Prasad Govindan (venggovi) >>>> <venggovi=40cisco....@dmarc.ietf.org> >>>> Cc: Stig Venaas (svenaas) <sven...@cisco.com>; RFC Editor >>>> <rfc-editor@rfc- editor.org>; pim-...@ietf.org; pim-cha...@ietf.org; >>>> mmcbri...@gmail.com; gunter.van_de_ve...@nokia.com; >>>> auth48archive@rfc-editor.org >>>> Subject: Re: AUTH48: RFC-to-be 9798 >>>> <draft-ietf-pim-jp-extensions-lisp-09> >>>> for your review >>>> Importance: High >>>> >>>> Hi Prasad and Stig, >>>> >>>> We have updated the document as described and posted the files here: >>>> https://www.rfc-editor.org/authors/rfc9798.xml >>>> https://www.rfc-editor.org/authors/rfc9798.txt >>>> https://www.rfc-editor.org/authors/rfc9798.pdf >>>> https://www.rfc-editor.org/authors/rfc9798.html >>>> >>>> Diffs highlighting the most recent updates only: >>>> https://www.rfc-editor.org/authors/rfc9798-lastdiff.html >>>> https://www.rfc-editor.org/authors/rfc9798-lastrfcdiff.html (side >>>> by side) >>>> >>>> AUTH48 diffs: >>>> https://www.rfc-editor.org/authors/rfc9798-auth48diff.html >>>> https://www.rfc-editor.org/authors/rfc9798-auth48rfcdiff.html (side >>>> by >>>> side) >>>> >>>> Comprehensive diffs: >>>> https://www.rfc-editor.org/authors/rfc9798-diff.html >>>> https://www.rfc-editor.org/authors/rfc9798-rfcdiff.html (side by >>>> side) >>>> >>>> >>>> Please review and let us know if updates are needed or if you approve >>>> the RFC for publication. >>>> >>>> Thank you, >>>> RFC Editor/sg >>>> >>>> >>>>> On Jun 16, 2025, at 11:02 AM, Vengada Prasad Govindan (venggovi) >>>> <venggovi=40cisco....@dmarc.ietf.org> wrote: >>>>> >>>>> Hello Sandy, Stig, >>>>> Two replies inline with GVP1> >>>>> Thanks >>>>> Prasad >>>>> >>>>> >>>>> From: Stig Venaas (svenaas) <sven...@cisco.com> >>>>> Sent: Monday, June 16, 2025 10:16 PM >>>>> To: Sandy Ginoza <sgin...@staff.rfc-editor.org> >>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Vengada Prasad Govindan >>>>> (venggovi) <vengg...@cisco.com>; pim-...@ietf.org >>>>> <pim-...@ietf.org>; pim-cha...@ietf.org <pim-cha...@ietf.org>; >>>>> mmcbri...@gmail.com <mmcbri...@gmail.com>; >>>>> gunter.van_de_ve...@nokia.com <gunter.van_de_ve...@nokia.com>; >>>>> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> >>>>> Subject: RE: AUTH48: RFC-to-be 9798 >>>>> <draft-ietf-pim-jp-extensions-lisp-09> for your review >>>>> >>>>> Hi Sandy and Prasad >>>>> >>>>> Thanks for a lot of good improvements Sandy. A few more changes are >>>> needed. >>>>> >>>>> First sentence of 3.1: >>>>> "No changes are proposed to the syntax" >>>>> >>>>> It is fine to say "proposed" in an internet draft, but now that this >>>>> is an RFC I think it should just say "There are no changes to the syntax". >>>> Other suggestions? >>>>> GVP1> Agree, this makes sense. >>>>> >>>>> Can you please use "s...@cisco.com" as my email address? This is >>>>> what I'm >>>> using in other RFCs. >>>>> >>>>> Prasad, shouldn't your affiliation and contact details be updated as >>>>> well? At >>>> least it should say "Cisco Systems, Inc." for both of us. >>>>> GVP1> Agree, Please use the same affiliation for both >>>>> Thanks, >>>>> Stig >>>>> >>>>>> -----Original Message----- >>>>>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> >>>>>> Sent: Friday, June 13, 2025 5:08 PM >>>>>> To: Stig Venaas (svenaas) <sven...@cisco.com> >>>>>> Cc: Stig Venaas (svenaas) <sven...@cisco.com>; RFC Editor >>>>>> <rfc-editor@rfc- editor.org>; Vengada Prasad Govindan (venggovi) >>>>>> <vengg...@cisco.com>; pim-...@ietf.org; pim-cha...@ietf.org; >>>>>> mmcbri...@gmail.com; gunter.van_de_ve...@nokia.com; >>>>>> auth48archive@rfc-editor.org >>>>>> Subject: Re: AUTH48: RFC-to-be 9798 >>>>>> <draft-ietf-pim-jp-extensions-lisp-09> >>>>>> for your review >>>>>> Importance: High >>>>>> >>>>>> Hi Stig, >>>>>> >>>>>> I apologize for my delayed reply. The document has been updated as >>>>>> noted below. Regarding item 3, we have updated the in-text >>>>>> citation to refer to RFC 6831, instead of RFC 9300. >>>>>> >>>>>> >>>>>>> The terms EID and RLOC are (and should be) are the same in 6831 >>>>>>> and 9300, >>>>>> but 6831 has more details explaining what the terms mean in >>>>>> multicast context. I think it is helpful to the reader of this >>>>>> document to use the definitions in 6831 as this also applies to how >>>>>> this document uses them in the same context. >>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> This document uses terminology defined in [RFC9300], such as >>>>>>>> EID, RLOC, ITR, and ETR. >>>>>> >>>>>> >>>>>> Current: >>>>>> This document uses terminology defined in [RFC6831], such as EID, >>>>>> RLOC, ITR and ETR. >>>>>> >>>>>> >>>>>> The most current files are available here: >>>>>> https://www.rfc-editor.org/authors/rfc9798.xml >>>>>> https://www.rfc-editor.org/authors/rfc9798.txt >>>>>> https://www.rfc-editor.org/authors/rfc9798.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9798.html >>>>>> >>>>>> Diffs highlighting the most recent updates only: >>>>>> https://www.rfc-editor.org/authors/rfc9798-lastdiff.html >>>>>> https://www.rfc-editor.org/authors/rfc9798-lastrfcdiff.html (side >>>>>> by side) >>>>>> >>>>>> AUTH48 diffs: >>>>>> https://www.rfc-editor.org/authors/rfc9798-auth48diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9798-auth48rfcdiff.html >>>>>> (side by >>>>>> side) >>>>>> >>>>>> Comprehensive diffs: >>>>>> https://www.rfc-editor.org/authors/rfc9798-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9798-rfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> >>>>>> Please review and let us know if any additional updates are needed >>>>>> or if you approve the RFC for publication. >>>>>> >>>>>> Thank you, >>>>>> RFC Editor/sg >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 4, 2025, at 1:43 PM, Stig Venaas (svenaas) >>>>>>> <sven...@cisco.com> >>>>>> wrote: >>>>>>> >>>>>>> Hi Sandy >>>>>>> >>>>>>> Please see inline >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> >>>>>>>> Sent: Monday, June 2, 2025 1:56 PM >>>>>>>> To: Stig Venaas (svenaas) <svenaas=40cisco....@dmarc.ietf.org> >>>>>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Vengada Prasad >>>>>>>> Govindan >>>>>>>> (venggovi) <vengg...@cisco.com>; pim-...@ietf.org; >>>>>>>> pim-cha...@ietf.org; mmcbri...@gmail.com; >>>>>>>> gunter.van_de_ve...@nokia.com; auth48archive@rfc-editor.org >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9798 >>>>>>>> <draft-ietf-pim-jp-extensions-lisp-09> >>>>>>>> for your review >>>>>>>> Importance: High >>>>>>>> >>>>>>>> Hi Stig and Prasad, >>>>>>>> >>>>>>>> Thank you for your replies. We have updated the document as >>>>>>>> discussed thus far, but we have a few followup questions noted below. >>>>>>>> >>>>>>>> The current files are available here; >>>>>>>> https://www.rfc-editor.org/authors/rfc9798.xml >>>>>>>> https://www.rfc-editor.org/authors/rfc9798.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9798.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9798.html >>>>>>>> >>>>>>>> AUTH48 diffs: >>>>>>>> https://www.rfc-editor.org/authors/rfc9798-auth48diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9798-auth48rfcdiff.html >>>>>>>> (side by sid)e >>>>>>>> >>>>>>>> Comprehensive diffs: >>>>>>>> https://www.rfc-editor.org/authors/rfc9798-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9798-rfcdiff.html (side by >>>>>>>> side) >>>>>>>> >>>>>>>> >>>>>>>> In addition to reviewing the updated files, please address the >> following. >>>>>>>> >>>>>>>> >>>>>>>> 1) Regarding keywords, RFCs 8059 and 6831 do not specify >>>>>>>> keywords, so we have not added any. >>>>>>>> >>>>>>> >>>>>>> That is fine. >>>>>>> >>>>>>>> 2) We have updated the following sentence in the Abstract for >>>>>>>> clarity. Please let us know if any updates are needed. >>>>>>>> >>>>>>>> Original: >>>>>>>> This document specifies an update to the PIM Receiver RLOC >>>> Join/Prune >>>>>>>> attribute that supports the construction of multicast >>>>>>>> distribution trees … >>>>>>>> >>>>>>>> Current: >>>>>>>> This document specifies an update to the Receiver RLOC field >>>>>>>> (Routing >>>>>>>> Locator) of the PIM Join/Prune attribute that supports the >>>>>>>> construction of multicast distribution trees … >>>>>>> >>>>>>> This is good, thanks. >>>>>>> >>>>>>>> 3) We recommend pointing to either RFC 6831 or 9300 to define EID >>>>>>>> and RLOC, or clarifying what each of the documents is providing >>>>>>>> (for example, does one provide additional information?). Please >>>>>>>> review and let us know if we may update the text to more >>>>>>>> definitively indicate where EID and RLOC are defined. >>>>>>>> >>>>>>>> Original (both from the Introduction): >>>>>>>> Please refer to Section 3 of [RFC6831] for the definition of >>>>>>>> the terms EID and RLOC. >>>>>>> >>>>>>> The terms EID and RLOC are (and should be) are the same in 6831 >>>>>>> and 9300, >>>>>> but 6831 has more details explaining what the terms mean in >>>>>> multicast context. I think it is helpful to the reader of this >>>>>> document to use the definitions in 6831 as this also applies to how >>>>>> this document uses them in the same context. >>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> This document uses terminology defined in [RFC9300], such as >>>>>>>> EID, RLOC, ITR, and ETR. >>>>>>>> >>>>>>>> >>>>>>>> 4) This comment appears in the XML — note that we intend to >>>>>>>> remove this comment. >>>>>>>> >>>>>>>> <!-- >>>>>>>> %<t>The root ITR MUST also discard all affected Join/Prune >>>>>>>> sources if the Transport Attribute value is set to any value >>>>>>>> other than zero and the Address field of the Receiver RLOC >>>>>>>> contains a multicast IP address. </t> --> >>>>>>> >>>>>>> Yes, please do. >>>>>>> >>>>>>> Thanks, >>>>>>> Stig >>>>>>> >>>>>>>> >>>>>>>> Thank you, >>>>>>>> RFC Editor/sg >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On May 29, 2025, at 9:00 AM, Stig Venaas (svenaas) >>>>>>>> <svenaas=40cisco....@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>> Dear RFC Editor >>>>>>>>> >>>>>>>>> I'm fine with the comments from my co-author. >>>>>>>>> >>>>>>>>> One comment inline for point 7 below. >>>>>>>>> >>>>>>>>> I reviewed the changes, and they look good, but I see we don't >>>>>>>>> have full >>>>>>>> contact details for the authors. >>>>>>>>> >>>>>>>>> The correct details for me are: >>>>>>>>> >>>>>>>>> Stig Venaas >>>>>>>>> Cisco Systems, Inc. >>>>>>>>> Tasman Drive >>>>>>>>> San Jose CA 95134 >>>>>>>>> United States of America >>>>>>>>> >>>>>>>>> Email: s...@cisco.com >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Stig >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>>>>>>> Sent: Tuesday, May 27, 2025 3:42 PM >>>>>>>>>> To: Vengada Prasad Govindan (venggovi) <vengg...@cisco.com>; >>>>>>>>>> Stig >>>>>>>> Venaas >>>>>>>>>> (svenaas) <sven...@cisco.com> >>>>>>>>>> Cc: rfc-edi...@rfc-editor.org; pim-...@ietf.org; >>>>>>>>>> pim-cha...@ietf.org; mmcbri...@gmail.com; >>>>>>>>>> gunter.van_de_ve...@nokia.com; auth48archive@rfc-editor.org >>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9798 >>>>>>>>>> <draft-ietf-pim-jp-extensions-lisp- >>>>>>>> 09> >>>>>>>>>> for your review >>>>>>>>>> Importance: High >>>>>>>>>> >>>>>>>>>> Authors, >>>>>>>>>> >>>>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>> necessary) >>>>>>>>>> the following questions, which are also in the XML file. >>>>>>>>>> >>>>>>>>>> 1) <!-- [rfced] Because this document updates RFC 8059, please >>>>>>>>>> review the errata reported for RFC 8059 (https://www.rfc- >>>>>>>>>> editor.org/errata_search.php?rfc=8059). We do not believe any >>>>>>>>>> are >>>>>>>> applicable >>>>>>>>>> to this document, but we would appreciate confirmation that >>>>>>>>>> this is >>>>>>>> correct. >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that >>>>>>>>>> appear in the >>>>>>>>>> title) for use on https://www.rfc-editor.org/search. --> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3) <!-- [rfced] [RFC6831] appears to use the terms "(S-EID,G)" >>>>>>>>>> and >>>>>>>>>> "(S- RLOC,G)" rather than "(root-EID, G)" and "(root-RLOC, G)". >>>>>>>>>> This is clarified later in the paragraph, but perhaps the >>>>>>>>>> sentences should be closer together and the original term >>>>>>>>>> defined in RFC 6831 >>>>>> should be noted first. >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> [RFC6831] specifies that (root-EID, G) data packets are to be >>>>>>>>>> LISP- encapsulated into (root-RLOC, G) multicast packets. ... >>>>>>>>>> We use the term root-EID or root-RLOC to refer to the source >>>>>>>>>> of the multicast tree rooted at the EID or RLOC. >>>>>>>>>> >>>>>>>>>> Perhaps: >>>>>>>>>> [RFC6831] specifies that (EID, G) data packets are to be LISP- >>>>>>>>>> encapsulated into (RLOC, G) multicast packets. In this >>>>>>>>>> document, we use the term root-EID or root-RLOC to refer to the >>>>>>>>>> source of the multicast tree rooted at the EID or RLOC. ... >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 4) <!-- [rfced] Seemingly, the text points readers to RFCs 6831 >>>>>>>>>> and >>>>>>>>>> 9300 for definitions of EID and RLOC. Please review. >>>>>>>>>> >>>>>>>>>> Original (both from the Introduction): >>>>>>>>>> Please refer to Section 3 of [RFC6831] for the definition of >>>>>>>>>> the terms EID and RLOC. >>>>>>>>>> >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> This document uses terminology defined in [RFC9300], such as >>>>>>>>>> EID, RLOC, ITR, and ETR. >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 5) <!-- [rfced] Is (PxTR) the same as the site border node? >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> Inter-site Proxy Tunnel Routers (PxTR): >>>>>>>>>> When multiple LISP sites are interconnected through a LISP-based >>>>>>>>>> transit, the site border node (PxTR) connects the site-facing >>>>>>>>>> interfaces with the external LISP core. >>>>>>>>>> >>>>>>>>>> Perhaps: >>>>>>>>>> Inter-site Proxy Tunnel Routers (PxTR): >>>>>>>>>> When multiple LISP sites are interconnected through a LISP-based >>>>>>>>>> transit, the site border node (i.e., PxTR) connects the site-facing >>>>>>>>>> interfaces with the external LISP core. >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 6) <!-- [rfced] For clarity, we suggest including a section >>>>>>>>>> number (at >>>>>>>>>> minimum) and/or the text being replaced. For example: >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> The definition of the "Receiver RLOC" field of the Receiver ETR >>>>>>>>>> RLOC attribute RFC 8059 [RFC8059] is updated as follows: >>>>>>>>>> >>>>>>>>>> Receiver RLOC: >>>>>>>>>> The RLOC address on which the receiver ETR wishes to receive >>>>>>>>>> the encapsulated flow. A unicast IP Receiver RLOC address is >>>>>>>>>> used for unicast-encapsulated flows. Alternately, a multicast >>>>>>>>>> IP Receiver RLOC address is used for for >>>>>>>>>> multicast-encapsulated flows. A multicast IP address MUST be >>>>>>>>>> used only when the underlay network >>>> of >>>>>>>>>> the LISP core supports IP Multicast transport. >>>>>>>>>> >>>>>>>>>> Suggested: >>>>>>>>>> The definition of the "Receiver RLOC" field of the Receiver ETR >>>>>>>>>> RLOC attribute (see Section 5.1 of [RFC8059]) is updated as >>>> follows: >>>>>>>>>> >>>>>>>>>> OLD: >>>>>>>>>> Receiver RLOC: The RLOC address on which the receiver ETR wishes >>>> to >>>>>>>>>> receiver the unicast-encapsulated flow. >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> Receiver RLOC: >>>>>>>>>> The RLOC address on which the receiver ETR wishes to receive >>>>>>>>>> the encapsulated flow. A unicast IP Receiver RLOC address is >>>>>>>>>> used for unicast-encapsulated flows. Alternately, a multicast >>>>>>>>>> IP Receiver RLOC address is used for multicast-encapsulated >>>>>>>>>> flows. A multicast IP address MUST be used only when the >>>>>>>>>> underlay network >>>> of >>>>>>>>>> the LISP core supports IP Multicast transport. >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 7) <!-- [rfced] [RFC6831] uses the term "outgoing interface list" >>>>>>>>>> and "OIF- >>>>>>>> list"; >>>>>>>>>> we do not see use of the term "OutgoingInterfaceList". >>>>>>>>>> Please review. >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> * It allocates a new entry in the OutgoingInterfaceList RFC 6831 >>>>>>>>>> [RFC6831] for every unique underlay multicast mapping. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> It would be good to replace this with "outgoing interface list" >>>>>>>>> as in >>>> 6831. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 8) <!-- [rfced] Throughout the text, the following terminology >>>>>>>>>> appears to be used inconsistently. Please review these >>>>>>>>>> occurrences and let us know >>>>>>>> if/how >>>>>>>>>> they may be made consistent. >>>>>>>>>> >>>>>>>>>> Multicast vs multicast >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note that we expanded the following abbreviations. Please let >>>>>>>>>> us know if >>>>>>>> any >>>>>>>>>> updates are required. >>>>>>>>>> >>>>>>>>>> Routing Locator (RLOC) >>>>>>>>>> Tunnel Router (xTR) >>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 9) <!-- [rfced] Please review the "Inclusive Language" portion >>>>>>>>>> of the online Style Guide <https://www.rfc- >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On May 27, 2025, at 3:37 PM, rfc-edi...@rfc-editor.org wrote: >>>>>>>>>> >>>>>>>>>> *****IMPORTANT***** >>>>>>>>>> >>>>>>>>>> Updated 2025/05/27 >>>>>>>>>> >>>>>>>>>> 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/rfc9798.xml >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9798.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9798.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9798.txt >>>>>>>>>> >>>>>>>>>> Diff file of the text: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9798-diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9798-rfcdiff.html (side >>>>>>>>>> by >>>>>>>>>> side) >>>>>>>>>> >>>>>>>>>> Diff of the XML: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9798-xmldiff1.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tracking progress >>>>>>>>>> ----------------- >>>>>>>>>> >>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9798 >>>>>>>>>> >>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>> >>>>>>>>>> Thank you for your cooperation, >>>>>>>>>> >>>>>>>>>> RFC Editor >>>>>>>>>> >>>>>>>>>> -------------------------------------- >>>>>>>>>> RFC 9798 (draft-ietf-pim-jp-extensions-lisp-09) >>>>>>>>>> >>>>>>>>>> Title : PIM Join/Prune Attributes for LISP Environments >>>>>>>>>> using >>>>>> Underlay >>>>>>>>>> Multicast >>>>>>>>>> Author(s) : V. Govindan, S. Venaas >>>>>>>>>> WG Chair(s) : Stig Venaas, Mike McBride >>>>>>>>>> >>>>>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van >>>>>>>>>> de Velde >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
