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
