[lisp] Gunter Van de Velde's No Objection on draft-ietf-lisp-name-encoding-10: (with COMMENT)

Gunter Van de Velde via Datatracker <noreply@ietf.org> Mon, 05 August 2024 10:07 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from [10.244.2.66] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id CD88EC14CE3F; Mon, 5 Aug 2024 03:07:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Gunter Van de Velde via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172285247723.647368.5242646312252412404@dt-datatracker-6dd76c4557-2mkrj>
Date: Mon, 05 Aug 2024 03:07:57 -0700
Message-ID-Hash: 7743NERKBJ4ZKWRDPSWZ4SWCCFBLAJYY
X-Message-ID-Hash: 7743NERKBJ4ZKWRDPSWZ4SWCCFBLAJYY
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-lisp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-lisp-name-encoding@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Gunter Van de Velde <gunter.van_de_velde@nokia.com>
Subject: [lisp] Gunter Van de Velde's No Objection on draft-ietf-lisp-name-encoding-10: (with COMMENT)
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/S-OsQdLUn6ZND33RBWp6XeljQus>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Owner: <mailto:lisp-owner@ietf.org>
List-Post: <mailto:lisp@ietf.org>
List-Subscribe: <mailto:lisp-join@ietf.org>
List-Unsubscribe: <mailto:lisp-leave@ietf.org>

Gunter Van de Velde has entered the following ballot position for
draft-ietf-lisp-name-encoding-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-name-encoding/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# 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.