Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt

Patrick Mevzek <pm@dotandco.com> Mon, 27 April 2020 07:51 UTC

Return-Path: <pm@dotandco.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01D23A1193 for <regext@ietfa.amsl.com>; Mon, 27 Apr 2020 00:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=NrA9QME0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qn2p+CN6
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PupPBSj_GKbt for <regext@ietfa.amsl.com>; Mon, 27 Apr 2020 00:51:43 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044913A1190 for <regext@ietf.org>; Mon, 27 Apr 2020 00:51:42 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 0E3FF43A for <regext@ietf.org>; Mon, 27 Apr 2020 03:51:41 -0400 (EDT)
Received: from imap22 ([10.202.2.72]) by compute3.internal (MEProxy); Mon, 27 Apr 2020 03:51:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=htTsg Otoj5iHCHFSjeHqcaUJbz3jEYMpqKngCDlAb8Y=; b=NrA9QME0k2sP+shqyDHda NPU3mcsGm7hkxagc2iOK2Aa526NX/9l836NVOpTofCGOGZv+02YNyEGEQrDqfqUS OSlK03UEaLR0u/T/8aE3MaQA92v7eCogts6ukWznxB6aF3zyRem4OWaXNMDHpRmd 4Kt5QEr2lEdPpLgUIw1KEwBXAo7a3dr8JlNTEsYr0d6vGWPEJecPJGlV10ap5dBz FI7nMVkiZTIBWyhXtEjVNyBM4/KydYpkT8cEBrhUr9beBLTBMRbCKl+7m6t5fD7Z 4JUQFbApkaWgPBP0x3/1QNVwbR0hSXd+6YkMLUq8Fh2uqZFNgz81CBhYwgcTwE4U A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=htTsgOtoj5iHCHFSjeHqcaUJbz3jEYMpqKngCDlAb 8Y=; b=qn2p+CN69PwHQF4pREVS6nZqEdOH9JvBxD/TdiWNOSVxPSLSFAKExYWJR hXp7f0kFVB+nLLRKAilwh1PZkrYbWpNKrkR3OrMn3EygTGMK78tFzDx9jf5GcWc9 sAJ81dKJFLPN0pSNtCP+VekzcAZ/O7lK+VoSJR2pWaWI3rNfQXt+MEcj2MhA0eK1 3pdB4y97mhseHPo2Ozab4K9nmK2G4l7TjxyuZH2peM4BXMyyERRS+GEmJyLK6oXi HTx0/lQeLgw97QIX/0mVmbxLSmhPufSwDz53e/HIs6ZxKYsI8mXRgImDWDJCCoKO FYK+VokRbh3HdVfxBjrDjwhaVFNxw==
X-ME-Sender: <xms:DY-mXpgMU54lzjtfaGxJ96LeUaVtMkouERNn_n_a0SoyPklDekhZfVohZBQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheekgdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdfrrghtrhhitghkucfovghviigvkhdfuceophhmsegu ohhtrghnuggtohdrtghomheqnecuffhomhgrihhnpegvgigrmhhplhgvrdhnvghtpdhfhe drtghomhdpihgrnhgrrdhorhhgpdhmohhnthgrnhgrrdgvughunecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhmseguohhtrghnuggtohdrtg homh
X-ME-Proxy: <xmx:DY-mXkZrN8VucC17712n81ecw3AMjISTI6y8URhoy5W6BPCCxhF9lQ> <xmx:DY-mXlWycdjvFHbU7Nr8Ny1iodtzg4INikSiQjwnRjOhH_IjanlyLw> <xmx:DY-mXsHratDbwi6VGYyrbhWPAAWjmplke0QrYr8q7vWGKgoCLyG74g> <xmx:DY-mXvwJSv5Rh0DR8voXwoFc1TF58oRX3bBpfMka4MdX44EyrN5ZMg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 566FB6680073; Mon, 27 Apr 2020 03:51:41 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <5b82dd6f-c2c3-4fb5-9084-b580823a669a@www.fastmail.com>
In-Reply-To: <bb1c73111e9f48ff83f8b1e454faf954@verisign.com>
References: <158202847369.14106.8963334452011519309@ietfa.amsl.com> <bb1c73111e9f48ff83f8b1e454faf954@verisign.com>
Date: Mon, 27 Apr 2020 02:51:21 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Wh5wbS1SGRXVOK4l8dTRkvWM8aU>
Subject: Re: [regext] =?utf-8?q?FW=3A_I-D_Action=3A_draft-hollenbeck-regext-r?= =?utf-8?q?fc7483bis-00=2Etxt?=
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Mon, 27 Apr 2020 07:51:45 -0000

Hello Scott,

On Tue, Feb 18, 2020, at 07:31, Hollenbeck, Scott wrote:
> Lastly, let's 
> start to talk about any other needed clarifications. Are you aware of 
> any? Send 'em to the list for discussion.

First, please excuse me in advance if I didn't understood things right, as my points below are maybe more than a clarification so I do not know if the bis version is expected just to fix the nitpicks/errata or really revisit some points.

If the latter feel free to disregard most of the below. They are in part related to previous discussions here and also Marc's draft on deployment findings.


2.1
I think there should be far more explanations (or even enforcement)
of the relationship, if any, from the specific label used in rdapConformance
and then used as prefix for extended names.

Like, to be able to use "lunarNic_beforeOneSmallStep" and "lunarNic_harshMistressNotes"
does that mean that there should be (and hence registered at IANA)
"lunarNic_level_0" in rdapConformance?
This seems to be the case, comparing text between 2.1 and 4, but I think it should
be more stressed out if it is a requirement.

There should be more explanation also on what is registered at IANA,
since there is confusion, about the "level_0" ending. Is that mandatory? Suggested?


4.2 Links

I think there should be more explanation of what "value" (the context URI) means
in the case of RDAP. It is optional like all others except href, but is visible
in examples, so more guidance would be welcome.

4.8 publicIDs

I am under the impression that the same structure as for links could be reused.
Also "type" should be better explained or even be in a IANA registry.

Unfortunately I lost my previous notes but I think I sensed there  a possible interoperability
problem, but now I am not so sure. Sorry about that, will try to remember that point again.

5.2 Maybe nitpick

       "ldhName" : "ns1.xn--fo-5ja.example",
       "unicodeName" : "ns1.foo.example",

It is absolutely not clear that the unicodeName does indeed have a non ASCII
character (hence the ldhName), as just copying the string from the document
into any viewer shows purely ASCII characters.
Maybe we should use guidance from RFC 7997?
And since it is JSON:

       "ldhName" : "ns1.xn--fo-5ja.example",
       "unicodeName" : "ns1.f\u00f3o.example",


5.4 Nitpick

"href" : "http://example.net/ip/2001:C00::/23",

Why uppercase characters are technically allowed per RFC7482 §3.1.1
as it says RFC 4291 formats are allowed and 5952 is only RECOMMENDED
(which specifically calls for lowercase only), it is still RECOMMENDED,
so there should be valid reasons to ignore it, and in this example it 
is not clear why it is not followed, so maybe simpler to just follow
the recommendation?


Also, the explanation for "status" should refer to section 4.6
like other parts do.


9.
If we are not in the just errata types of changes, I really recommend
a more "programmatic" way to signal truncation, instead
of having to rely on a specific string. Like using a boolean.
Deployments in the wild show that this string varies among servers.
I know that it is a registered string in IANA registry (so servers shouldn't vary
in theory), but I still
feel uneasy for an automated interface to have to rely on human strings
to decide what to do.
(especially when one of the reason given to favor JSON over XML is that
it is less bulky)

15.2 Nitpicks

https://devcentral.f5.com/s/weblogs/macvittie/archive/2011/04/27/the-stealthy-ascendancy-of-json.aspx is today a 404, so not really useful.

For
http://www.iana.org/domains/idn-tables
maybe use https:// instead.

Same for http://www.cs.montana.edu/izurieta/pubs/caine2009.pdf

(both do an automatic redirect from http:// to https:// anyway)




And with all planned changes to RFC7483, it is time to introduce
rdap_level_1
in rdapConformance values?
If we say: "we shouldn't because clients will not be upgraded, etc.",
then I believe rdapConformance is not useful, if it can not be used as an upgrade
path. We might as well consider then that rdap_level_0 is a kind of hardcoded
constant.

-- 
  Patrick Mevzek
  pm@dotandco.com