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
