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
