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
