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
