Hi Megan, Thanks a lot for your work.
I added inline my comments to the points I missed. Ciao L. > -----Original Message----- > From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > Sent: Monday, 3 February 2025 22:02 > To: Luigi IANNONE <luigi.iann...@huawei.com>; farina...@gmail.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 > > 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. > [LI] You can leave the text as it 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. [LI] No 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. [LI] I actually checked the UTF-8 specifications and "whitespace" is the term used. I fear that changing the term would create an incoherence. Hence I think would be better to leave it as it is. > > > 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. [LI] Not sure I get the comment. The abstract looks OK to me. What exactly should be added? > > 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
