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
