Hi Prasad, Assuming there are no additional questions raised, it will be announced in the next day or so.
Thanks, RFC Editor/sg > On Jun 25, 2025, at 8:43 AM, Vengada Prasad Govindan (venggovi) > <vengg...@cisco.com> wrote: > > Hello Sandy, > Thank you for the prompt response, can you please let me know a tentative > date for the publication? The reason I ask is because I have a bis draft that > needs to cite RFC(to be)9798 > Thanks > Prasad > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > Sent: Wednesday, June 25, 2025 9:11 PM > To: Vengada Prasad Govindan (venggovi) <vengg...@cisco.com> > Cc: Stig Venaas (svenaas) <sven...@cisco.com>; RFC Editor > <rfc-edi...@rfc-editor.org>; 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 Prasad, > > Thank you for your review. We have noted your approval on the AUTH48 page > and will continue with publication shortly. > > Thank you, > RFC Editor/sg > > > On Jun 22, 2025, at 8:56 AM, Vengada Prasad Govindan (venggovi) > > <vengg...@cisco.com> wrote: > > > > Hello Sandy, > > I have gone through this, the changes look good. Kindly proceed with the > > publication > > Thanks > > Prasad > > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > > Sent: Tuesday, June 17, 2025 3:45 AM > > To: Stig Venaas (svenaas) <sven...@cisco.com> > > Cc: Vengada Prasad Govindan (venggovi) <vengg...@cisco.com>; RFC Editor > > <rfc-edi...@rfc-editor.org>; 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 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
