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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 18 August 2020 14:46 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 ECA123A0B8B for <regext@ietfa.amsl.com>; Tue, 18 Aug 2020 07:46:06 -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 f5gNenR3NxZd for <regext@ietfa.amsl.com>; Tue, 18 Aug 2020 07:46:04 -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 99A113A0B87 for <regext@ietf.org>; Tue, 18 Aug 2020 07:46:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2220; q=dns/txt; s=VRSN; t=1597761965; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=McZBJNlvc9dGKtJWyUVxVgNsc6jnxZTMh1LpmPZUOLY=; b=JqXgF4W5gCLIkkQGywqtiEt0aW73qeMdpONnHn9WWuLUW91S+9tVOVw2 oie5KRFqJMw2V2hjZembUHmP8HxWcRlGsmdnGQGgdA7PIM5HU3t1UHItw ojZ9K34tj+1rc9EwK6P9KynR82eXFnXZEyp+MUrd1Fsw84OEd32mGraZM M7RgRDobUZfwkjvhLpDGs9tIaYKPMIjn+hr8Q6Z/ixQn+oZb8fB5sc4hx xDe8IBslrnez3qA6g+pF7RhfL4OSYIvxHGFFO8gM02KWvuEHJ79surm4f xaOF4ZFts6X96zppyiHLYUdS+hTt4W4uTMd1RceT5DdiVOS6AFRv0Mevx w==;
IronPort-SDR: KqNh2bDEe3bo1zVPkhwh+G/eb+Rt16SziDHMRCYCKuMUgTlkvhxdW+1gtwOUY5TT0kHvGY69p/ rwKxgve0xd3dGwGSzXfTvrDCRLj8+naDrhKJBZ7U305qGVPSr4+zLguUz7hd2c/4oZYCJewEPt 1bMyVA2cndiObfQQNZrevcxRRsjGbGs6+jDJeDJTP0QJAz+LT+7Ff6GsD64iEe3eZdv2//4Un7 V9Nj/0nqBYf+hf4YIFRS8ylNGoIz4RXuw2S1Z1wTVr7977hAxkvgXE7nZxOVTDrdFbkEeVNUpi h+8=
X-IronPort-AV: E=Sophos;i="5.76,327,1592870400"; d="scan'208";a="2777144"
IronPort-PHdr: 9a23:/UJUTRcrqI8IYxjLtd6eLVmXlGMj4u6mDksu8pMizoh2WeGdxcW6Zh7h7PlgxGXEQZ/co6odzbaP7ea5ATJLv8bJmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFRrlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanbr5+MRS7oR/MusUKgIZuJac8xxjUqXZUZupawn9lK0iOlBjm/Mew+5Bj8yVUu/0/8sNLTLv3caclQ7FGFToqK2866tHluhnFVguP+2ATUn4KnRpSAgjK9w/1U5HsuSbnrOV92S2aPcrrTbAoXDmp8qlmRAP0hCoBKjU09nzchM5tg6JBuB+vpwJxzZPIYI+bN/R+f7/Sc9wVSmdaQsZRTi5BDp+gY4cTEeYMO/tToYnnp1sJqBuzHQegCuHoyj9Mgn/5w6s63P8/Hg7a3wwsB88FvmnIo9XyKKcSTe65x7TPwDXYb/NW3jP96IzWfRAnuv6DQ65/ccnKxEkxCQzFlFSQqZfkPzOa0OQBqXSU7+1lVe+2jWMstg5+rCS1yMg2lonJmpwaykrC9Shh3Is5ON61RkB1b9OrDJZcqT+XOolyT80tR2xlpDo3x78YtJC0ciYExogqywLfZvGDcIWF/BztWeSMLTtkin9reLSyjAux/0i40uDwS9W43ExXoidHnNTArG0B2hzd58SdRfZw+l+t1SuT2wzJ9+1JI1w4mbDGJ5MuwbM8jIcfvEfFEyTrgkv5lrWWeV8h+uWw7uTnZajpqYGEOo9vjwH+LrwumsuiAeQkKgQOX3aU+eC71LD74ED3XK1EguA2nafBv57VJNgXqrCjDw9Lzokj7Ay/Dy+83NsCgHYLNkxFeAicj4jvIV3BPPf4DfKnj1Stljdk2ezGM6X8DpnRNHTPjbXscLhn50JByAc+w8pT6p1QB70ZJfL8QE7xtNjWDh8jNAy0xv7qCM591oMZXWKPBrGWMKXJvlCW+u0vIPKBZJELtzbnKvgl/P/ujXA/mVMHYaap2p4XZGiiHvt6O0WZfWbsgtAZHGcQoAU+Q/LliVKeUTNIZna9Qb485j8hBIKhF4fDSdPlvLvUlj22EZBGekhHB0yCV3DyeM/MD+0BZy+CPudgnyAKE7+7RNly+wupsVqw671jKufS8CATttar79Ny+/GZ3UUp9TtwC8mb2WyGTElqk3kJXD452uZ0pkkrmQTL6rRxn/ENTY8b3PhOSApvbZM=
X-IPAS-Result: A2EJBQBE6Ttf/zGZrQo2BQEBIoEJgz+CYpZSmxILAQEBAQEBAQEBBwETHAQBAYZvJTgTAgMBAQsBAQEFAQEBAQEGAwEBAQKGRguCNyKEFR04GQE+BT0mAQQbt1WBNIppgTiNOoFCPoERgluFGIYPBI9DjT2ZLwMHgmKaGCqDAI8OjhWNc4RIgW2dUwIEAgQFAhWBaoF7cFCCak8XAg2OKxcUjhCBKwIGCgEBAwmQBIERAQE
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; Tue, 18 Aug 2020 10:46:02 -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; Tue, 18 Aug 2020 10:46:02 -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: AdZ1astAsPab2hBTRSq82YYHXzwVyA==
Date: Tue, 18 Aug 2020 14:46:01 +0000
Message-ID: <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/6F2xsYVJFYy-VDBhC7x8OeiGzXA>
Subject: [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: Tue, 18 Aug 2020 14:46:07 -0000

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?

Scott