Thanks Megan. All looks good to me. You have my approval. Dino
> On Feb 3, 2025, at 1:01 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > Hi Luigi and Dino, > > Thanks for your replies. We have made updates accordingly. Please see the > links to the updated files below. > > Additionally, we could use further guidance and/or a response regarding the > following from our initial set of queries (listed below with our comments in > [rfced]) so we can close out the list: > >> 10) <!--[rfced] We had a few questions regarding this text: >> >> Original: >> In a practical implementation of >> [I-D.ietf-lisp-site-external-connectivity] on LISP deployments, routers >> running as Proxy Egress Tunnel Routers (Proxy-ETRs) register their role with >> the Mapping System in order to attract traffic destined for external >> networks. >> >> a) Is there an update we can make to describe which part/concept of the >> cited document is being practically implemented (e.g., the registration >> procedures, requirements, etc.). > [rfced] We don’t believe we saw a response to (a). Please let us know if > you’d like to update or leave the text as is. > > >> a) Please review the way that the AFI value is referred to throughout the >> text (e.g., using an equals sign, spacing around the equals sign, etc.). We >> see: >> >> Address Family Identifier (AFI) 17 "Distinguished Names" >> AFI 17 "Distinguished Name" >> the AFI value 17 >> An AFI=17 Distinguished Name >> an AFI=17 encoded string >> AFI 17 >> > [LI] We can make everything uniform to: AFI 17 Distinguished Name > > [rfced] We actually did this slightly differently based on your response > regarding the abbreviation DN. When AFI 17 was mentioned and it seemed like > we were talking about the IANA-registered name, we used the quotes and > spelled out Distinguished Name. Other instances (without AFI 17) that seemed > like the general concept were made DN after we introduced the abbreviation. > Please review and let us know any objections. > >> 15) <!-- [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. >> >> For example, please consider whether the following should be updated: >> >> whitespace > [rfced] We didn’t see a response regarding the use of “whitespace”. Please > let us know any updates you’d like to make. > >> d) We see variations in the following forms. Should these be made >> consistent? >> >> Mapping System vs. mapping system >> EID-Record vs. EID record >> RLOC-record vs. RLOC record >> > [LI] Yes thanks. They should be: > > Mapping System > EID-Record > RLOC-Record > > [rfced] Please review our update to move a sentence from the Introduction to > the Abstract in order to keep the expansions of EID and RLOC while > maintaining consistent RLOC-Record and EID-Record use. > > Please review the files carefully for the incorporation of the other updates > you sent along as we do not make changes after publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9735.txt > https://www.rfc-editor.org/authors/rfc9735.pdf > https://www.rfc-editor.org/authors/rfc9735.html > https://www.rfc-editor.org/authors/rfc9735.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9735-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9735-auth48diff.html (AUTH48 changes > only) > > Please contact us with any further updates/questions/comments you may have. > > We will await replies to the above followups and approvals from each of the > parties listed on the AUTH48 status page prior to moving forward to > publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9735 > > Thank you. > > RFC Editor/mf > > > >> On Feb 3, 2025, at 2:19 AM, Luigi IANNONE >> <luigi.iannone=40huawei....@dmarc.ietf.org> wrote: >> >> Hi >> >> Thanks for reviewing the document. >> >> I have a few comments inline marked with "[LI]". >> >> >> L. >> >>> -----Original Message----- >>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>> Sent: Saturday, 1 February 2025 01:34 >>> To: farina...@gmail.com; Luigi IANNONE <luigi.iann...@huawei.com> >>> Cc: rfc-edi...@rfc-editor.org; lisp-...@ietf.org; lisp-cha...@ietf.org; >>> na...@cisco.com; james.n.guich...@futurewei.com; auth48archive@rfc- >>> editor.org >>> Subject: Re: AUTH48: RFC-to-be 9735 <draft-ietf-lisp-name-encoding-17> for >>> your review >>> >>> Authors, >>> >>> While reviewing this document during AUTH48, please resolve (as necessary) >>> the following questions, which are also in the XML file. >>> >>> 1) <!-- [rfced] Please note that the title of the document has been >>> updated as follows: >>> >>> a) Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style >>> Guide"). Please review. >>> >>> Original: >>> LISP Distinguished Name Encoding >>> >>> Current: >>> Locator/ID Separation Protocol (LISP) Distinguished Name Encoding >>> >>> b) Please note that we have added an abbreviated title that appears in the >>> running header of the pdf version. Please review and let us know if any >>> updates are necessary. >>> >>> Original: >>> [nothing] >>> >>> Current: >>> LISP Name Encoding >>> --> >> [LI] OK. Thanks. >> >> >>> >>> >>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the >>> title) for use on https://www.rfc-editor.org/search. --> >>> >>> >>> 3) <!--[rfced] Neither RFC 9300 nor RFC 9301 have "architecture" in their >>> title. Are these document "nicknames" or concepts? Please >>> review this citation and sentence and let us know if any updates >>> are needed. >>> >>> Original: >>> The LISP architecture and protocols ([RFC9300], [RFC9301]) introduces two >>> new numbering spaces,... >>> --> >>> >> [LI] May be just simplify to "LISP ([RFC9300], [RFC9301]) introduces....." >> >>> >>> 4) <!--[rfced] Is RFC 5280 to be read as one of a group of RFCs? Or is >>> this the only RFC the reader is being pointed to? >>> >>> Original: >>> The Distinguished Name field in this document has no relationship to the >>> similarly named field in the Public-Key Infrastructure using >>> X.509 (PKIX) specifications [RFC5280]. >>> >>> Perhaps: >>> The Distinguished Name field in this document has no relationship to the >>> similarly named field in the Public-Key Infrastructure using >>> X.509 (PKIX) specifications (e.g., [RFC5280]). >> >> [LI] This change is OK. >> [LI] >> >> >>> --> >>> >>> >>> 5) <!--[rfced] Please review uses of NULL in this document. >>> Particularly: >>> >>> a) Should these be updated to NUL? Please let us know any changes in >>> Old/New format or feel free to update the edited XML as desired. >>> >> [LI] Keep "NULL" >> >> >>> b) We see the following similar uses. Should these be made uniform? >>> >>> NULL Terminated vs. >>> NULL (0x00) terminated vs. >>> terminating NULL 0x00 octet vs. >>> NULL 0 octet vs. >>> NULL terminated vs. >>> NULL octet vs. >>> null octet >> [LI] Uniform to: >> NULL-terminated (0x00) >> NULL octet (0x00) >> >>> >>> c) Further, we would expect NULL Terminated to be hyphenated in >>> attributive position (before a noun). Please see how (0x00) can fit into >>> that >>> scheme. >>> --> >> [LI] See above >> >>> >>> >>> 6) <!--[rfced] We had a few questions about the following text: >>> >>> Original: >>> When Distinguished Names are encoded for EIDs, the EID Mask-Len length of >>> the EIDs as they appear in EID-Records for all LISP control messages >>> [RFC9301] is the length of the string in bits (including the terminating >>> NULL >>> 0x00 octet). >>> >>> a) Might it be helpful to move this citation to RFC 9301 to a >>> previous/first use >>> of LISP control messages (perhaps in the Introduction)? Or is this citation >>> covering another/more parts of the sentence here? >> [LI] I would keep it here as it applies for any use of Distinguished Names >> as EIDs. >>> >>> b) Is it redundant to say "the EID Mask-Len length of the EIDs"? >>> >>> --> >> [LI] Yes, may be simplify to " the EID Mask-Len length of the EID-Records, >> for all LISP control messages,...." >> >>> >>> >>> 7) <!--[rfced] We are having trouble parsing this sentence. What MUST the >>> lookups carry? >>> >>> Original: >>> Distinguished Name EID lookups MUST carry as an EID Mask-Len length >>> equal to the length of the name string. >>> --> >> [LI] Rephrase the first sentence as: >> >> When performing Distinguished Name EID lookups, Map-Request messages >> MUST carry an EID Mask-Len length equal to the length of the name string >> in bits. >> >>> >>> >>> 8) <!--[rfced] In the following, please clarify the parenthetical. What >>> is 5 octets? The null octet itself or the null octet plus >>> "ietf"? >>> >>> Original: >>> For example, if the registered EID name is "ietf" with EID Mask-Len of 40 >>> bits >>> (the length of string "ietf" plus the null octet is 5 octets), and a >>> Map-Request >>> is received for EID name "ietf.lisp" with an EID Mask-Len of 80 bits, the >>> Map- >>> Server will return EID "ietf" >>> with length of 40 bits. >>> >>> --> >> [LI] 5 octets is "ietf"+0x00, may be writing "> (the length of string >> "ietf" plus the length of the NULL octet makes 5 octets), " >> >> >>> >>> >>> 9) <!--[rfced] To what does "LISP Distinguished Name specification" >>> refer? Is a citation necessary here? >>> >>> Original: >>> Practical implementations of the LISP Distinguished Name specification have >>> been running in production networks for some time. >>> >>> --> >> [LI] Is the specifications in this document, may be change as "... >> implementations of the LISP Distinguished Name, defined in this document, >> have...." >> >> >>> >>> >>> 10) <!--[rfced] We had a few questions regarding this text: >>> >>> Original: >>> In a practical implementation of >>> [I-D.ietf-lisp-site-external-connectivity] on LISP deployments, routers >>> running as Proxy Egress Tunnel Routers (Proxy-ETRs) register their role with >>> the Mapping System in order to attract traffic destined for external >>> networks. >>> >>> a) Is there an update we can make to describe which part/concept of the >>> cited document is being practically implemented (e.g., the registration >>> procedures, requirements, etc.). >>> >>> b) We note some inconsistencies in the abbreviation for "Proxy Egress >>> Tunnel Routers": >>> >>> [I-D.ietf-lisp-site-external-connectivity] seems to use pETR >>> >>> This document uses Proxy-ETR >>> >>> Past RFCs have used PETR. >>> >>> Please review and let us know what, if any, updates are necessary. >> [LI] RFC 9300 is the reference, and it uses "Proxy-ETR", we should use this >> everywhere. >> >>> --> >>> >>> >>> 11) <!--[rfced] What citation should be added to this sentence to point >>> the reader to the LISP Site External Connectivity document? Is >>> this draft-ietf-lisp-site-external-connectivity? >> [LI] Yes. >>> >>> Original: >>> The Distinguished Name in this case serves as a common reference EID that >>> can be requested (or subscribed as per [RFC9437]) to dynamically gather this >>> Proxy-ETR list as specified in the LISP Site External Connectivity document. >>> --> >>> >>> >>> 12) <!--[rfced] We had a few questions about these similar sentences >>> appearing in Sections 9.3-9.5: >>> >>> a) Perhaps we can update to avoid saying a website has had experience in >>> these sentences? >>> >>> b) Should the same citation appear in each of the sentences? >>> >>> Original: >>> The open source lispers.net NAT-Traversal implementation >>> [I-D.farinacci-lisp- >>> lispers-net-nat] has had 10 years of deployment experience using >>> Distinguished Names for documenting xTRs versus Re- encapsulating Tunnel >>> Router (RTRs) as they appear in a locator-set. >>> >>> Perhaps: >>> At the time of writing, the open-source lispers.net NAT-Traversal >>> implementation [I-D.farinacci-lisp-lispers-net-nat] has deployed >>> Distinguished Names for documenting xTRs versus Re-encapsulating Tunnel >>> Routers (RTRs) as they appear in a locator-set for 10 years. >>> >>> >>> Original: >>> The open source lispers.net implementation has had 10 years of self- >>> documenting RLOC names in production and pilot environments. >>> >>> Perhaps: >>> At the time of writing, the open-source lispers.net implementation [I- >>> D.farinacci-lisp-lispers-net-nat] has self-documented RLOC names in >>> production and pilot environments. >>> >>> >>> Original: >>> The open source lispers.net implementation has had 10 years of deployment >>> experience allowing xTRs to register EIDs as Distinguished Names. >>> >>> Perhaps: >>> At the time of writing, the open-source lispers.net implementation [I- >>> D.farinacci-lisp-lispers-net-nat] has deployed xTRs that are allowed to >>> register EIDs as Distinguished Names for 10 years. >>> >>> --> >> [LI] OK for me. >> >>> >>> >>> 13) <!-- [rfced] We had the following questions related to terminology use >>> throughout the document: >>> >>> a) Please review the way that the AFI value is referred to throughout the >>> text (e.g., using an equals sign, spacing around the equals sign, etc.). We >>> see: >>> >>> Address Family Identifier (AFI) 17 "Distinguished Names" >>> AFI 17 "Distinguished Name" >>> the AFI value 17 >>> An AFI=17 Distinguished Name >>> an AFI=17 encoded string >>> AFI 17 >>> >> [LI] We can make everything uniform to: AFI 17 Distinguished Name >> >> >>> See also: AFI = 1 >> [LI] replace with "AFI equal 1" >>> >>> How may we make these consistent throughout? >>> >>> b) We see variation in the way the term Distinguished Names is referred to >>> (i.e., capitalization, pluralization, quotation, etc.). >>> In addition to the examples in a) above, please also see: >>> >>> LISP Distinguished Names >>> AFI 17 "Distinguished Name" and (AFI) 17 "Distinguished Names" (sg/pl) >>> Distinguished Name (DN) >> >> [LI] Plural should be avoided. But I do not see other issues.... >> >>> >>> Please consider if this is the name of the value or the concept in general >>> during your review and send us updates in either Old/New form or update >>> the edited XML file directly. >>> >>> c) We see that the abbreviation DN was used nearly at the end of the >>> document. Might we reduce some of the inconsistencies by moving the >>> abbreviation to first use (or the first use that is not to the direct name >>> of the >>> IANA-registered value) and then using DN thereafter? >> [LI] Sure. >> >>> >>> d) We see variations in the following forms. Should these be made >>> consistent? >>> >>> Mapping System vs. mapping system >>> EID-Record vs. EID record >>> RLOC-record vs. RLOC record >>> >> [LI] Yes thanks. They should be: >> >> Mapping System >> EID-Record >> RLOC-Record >> >> >>> --> >>> >>> >>> 14) <!-- [rfced] FYI - We have added expansions for the following >>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style >>> Guide"). Please review each expansion in the document carefully >>> to ensure correctness. >>> >>> LISP - Locator/ID Separation Protocol >>> LCAF - LISP Canonical Address Format >>> >>> --> >> [LI] Thanks. >>> >>> >>> 15) <!-- [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. >>> >>> For example, please consider whether the following should be updated: >>> >>> whitespace >>> >>> In addition, please consider whether "tradition" should be updated for >>> clarity. While the NIST website <https://www.nist.gov/nist-research- >>> library/nist-technical-series-publications-author-instructions#table1> >>> indicates that this term is potentially biased, it is also ambiguous. >>> "Tradition" is a subjective term, as it is not the same for everyone. >>> >>> Original: >>> ...to start with traditional UDP registrations. >>> --> >> [LI] The term "traditional" can be dropped. >> >>> >>> >>> Thank you. >> [LI] Thanks for the thorough review. >> >> >> >>> >>> RFC Editor/mf >>> >>> *****IMPORTANT***** >>> >>> Updated 2025/01/31 >>> >>> 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/rfc9735.xml >>> https://www.rfc-editor.org/authors/rfc9735.html >>> https://www.rfc-editor.org/authors/rfc9735.pdf >>> https://www.rfc-editor.org/authors/rfc9735.txt >>> >>> Diff file of the text: >>> https://www.rfc-editor.org/authors/rfc9735-diff.html >>> https://www.rfc-editor.org/authors/rfc9735-rfcdiff.html (side by side) >>> >>> Diff of the XML: >>> https://www.rfc-editor.org/authors/rfc9735-xmldiff1.html >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> https://www.rfc-editor.org/auth48/rfc9735 >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> -------------------------------------- >>> RFC9735 (draft-ietf-lisp-name-encoding-17) >>> >>> Title : LISP Distinguished Name Encoding >>> Author(s) : D. Farinacci, L. Iannone >>> WG Chair(s) : Joel M. Halpern, Luigi Iannone >>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde >>> >>> >> > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
