Re: [regext] draft-ietf-regext-rfc7483bis Last Call Comments Channeled from draft-blanchet-regext-rdap-deployfindings

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 14 September 2020 13:44 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 89E6E3A09E3 for <regext@ietfa.amsl.com>; Mon, 14 Sep 2020 06:44:17 -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 iE8ovHqYuBmA for <regext@ietfa.amsl.com>; Mon, 14 Sep 2020 06:44:16 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 0B4933A09E1 for <regext@ietf.org>; Mon, 14 Sep 2020 06:44:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2814; q=dns/txt; s=VRSN; t=1600091056; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=s8Swd8mXlmZN0CO6l4GyrjK0sMcD1xeCjb9dXz3mCo8=; b=ARY+E6wfJkH/BMvT9N+Jvdl4r2m0+vFQrRHCX3OdGUaA04sFj/34hp+G QALoNBgfqXVS/bOyXXGyqlD3DLSTDwz7XeEe9nM8C8sgVqwzZCGy9eBub gs2tvFpBvsDRiw9mzJUslvDN/dOiU0/thJ2/QDKt0sfJ7ZYka+PA98Pm6 9fFlfj6B4UkzKmde/V4u4MDZaiKAF3RZm4upLv9ipRKPl63JYYpbqFgub MdqkpuCwigqRDholFsi/PoENs8D105gFVm+TQ+6ZOvd0vEKda1Vr/VDPt tQDl03YIe+i/IVvFXVVchOhLpxgJMJc0KUUMhu8VX6dEKYtwaQPrqmmyA A==;
IronPort-SDR: oWcV4mQO6I+B7BuQWQzufrecBtxrX7PIDlB6Ciq870vsPARo/pPT9f5UnT+Z3AAuTUTeffF5Yi T5PmMgjCTCOnfCG7KMlh3jnH3R65iEwXths8KOiG1sXbborKd7Cxpsz5md5SgT5a1b+pQvIkiC W/6WGn51YLSSSLMGQngbF+y/6s8Wd/YvWnTcuIGRYIBHARs0MjqNLy7VnZfmEVQttkiSi4r+1N Zv7z469ezGphHTET7/K9118iPHNksAniVDjy2ouNU6Yfv82+1I/v5I13n3vN05ZCdnDp0RDjfz hsg=
X-IronPort-AV: E=Sophos;i="5.76,426,1592870400"; d="scan'208";a="2398050"
IronPort-PHdr: 9a23:bS+f9BLsOHJZ3AEcnNmcpTZWNBhigK39O0sv0rFitYgfL/7xwZ3uMQTl6Ol3ixeRBMOHsqwC0rSI+P6wEUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCe8bL9oMRm7rATcusYXjIZhN6081gbHrnxUdupM2GhmP0iTnxHy5sex+J5s7SFdsO8/+sBDTKv3Yb02QaRXAzo6PW814tbrtQTYQguU+nQcSGQWnQFWDAXD8Rr3Q43+sir+tup6xSmaIcj7Rq06VDi+86tmTgLjhSEaPDA77W7XkNR9gqJFrhy8uxxxzY3aYI+XO/p/YqzTctwVSHFdXsZIVSxNHp+wY5cRA+cHIO1Wr5P9p1wLrRamCwWiBuTvyjtMhnDo2601yPouHh3F3AA4AtkArWjbrNLpNKcOX+y+0a7FzS7Db/NR3Tf97JbHchY6rv6SQb1wctHcyVcxGAPfj1WQso3lPzyT1ugXr2eb6O9gWPuphmU6pA5/viKhyd0wionVmI0V0FbE+D17zYg6IdC1VUF1b9G4HZZQty+XKop7T98jTmxstyg21L0ItJ66cSYK1pgpxx7RZvKafoWJ5h/uVemcLDN5iX94fr+0mhi88U+lyuLmV8m01k5HrjBLktbQr3wCyQHc6smbSvt65EetwzGP1xrc6uxCPEs6lrLbJoY8zrIsjJYfrEbOEyHslEnrjKKbeF8o9+es5uj/f7nquoWQO5J2hw3iKKgih8OyDOciPgQTXGWW//m32qf58k3jWrpKi+U7kqzesJ/HO8sWvrW5AwpJ0oY77Ba/Eium3MwYnXYZKFJFfwqKgpX1NV/WPfz3De+xjVutnzt32fzKJKPhDYnKLnjZiLftZ6xy5FNGxAot19Bf/JRUBqsdL/L0X0/9rN3YDhknPAyo2+vrFclx2pkDVW+NDKKVKr7evF+G6+41LOSBYJcZuDPnJPgk4/7ug2U5mVgYfaSxxpsXaHe4HvBiI0qHZ3rjmckOHnsJvgclUuzllkeCUT9IZ3azUKI84Cs3B56hDYfGXoytmqCO3D+nHp1KYWBLEkqMHmnnd4qaVPYMdDmfIs5/nTwYW7itUYgh1QuhtFyy970yZPDZ9SAIqbri2cR7oerJmlt6oSZ5AMmNz0mMQn162GQSSGll8rp4pBk36lCH1aV+ifFTFpgb3PhOThtwfcrHz+t+D930UA/Kff+XRUynWdSpB3c6SddnkIxGWFp0B9j31kOL5CGtGbJAz7E=
X-IPAS-Result: A2FCBADEcl9f/zGZrQpgHQEBAQEJARIBBQUBQIFPgxqBNAqVZoECmxsLAQEBAQEBAQEBCAEjDAQBAQKESQKCKSU4EwIDAQELAQEBBQEBAQEBBgMBAQEChkUBC4I3InuBAwEBAQEBAQEBAQEBAQEBAQEBAQEWAg1UaAEBAQEDHR04EwQCAQgRBAEBHwULMh0IAQEEEwiDH4MLtE50gTSKVwaBOI1HgUI+gRGCWzU+hCWGDwSPYI1VmVEDB4JlmjQqgwmPLI43jg6EUIFxnXICBAIEBQIVgWuBe3BQgmlQFwINjisXFIhOhUJ0NwIGCgEBAwmPP4ERAQE
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.1979.3; Mon, 14 Sep 2020 09:44:13 -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.1979.003; Mon, 14 Sep 2020 09:44:13 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: draft-ietf-regext-rfc7483bis Last Call Comments Channeled from draft-blanchet-regext-rdap-deployfindings
Thread-Index: AdZ1astAsPab2hBTRSq82YYHXzwVyAVMgTTA
Date: Mon, 14 Sep 2020 13:44:13 +0000
Message-ID: <9207985bfeb24a218529d0ef872980e8@verisign.com>
References: <a461b003ac6247bbbd68f6d7b806446b@verisign.com>
In-Reply-To: <a461b003ac6247bbbd68f6d7b806446b@verisign.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Hcq5l4FiDYhBeUjOpJ0O1qNnSOE>
Subject: Re: [regext] draft-ietf-regext-rfc7483bis Last Call Comments Channeled from draft-blanchet-regext-rdap-deployfindings
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, 14 Sep 2020 13:44:18 -0000

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of Hollenbeck, Scott
> Sent: Tuesday, August 18, 2020 10:46 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] [regext] draft-ietf-regext-rfc7483bis Last Call Comments
> Channeled from draft-blanchet-regext-rdap-deployfindings
>
> Marc Blanchet recently asked me if I had reviewed draft-blanchet-regext-
> rdap-deployfindings as I edited the 7482bis and 7483bis documents. I missed
> that, so I thought I'd do it in the context of the working group last call for the
> two documents. Here's my summary for draft-ietf-regext-rfc7483bis:
>
> Section 3.3 of draft-blanchet-regext-rdap-deployfindings describes links
> relation values seen "in the wild, and suggests that "It would be appropriate
> to further describes the  main ones in the RFC so implementors focus on
> ones that are expected instead of picking the wrong ones in the IANA
> registry or to define new ones and do not register them".  Section 4.2 of
> 7483bis says that 'The "value", "rel" and "href" JSON values MUST be
> specified.  All other JSON values are OPTIONAL.' Is there something else that
> should be said here?
>
> Section 3.4 of draft-blanchet-regext-rdap-deployfindings describes an issue
> where a server returns a link of "rel": "related" is pointing to itself, therefore
> causing the RDAP client to fetch the object again, then read the related link
> and then fetch again, creating an infinite loop. It suggests a 7483 update to
> note that 'A link of "rel": "related" should not have the "href" value the same
> as the value of "href" of link of "rel": "self".' I think this is worth doing.
>
> Section 3.5 of draft-blanchet-regext-rdap-deployfindings suggests an update
> to note that both "rel" and "href" should be mandatory. 7482bis already does
> this, going one further by also making "value" mandatory. I don't think
> there's anything to do here unless people think "value" should also be
> optional. This was discussed on the list a while back and the current set
> reflects where I think we settled.
>
> Section 3.6 of draft-blanchet-regext-rdap-deployfindings suggests an update
> noting that " All links of any "rel" types should always be returned in the A-
> Label form for IDNs in the href or value members, independent of if the
> query was a U-Label or A-Label or a mix." I think this is worth doing.
>
> That's all that I captured. Did I miss anything Marc? Is there anything here
> that people would like to discuss?

I just submitted -02 to address the points above that I suggested are worth doing. I also addressed erratum 6158:

https://www.rfc-editor.org/errata/eid6158

I believe this version is ready for WG last call.

Scott