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
