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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 27 April 2020 11:25 UTC

Return-Path: <shollenbeck@verisign.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 BC8A13A0890 for <regext@ietfa.amsl.com>; Mon, 27 Apr 2020 04:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_HELO_NONE=0.001, 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=verisign.com
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 rXHcupPoplBB for <regext@ietfa.amsl.com>; Mon, 27 Apr 2020 04:25:58 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A62F3A0899 for <regext@ietf.org>; Mon, 27 Apr 2020 04:25:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9144; q=dns/txt; s=VRSN; t=1587986757; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=pw4Z29P9GeyKSSagIHqyp5LxmDBg+oOiTJ/ggw2sIlw=; b=lJ2ZPNjzZPZW3+Gv3YZIL68bSKTig8MdOYR3rIBCZENJGIL/dY3GxHbE Osi7QRxcjxSdhMonortnA/kxL0Vo8E4Fd9/vdufzNJWXh1dzX1N4O27TJ MtEFPWdJpcCsOEgZHw0J822qaMBLRa6AFFTuEx5SYC7L3nWYnuxsuVnsd hlmzRQp10c/4SzNl+xvbngsRPYdJDEw/mltKv0i/FgatwwG2AySaAgo0l ubxWecs1mKdUyb5poW8zq8zZux67gN250eNs4ciX57zJ3sfyGAb1VBlb7 LNsPD+tgoAypd6te0nYEp/ELxDGqmOenYAJ6h5HRp/X6gf5DRFrWUYVGL A==;
IronPort-SDR: Tw4MkOLBMV+N0H90uYGk7rrEEg0iEYDHgTTgZvsztddlCI13HQ1M5i/O7ApBtKT/xwm8cB1XJz kMmsWEF+aiT3f9w3+cJoVlYgSUmlR3fcHaMoZKyGasDxydfDWzK8bxk2tE1bVcdOtw7DlFhwE/ i1X/N2F6KPUlRZ6Cz6PUIU+NK44ncO5+C2yGA2ezuR6c8FQy2wRmqd+OLT9fR9xu6ZnTFcCRiJ obK1h8hrw1PSak+80OmIeMuJkcCuFeaGCR/PV46bFcnvnPF/9v7ImB0ZRaRqg7v28kWnNxglCh 8DM=
X-IronPort-AV: E=Sophos;i="5.73,323,1583193600"; d="scan'208";a="1372731"
IronPort-PHdr: =?us-ascii?q?9a23=3Ap7QGtRSRnIIx3tCoFR+u6PAiJNpsv+yvbD5Q0Y?= =?us-ascii?q?Iujvd0So/mwa67ZBCFt8tkgFKBZ4jH8fUM07OQ7/m9HzFRqs3e+Fk5M7V0Hy?= =?us-ascii?q?cfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFR?= =?us-ascii?q?rwLxd6KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAi2oAnLtsQbhYRuJ6gzxx?= =?us-ascii?q?DUvnZGZuNayH9yK1mOhRj8/MCw/JBi8yRUpf0s8tNLXLv5caolU7FWFSwqPG?= =?us-ascii?q?8p6sLlsxnDVhaP6WAHUmoKiBpIAhPK4w/8U5zsryb1rOt92C2dPc3rUbA5XC?= =?us-ascii?q?mp4ql3RBP0jioMKjg0+3zVhMNtlqJWuBKvqQJizY7Ibo+bN/R+caHcfdwGSm?= =?us-ascii?q?ROUd1cVzBaDYO+c4cDE/YNMOReooLgp1UOtxy+BQy0Ce/hyDFIgXv23akk3O?= =?us-ascii?q?QnCg7JwhAvH9EWvH/Jsdv6KKASUfypzKXG0D7OaOhW2Tf66IjMdhAuv/eMUq?= =?us-ascii?q?lufsXNykkiDB3FgUuKqYzkJDOV1+sNs26B4+V8UuKvjncqpgdsqTahwccsj5?= =?us-ascii?q?PGhoMTyl3c6yp4z5w6JdigSE5/f9GoCp1QuD+GN4duXswiQnpotzo9yrEcpZ?= =?us-ascii?q?G7ey0KxIwpxxPfcfCIb4+I4hf7WOaQOzh4gmhqdKi4hxao/kis0u38VtWo0F?= =?us-ascii?q?ZSoCdKiMfAtn4T2xzd5MmGRPV88l291jaUzwzT6/9LIVw6labBLJ4h2LEwm5?= =?us-ascii?q?wOukrABi/7gFj6gLOMekk5+OWl5f7rbqjmq5KSLYN5hQXzPrwzlsCjG+g0Lw?= =?us-ascii?q?oDU3SB9eih27Du/lf1TKhJg/Awj6LXqorVJd4Bqa68GwJV14Ej5AuhADq+y9?= =?us-ascii?q?QYmGUHLEpCeBKak4jlI1HOL+78Dfe4m1mhjStlyejbMrLhGpvDIXnMnKv/cb?= =?us-ascii?q?pn9U5T1A0zzcpH555OEL4OPej/WlHrtNzDCB81KRC7w+HiCNll14MeX3yAAr?= =?us-ascii?q?OBPa/PrVOE/P8jLuuCaYMPpTrwK/Yo6+ThgHI9gVMdeLOm3ZoTaHC2BPRmJE?= =?us-ascii?q?CZbGL3gtcBFmcKug4+Q/LsiFKZTzFce3WyUrki5j4lEoKmDJzDRoGigLyHxi?= =?us-ascii?q?u0AppWZmVeBlCWDXjob5mEW+sLaC+KOs9hlycJWqWmS489zx6ushL1xKZgLu?= =?us-ascii?q?bO5iIYspfj3sBv5+LPjREy6SB0D8OF3mGXUW50kX0HRjAq3K1koExy1EuD0a?= =?us-ascii?q?Zij/xfD9xT6KABbgBvf4bZ5+B9F9n0VgnGONyOTRzuFs2jKT02Uts3z9QJJU?= =?us-ascii?q?16HoPmxlrZ0iWnE6M9lrGXCtoz6K2WlyzrKslw22ru1aQ9gR8hWMQZZkO8ga?= =?us-ascii?q?sqvSjUA4rElU+UnKXuPZ8X2zLRvi/X1mqJuEVVVgR9WqbtQ30FZ1DXotK/7U?= =?us-ascii?q?THGez9QY87OxdMnJbRYpBBbcfk2A1L?=
X-IPAS-Result: =?us-ascii?q?A2GvAAAfwKZe/zGZrQpmHAEBAQEBBwEBEQEEBAEBPIE2B?= =?us-ascii?q?AEBCwGDFYExCoQVg0mNT5scPAsBAQEBAQEBAQEHASMMBAEBAoRCAheCNjcGD?= =?us-ascii?q?gIDAQELAQEBBQEBAQEBBQMBAQEChj8MgjsidzwJOAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBAINVEkBAR0BAQEBAgEjEToEDAcEA?= =?us-ascii?q?gEIEQQBAQECAiYCAgIwFQgIAgQBEgiDH4JcL7B6doEyhAE4AYEVhQ+BDioBh?= =?us-ascii?q?SiHLoFCPoERgxA+gidAAoFWgyGCXwSOYgGCVKBrAweCRYgPj2klgluBB4dQk?= =?us-ascii?q?UmPeoFWh3KFUI1uAgQCBAUCFYFogXpwUIJpCUcYDZFsgzqEWYV9dA0oAgYBB?= =?us-ascii?q?wEBAwmMWYEzgRABAQ?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Apr 2020 07:25:54 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1913.005; Mon, 27 Apr 2020 07:25:54 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "pm@dotandco.com" <pm@dotandco.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt
Thread-Index: AQHWHGi+O4AEmUD480eN5/i0cPQF1qiM07GA
Date: Mon, 27 Apr 2020 11:25:54 +0000
Message-ID: <c8e89cf2ffc544a4aeff212f7e187586@verisign.com>
References: <158202847369.14106.8963334452011519309@ietfa.amsl.com> <bb1c73111e9f48ff83f8b1e454faf954@verisign.com> <5b82dd6f-c2c3-4fb5-9084-b580823a669a@www.fastmail.com>
In-Reply-To: <5b82dd6f-c2c3-4fb5-9084-b580823a669a@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/rpgnAroSWO3Cm_vACckmT8Ya0X4>
Subject: Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7483bis-00.txt
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 11:26:00 -0000

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of Patrick Mevzek
> Sent: Monday, April 27, 2020 3:51 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-
> rfc7483bis-00.txt
>
> 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.

The goal of the update is to only address necessary editorial corrections and clarifications. No protocol changes. Some of what you describe below has already come up in on-list discussion, so it will be addressed. Anything that changes the protocol itself will be out of scope for now. I'll take a look at everything below as I work on the next version of the document.

Scott

> 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://secure-web.cisco.com/1n_IpHslw-
> LLCMuu5QUV4Lywyxl7Zw7jsRk_jlusbxbaqWngp5UJ7qt6awNKo2l5LsxsudaH-
> y_HhXmqEdM3Wk8jPzDczGsJHH5JtRro34OgWuP5kApjBYrFKvmko4IbzYv0XkJ
> uev1U7OxhgV6fgtQOcx22hKHtmD9gyKumALcGjCHJKw_3m6YEheOfUH8A-
> N6kj4hcxKFY2K3wkcG9rY4Pu0UBWHD2F8w4_zkBOWEMBort77E5KNoR8zWX
> Qx-
> o4eak_DarWCMZsSs4elpwGrw/https%3A%2F%2Fdevcentral.f5.com%2Fs%2
> Fweblogs%2Fmacvittie%2Farchive%2F2011%2F04%2F27%2Fthe-stealthy-
> ascendancy-of-json.aspx is today a 404, so not really useful.
>
> For
> http://secure-web.cisco.com/141YW_PfA508VT6T6Dqt7nKZJDQ8czL4-
> FVZF408HiR1o4DWzE_X3CnPn0bl1Is2dqvB8fHsDFbA-
> l60a1AhiZdCohCSsA_EBybtY1NIgNEu9HaMmjUH82G8aYEM5Ty_9-FCEzj5AIU-
> qT1J_u11rBOYcRwPRlAwx7qPhw-
> lPquUcIG4trMyOLoXdEQm1Ai0IqIbKzCfLF7PgU8RKaoQ746sQu85RANh8x_8Bt
> WjLweo4ekahjSTrBcftAzUeG5881Ds5I2B48C2ilzNQWpng4VN8iGoaQ8z6Q8uB
> hwlmJuA/http%3A%2F%2Fwww.iana.org%2Fdomains%2Fidn-tables
> maybe use https:// instead.
>
> Same for http://secure-web.cisco.com/1Z-
> vlcEAhtgcUzjGDACcnU1o3wnRnWFLS7Np9g1GhHdXyggixazay3-
> opBNnCsvm3rPO3CdB08cy25xNV97GX5N0Q1fjryYF90SHT2xSVpnfGSiGKy-s2-
> dPw3MHMFZ5d1o7ZNdGE-
> cw0zJjL0j59aeP_lyQSz76nTC1PZWMcQ_FsYltVPcvstUtKcp6i_FJP4ltiknXdcSBX
> q1cv8BfZkKAssogfHVobluV33ajG33Qd3pVoODzpInnKYMWu3CZw7JPI_31yLX
> ZC03bEUvzIbQ/http%3A%2F%2Fwww.cs.montana.edu%2Fizurieta%2Fpubs%
> 2Fcaine2009.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
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://secure-
> web.cisco.com/19hy_uSuQ7ymESjnI6rLBR_KRE_2xE7ViCH1no0YDnvx_e0ENd
> J9fjWlEp2VgZFXqF4aRT9Yx1J4299qXO5XY-il2dND729Fz-4f-
> 0x8WwJxxxH0nY66x9aGdaaCbHCwlUVscNathDwDxvLDAPwaHAO3L0CJ_yBHF
> oyNveDPAWqmi0kMf4ZJX5NkRcV_qCxSdP5EA26GguNpN9GJsTVCjChl3cwM
> P_WbIUpX2PXvr9AUJykX2sZRTp3GMqpRhrk8bbCJNmPMZwwEp0i9BGAbgeo
> 5HdVWOykDhOoOtRlpGCno/https%3A%2F%2Fwww.ietf.org%2Fmailman%2
> Flistinfo%2Fregext