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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 06 May 2020 20:19 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 7D8E73A0D23 for <regext@ietfa.amsl.com>; Wed, 6 May 2020 13:19:23 -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 skJv6M7Y6A88 for <regext@ietfa.amsl.com>; Wed, 6 May 2020 13:19:10 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 C2A833A0BB5 for <regext@ietf.org>; Wed, 6 May 2020 13:18:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=11172; q=dns/txt; s=VRSN; t=1588796323; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=9Q4Ly0PwmrCE7+aT1vwT6ORivzZjfp04cKjZXz3fvEE=; b=CPjPznX5xJuGeG+c2DnWRSsN03G1DHwJPZqVLL73R+Uy9gqnyMK0ZVri r1El9ievoVq94/v/6AR3iWzfAekd2M2fxvjPzDnAeZ8bhAkHwchivpx/c AYGGvGTUNtt4kYnvuWGYc8/SVGJLJHBIh0OwLnB9J+xWSMk5pr6HngnVs u9FBC3x2E+K8BaXCwy9BD8GLB/XNMLx2Jc8MNgxGhi6xB7hlCuTBzXFc4 ZoNHWjedc+PZv+1n/tvDVJ2MwLt4PoChy2qzAsZd36iE9iX+sW+4ewLow NhXbzFJeUggKXAC/Ega89976DWSrYU92VYJH8rUnSQvDjyysC2ZqFD5wY A==;
IronPort-SDR: V/iBP64B+hTxXBAymkLbtVilrR8E2JKYd2H/eZHqUZiOnU/3po6GJQhM2WCXoaAF0zWhVSmeA0 IoKPmxWGWlDXA5c3IcM3J0q/zaMk3m8DXLG4bHc+DDgjbcdPUHdilXrLs2vTqpulZUeb+An1OC n3DuOwQ4wV9UY46z2EKdx+5e3/INabYClY8dme8iHRC8v3I3tDbOlWmwjbX7OHMCAX5NGo25vP 5zhKcEJZzHSwK2SZzcIuPdOHioHcZbQzOLJLMICGAVSxek68oGF5iMPIC/HbAiLlVufsOumXHe Y3M=
X-IronPort-AV: E=Sophos;i="5.73,360,1583193600"; d="scan'208";a="1518360"
IronPort-PHdr: =?us-ascii?q?9a23=3AElS/FxOHND09L+UB0H0l6mtUPXoX/o7sNwtQ0K?= =?us-ascii?q?IMzox0K/36osbcNUDSrc9gkEXOFd2Cra4d1qyJ4+u5AjFIyK3CmUhKSIZLWR?= =?us-ascii?q?4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBx?= =?us-ascii?q?rwKxd+KPjrFY7OlcS30P2594HObwlSizexfLN/IA+0oAjSucUanIVvJ6YswR?= =?us-ascii?q?bVv3VEfPhby3l1LlyJhRb84cmw/J9n8ytOvv8q6tBNX6bncakmVLJUFDspPX?= =?us-ascii?q?w7683trhnDUBCA5mAAXWUMkxpHGBbK4RfnVZrsqCT6t+592C6HPc3qSL0/RD?= =?us-ascii?q?qv47t3RBLulSwKMSMy/mPKhcxqlK9VoAyvqQFjw4DaY4+VOvhxfqLBct0VSm?= =?us-ascii?q?VMRdpRWDdDAo+gc4cDE+gMMOBFpIf9vVsOqh6+CBGiCO3tzT9Ignv20rM80+?= =?us-ascii?q?s6Dw7JwA8gE8oTu3rJsNr1M7sSUfy7wKLVyjjDdPNW2TD56IjMbB8hp+qDUq?= =?us-ascii?q?xsfsrS0kQvCR3Kjk+RqYz+PjOV2eINv3KH4OpnUOKikmgqoBx+rTaz3MkjkJ?= =?us-ascii?q?XJhp4LxVDe8yV02Jg5K9O5RUN1btOpFJlduS6UOYZ4QM4vR29mtSckx7MIt5?= =?us-ascii?q?O2fjUGxZQ5yhPbZfKKfIuF7xLiWeieITl1mHFoda65ih2v/0agzej8WdO10F?= =?us-ascii?q?ZMtidKjNbNuWoI1xzL7siIVOFx/kG/1jaTzwzc9uBEIVsomqrcMZIu3rkwlp?= =?us-ascii?q?8LvUTNHiL6gln5jKiTdkk8++in8eLnba/8qp+bLY90hRnyMqQymsyjGeQ1PB?= =?us-ascii?q?IBU3aV+eii2r3i80P4QbtQgvIqianUto3RK8cDpqOhHgNZzpwv5wu9Ajqoyt?= =?us-ascii?q?gUgHkKIVxfdB+Ii4XlI0zCLOziAfuigVmgjC1ny+3JM7DiGJnBM3vOnbH8dr?= =?us-ascii?q?hn8UFc0hA8zdVH6pJRDbEOPez8V1fqtNzdEh85Kwu0w/v7CNll1oMRR2aPAq?= =?us-ascii?q?iBPa7PrVGG/v8jLOmUaoEauTnxN+Yp6+TwjXAlnl8dZ7Gp0YENZ3+lBPhmPV?= =?us-ascii?q?+ZYWHqgtsbDWgKuQ8+QPTriF2ETzFTe26/U78g6j0hFY6rD4nOSpqwjLGB0i?= =?us-ascii?q?q3BJJba2ReBlCJC3jodoGEW/kWaCKVJ89siicEVbimS48l0RGhqgn6xKF5Ie?= =?us-ascii?q?XI+S0Vrozj28Zv5+3SjhEy9DN0D8KH326RSGF0m3sERyUq06BnvUx91lCD3L?= =?us-ascii?q?Bgg/xdDtFc+vRJUhsgOp7a0uN1F9fyVhjdcdeOTVasWs+mDi0pTtIt398OZF?= =?us-ascii?q?5wG8+8gRDMwSWrDKMVmqeKBJMq7qLc0WL9J8Fny3bJh+EdiAxsWs5nOWq6j6?= =?us-ascii?q?hz/A+VDInM2Q3Nj6OCeaMA1SjB/2DFxm2L6gUQGhR9XqjVQVgea1fY69Pj6Q?= =?us-ascii?q?mKG6WjBrk3LiNAxNKMbKxQZYu6o09BQaKpGNPaZ2+3kWq7BlLA/biLcJagMz?= =?us-ascii?q?EG3CLZDEUCmQ0Y/l6YOBI/HSaupSTVCzk4RgGnWF/l7eQr8CDzdUQz1QzfN0?= =?us-ascii?q?A=3D?=
X-IPAS-Result: =?us-ascii?q?A2GzAACdGrNe/zGZrQpmHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?TYEAQELAYMXgTEKhBmRD5siHCALAQEBAQEBAQEBBwEjDAQBAQKBToJ0AheCD?= =?us-ascii?q?zcGDgIDAQELAQEBBQEBAQEBBQMBAQEChj8MgjsiGF88CQwBAQEBAQEBAQEkA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQQCDQJSAkcBA?= =?us-ascii?q?R0BAQEBAgEjERMrDAcEAgEIEQQBAQECAiYCAgIwFQgIAgQBEgiDH4JcL7NWd?= =?us-ascii?q?oEygzaBAwGBFoUMgQ4qAYFbg1CHMoFCPoERgxA+gmcBAQKBUQODIYJgBI5uA?= =?us-ascii?q?YJWkQaPCX0DB4JIiBiPdiWCW4EMh1WRZJAXiVSFVI10AgQCBAUCFYFogXpwU?= =?us-ascii?q?IJpCUcYDZBOFxWDOoRZhX10DSoCBgEHAQEDCZADgTOBEAEB?=
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; Wed, 6 May 2020 16:18:39 -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; Wed, 6 May 2020 16:18:39 -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/i0cPQF1qibhkyQ
Date: Wed, 6 May 2020 20:18:39 +0000
Message-ID: <27200d8b050941e1a7820de20dc7dc3d@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/i4pOkotDkgYTC9YvqK2axtK-aNQ>
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: Wed, 06 May 2020 20:19:30 -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.
> 
> 
> 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?

Agreed. I'm thinking of doing this to the text:

OLD:
The string literal "rdap_level_0" signifies conformance with this
specification.  When custom JSON values are inserted into responses,
conformance to those custom specifications MUST use a string prefixed
with the appropriate identifier from the IANA RDAP Extensions
registry specified in [RFC7480].  For example, if the fictional
Registry of the Moon wants to signify that their JSON responses are
conformant with their registered extensions, the string used might be
"lunarNIC_level_0".  These prefixes aid the identification of
specifications for software implementers, and failure to use them
could result in slower adoption of extensions.

NEW:
The string literal "rdap_level_0" signifies conformance with this
specification.  When custom JSON values are inserted into responses,
conformance to those custom specifications MUST be indicated by
including a unique string literal value registered in the IANA RDAP
Extensions registry specified in [RFC7480].  For example, if the
fictional Registry of the Moon wants to signify that their JSON
responses are conformant with their registered extensions, the string
used might be "lunarNIC_level_0".  These registered values aid the
identification of specifications for software implementers, and
failure to use them could result in slower adoption of extensions.

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

Do you have text to suggest?

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

We can't change the structure as part of this effort, but if there's an issue here we can create a ticket for it. I'm open to suggested text for a better description of the "type" value.

> 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",

This is a bug in 7483 and/or the RFC publication process. Those examples are supposed to contain non-ASCII characters. The challenge here is that the characters in question are part of U-labels, so we have to use something that's appropriate for representing a U-label. I think that means that I need to make sure the Unicode characters are preserved when xml2rfc produces the text for the I-D.

> 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?

Agreed.

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

Agreed.

> 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)

Let’s defer this.

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

I found a current reference that I'll use for a replacement:

https://devcentral.f5.com/s/articles/the-stealthy-ascendancy-of-json

> 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)

Agreed.

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

I'm of the mind that rdap_level_1 will be required if/when we actually describe protocol *changes* that require a new Proposed Standard specification. I don't think we're there yet.

Thanks for the feedback, Patrick!

Scott