Thank you to Rich Salz for his secdir review. 

I agree with Rich's conclusions and would encourage the author to explain and clarify that design choice (use of ASCII characters).  This would include explaining how errors would be handled in the case of incorrect ASCII values being used.  

If the use of ASCII characters with no restrictions persists, then I encourage an addition to the Security Considerations to discuss the consequences of inappropriate ASCII choices.

I also agree that the use of 'Distinguished Name' is an unfortunate collision.  Given that, perhaps a definition could be added to Section 2.

# Internet AD comments for draft-ietf-lisp-name-encoding-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S2

* "An address is family currently defined" ->
  "An address family is currently defined"

# Gunter Van de Velde, RTG AD, comments for draft-ietf-lisp-name-encoding-10

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

# Many thanks to Acee Lindem and Christian Hopps for the RTGDIR reviews and Alberto Rodriguez-Natal for the shepherd write-up

# please take these NON BLOCKING comments as suggestions to help improve the content if you feel appropriate

#GENERIC COMMENTS
#================
## Well written draft, short and to the point

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

10	Abstract
11
12	   This draft defines how to use the AFI=17 Distinguished Names in LISP.

[minor]
This abstract is rather brief and could use some more meat to the bone to sumamrize the content of the document.
What about the following proposed textblob:

"
This document specifies an encoding format for names in LISP. The proposed encoding supports various naming schemes, including DNS names, distinguished names, and user-defined names, facilitating the integration of LISP with diverse applications and services. The encoding ensures efficient and scalable name resolution within the LISP mapping system. Additionally, the document addresses interoperability considerations and provides guidelines for implementation. This work aims to enhance the flexibility and applicability of LISP in modern network environments.
"

116	   17.  This draft defines a termination character, an 8-bit value of 0
117	   to be used as a string terminator so the length can be determined.

[minor]
RFC0020 seems to name the 0000 000 ascii characted 'NUL'. WOuld that make sense to mention or name the character like that in this document?

139	     0                   1                   2                   3
140	     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
141	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
142	    |            AFI = 17           |       ASCII String ...        |
143	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
144	    |               ...  ASCII String             |       0         |
145	    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[minor]
Clarification. Is the '0' termination character assumed to be at a 32bit boundary? or can it be somewhere else?
Maybe worthwhile to explicit document the expectation. RFC states that an ASCII character is represented using 7 bits. However, in practice, it is often stored in an 8-bit byte, with the extra bit typically set to zero.

218	9.  Sample LISP Distinguished Name (DN) Deployment Experience

220	   Practical implementations of the LISP Distinguished Name
221	   specification have been running in production networks for some time.
222	   The following sections provide some examples of its usage and lessons
223	   gathered out of this experience.

[minor]
I believe that this complete section is informational and belongs more in an appendix to make it explicit that its not part of the formal procedure outlined in this document and are examples.

"Abstract", paragraph 1
>    This draft defines how to use the AFI=17 Distinguished Names in LISP.

Would agree with some of the other reviewers on the brevity of the Abstract.

The IANA review of this document seems to not have concluded yet.

DOWNREF [RFC8060] from this Proposed Standard to Experimental RFC8060. (For
IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and
also seems to not appear in the DOWNREF registry.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 9.1, paragraph 2
> hat plan to switch to using a reliable transport to hold registrations first
>                             ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"reliable transport".

Section 9.2, paragraph 1
> m is distributed, the ETR requires to have one specific mapping ready to be r
>                                    ^^^^^^^
Did you mean "having"? Or maybe you should add a pronoun? In active voice,
"require" + "to" takes an object, usually a pronoun.

Section 9.2, paragraph 1
> hat they can switch to using a reliable transport. This can also lead to gene
>                              ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"reliable transport".

Section 9.2, paragraph 4
> unnel Router (RTRs) as they appear in an locator-set. 9.4. DNs for Self-Docu
>                                       ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

I support Paul's DISCUSS.

Thank you to Jouni Korhonen for the GENART review.

** Section 3
   When Distinguished Names are encoded for EIDs, the EID-Prefix 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
   null 0 octet).

Is “EID-Prefix length” described here the same as “EID mask-len” described in RFC9301?  “EID-Prefix length” is not a string found in FC9301.

** Section 3
   The string of characters are encoded in the ASCII character-set
   definition [RFC0020].

To confirm, any RFC20 ASCII string is a valid EID?  For example, “0x01 0x02 0x03 0x04” would be valid?  How would a non-terminating 0x00 be handled – is that invalid?

I concur with the SECDIR reviewer (Rich Salz) that it would be helpful to explain this design choice.

** Section 5.
   An RLOC that describes an Ingress or Egress
   Tunnel Router (xTR) behind a NAT device can be identified by its
   router name, as in [I-D.farinacci-lisp-lispers-net-nat]

Per [I-D.farinacci-lisp-lispers-net-nat] (draft-farinacci-lisp-lispers-net-nat): Given that the IESG conflict review on this document came back as “Request not to publish” (https://datatracker.ietf.org/doc/conflict-review-farinacci-lisp-lispers-net-nat/), is the WG confident that it makes sense to mention this document here?

Thanks for working on this specification. I will support Paul's discuss on security considerations. I would like to understand why there is no security considerations, is this already considered somewhere else ?

# Éric Vyncke, INT AD, comments for draft-ietf-lisp-name-encoding-09

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Alberto Rodriguez-Natal for the shepherd's detailed write-up including the WG consensus _and_ the justification of the intended status.

Other thanks to Tim Winters, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-lisp-name-encoding-09-intdir-telechat-winters-2024-07-25/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

Normally, it is expected that abstracts are short, but this one is probably a little too short.

## Section 2

Is there an inversion in `An address is family currently defined` ?

## Section 3

Unsure whether using ASCII rather than UTF-8 is wise.

I am not familiar enough but it seems that the length field is sometimes expressed in bit units or in octect units. Adding some clarifications would be welcome.

`then any length field is the length` is really unclear with the use of "any" in the sentence.  

## Section 4

Is the match case sensitive ? Nothing is said.

## Section 5

Please avoid using a commercial USA name "GPS" in `GPS coordinate mappings` rather use the "GNSS" term (that applies to Galileo, GPS, ...) or even remove "GPS" entirely. 

## Section 7

Nothing is specified when the NULL character is not present.