I reviewed the diff file. All the changes look good.
One comment, you should change anchor label “LISP-NET-NAT” to
“LISPERS-NET-NAT”.
Thanks,
Dino
> On Jan 31, 2025, at 4:34 PM, rfc-edi...@rfc-editor.org wrote:
>
> 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
> -->
>
>
> 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,...
> -->
>
>
> 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]).
> -->
>
>
> 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.
>
> 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
>
> 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.
> -->
>
>
> 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?
>
> b) Is it redundant to say "the EID Mask-Len length of the EIDs"?
>
> -->
>
>
> 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.
> -->
>
>
> 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.
>
> -->
>
>
> 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.
>
> -->
>
>
> 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.
> -->
>
>
> 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?
>
> 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.
>
> -->
>
>
> 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
>
> See also: AFI = 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)
>
> 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?
>
> 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
>
> -->
>
>
> 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
>
> -->
>
>
> 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.
> -->
>
>
> Thank you.
>
> 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
