[regext] Artart last call review of draft-ietf-regext-epp-eai-12

Takahiro Nemoto via Datatracker <noreply@ietf.org> Thu, 09 June 2022 20:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: regext@ietf.org
Delivered-To: regext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0810CC157B5E; Thu, 9 Jun 2022 13:32:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Takahiro Nemoto via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-regext-epp-eai.all@ietf.org, last-call@ietf.org, regext@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165480673502.56173.16072247886040677393@ietfa.amsl.com>
Reply-To: Takahiro Nemoto <nemo@go.tuat.ac.jp>
Date: Thu, 09 Jun 2022 13:32:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/-fEOtZdvhN2RQylExznKKcf12EY>
Subject: [regext] Artart last call review of draft-ietf-regext-epp-eai-12
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2022 20:32:15 -0000

Reviewer: Takahiro Nemoto
Review result: Ready with Issues

I am the assigned ART-ART reviewer for this draft.

I think this document is concise and generally good, but a few things are not
explained well enough. Please consider revising the following points.

Minor issues:
- It is unclear how to provide "alternative ASCII addresses" in Section 5.3.2
and how to distinguish between an EAI address and an alternative ASCII address,
so it would be better to add an explanation.

- It is unclear how to verify the code points of domain names in Section 8, so
it would be better to add an explanation. RFC5892 describes how to determine
the code points that can be used in IDNA2008 but does not describe how to
validate domain name code points. So it would be easier to convey the intention
to the reader to write "validate whether the domain name consists of the code
points allowed by IDNA2008" rather than just writing "validate all code points
in the domain name according to IDNA2008". Also, if the validation described in
this section is intended to be compared to the code points listed in Appendix
B.1. of RFC 5892, it would be better to refer to IDNA Rules and Derived
Property Values
listing the latest IDNA Derived Property Values.