Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 12 October 2020 15:09 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 498383A1564 for <regext@ietfa.amsl.com>; Mon, 12 Oct 2020 08:09:43 -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 RSiZIArC9FSk for <regext@ietfa.amsl.com>; Mon, 12 Oct 2020 08:09:41 -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 8C93F3A1560 for <regext@ietf.org>; Mon, 12 Oct 2020 08:09:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4672; q=dns/txt; s=VRSN; t=1602515382; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=XIVEOdUgfzNC1d92NnOlrV0FIisvDXk8l9L20ruvIvE=; b=lcYfSPharf8r32cMxSfGtGVaHMp4p/p7JFfXQZqZpTQZMAB3CtpZvuO9 TcEvLBIHvBI01CKUCJRTusVhsGoQPlZGKeRnVefaNCXtMkovLZcci5fkA Sh2dMxW10VJd+qLwkMAbKHUGXmG2b0mbgl7nfbrDa/ohOGHadyEBNPH4J RYVuQAK1ZlaZ4uBrvVCa4Q3ypcM24uHOajGzaF+J/sbZchVLSBMmFpouN kvCWSiCR5ZB+rMXGHBn5iCt3WZ7F6k+vOXbhyFqxK4uJ07118bpii1UrW RN3VDfbOBBwR+Jqjs8/mzskFJJFfc/a1wk+Po+bU4dK4iDo/EQ7GHptdz Q==;
IronPort-SDR: lqoMDWZiYph1+MX8dtP/hubr4R5mxTLqCJlxkQd2jPWltAHHvUIa1UWm1H4al7TlIM1PdvRpTb /SJ2xXNBnOOqRW7L+2c9/hx1StlM2cMi75i72CW6liZq0MSiFUyYyROr4Z38PlV0YnUQIIMZv5 OdWrnyaLa1wHsFJ4fvvENnRBkTYHLy1QlZd0vM4YqOmoyf5NvQBKEaUaM5CWt+auV/FJD6fgi6 nT7BitbGWl0Zc4K4JO7gufVIAgVqXdSZY09FEoimCCly/ueZt0f/HlLZ5LYlQ3ckr2umGha5A7 7WM=
X-IronPort-AV: E=Sophos;i="5.77,367,1596499200"; d="scan'208";a="3508064"
IronPort-PHdr: 9a23:Eq/0VBUTS9gpCTsRhJflK8Fri0zV8LGtZVwlr6E/grcLSJyIuqrYZRSCvadThVPEFb/W9+hDw7KP9fy5Bipdvt3e4DgrS99lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUhrwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrrwjdrMkbjIltJqszyRbCv2dFdflRyW50P1yYggzy5t23/J5t8iRQv+wu+stdWqjkfKo2UKJVAi0+P286+MPkux/DTRCS5nQHSWUZjgBIAwne4x7kWJr6rzb3ufB82CmeOs32UKw0VDG/5KplVBPklCEKPCM//WrKiMJ/kbhbrQqhqRJh3oDUfI+bOvlwfqzffNMVWWVPUclKWixdGYy8bZcDA/YdMetaqYT2ulsArQG5BQmpHO7jxD1Ghnjy3a0+zeshFxrJ0xI8ENINqHjfscj7O7sVUeCp0KnEwyjIYvRN2Tf974jIdhQhru+KXb1rb8Xe1UovGhjbjlqOs4zlPiiV1uUCs2id9eZvSeWvi2s+pgx3vzOgydsihJPTiYIJ1lDL6z95wIAtKNC6VEJ2ZdCqHIZNuyyaOYZ4Qs0vTW5stSomyrMKpZy2cDYKxZooxRPSavKJfouU7h/9SOucLip0iW94dL+7iRi/91WrxOP7VsmxyllKryxFn8HQuXAMzBzc9s+HRuFh8Uem3DaDzwHT5f1eLkAyk6rXMZkhwqQ/lpcVrE/NHTf2lV3rgKOKbEko5+ql5ur9brn7ppKROZV4hw79P6g2h8CzHf40PhUMUmSH4+iwybLu8E7jTLlXjfA7lLTSvorAKsQBvKG5BhdY0oMk6xmiETiryM8YnXwbLFJdfxKHkpTpN0nOIP/mCfe/hEyhnSp3yf7eI7HuAo3DIHfCn7v9YLpx8VBcxxY0zdBF/5JYEKsOL+/pVk/vrtzYFRk5PxaozObgDdVxzoIeWWSRDa+FKK7erEOE6vgyL+SOaoIZoivxJvgr6vL0gnI0mkcRfayz0psWbHC4EO5mI0KcYXf0mdcBEWAKvg46TOP0jl2NSiBcaGqxX68n+DE0FpimDYbYRoCsj7yB2j23EYFRZmBDElyMC2vnd52YW/cQbyKfOsBhnSYAVbi/So8h0wqjuxH+y7pmNerU5iIZuYj/29hy4u3ZjQsy+iBsD8SBz2GNSHl5nnkWSD85wq9+rlB9x0yC0admn/xYG8Zf5/RTUgc1ZtbgyLkwBNn2RAPHVtqNSU26UpOtBjR7BoY+ytsQYkBVFtGjlQzTmSGtBulR3/aRCZM54r703nXtKYB60XmMnP07glYrUtdnNGC6iOh47QeFVKDTlEDM3YatcaAR2iTA/2THhVGFu11EGkYkSqXCWXQSYEHbptfR+E7YTqSvBrJhOQxEn53RYpBWY8Hk2A0VDMzoP87TNjq8
X-IPAS-Result: A2F3BAAfcYRf/zCZrQpggQmBT4MagTQKhDORGptpPQsBAQEBAQEBAQEIAR8QBAEBAoRIAheCASY3Bg4CAwEBCwEBAQUBAQEBAQYDAQEBAoZFDII3Ins9CT0BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBAINVEkBHgEBAQEDHQYROhcEAgEIEQQBAQMCJgICAjAVCAgCBAESCIMfgwumTXaBMoQ7AYEYhGYGgQ4qhmCGcYFCPoERgxA+glwCgUeDL4JgBJAgNoJwhyybZIEKAweCaIkBhlqLBSuDFYoIlB2SGwx7gXuIdpFyg0ICBAIEBQIVgWqBfHBQgmlQFwINjisXg06KVnQNKgIGAQkBAQMJjTeBEQEB
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 12 Oct 2020 11:09: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.1979.003; Mon, 12 Oct 2020 11:09:39 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "galvin@elistx.com" <galvin@elistx.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Thread-Index: AQHWmPjLfeyhdS9JvkeXoVF1lYwy36mUIRUA
Date: Mon, 12 Oct 2020 15:09:39 +0000
Message-ID: <5eb56fa9e9f94347ae613e26d8a2fd62@verisign.com>
References: <D394EB73-FAA1-42E2-899B-8E188A78411F@antoin.nl> <4A5F8A5D-32E6-4666-898F-23B83C5CDB18@elistx.com>
In-Reply-To: <4A5F8A5D-32E6-4666-898F-23B83C5CDB18@elistx.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/TZm4gHC4cL2ne9J63Bgbmg1976c>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
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, 12 Oct 2020 15:09:43 -0000

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of James Galvin
> Sent: Friday, October 2, 2020 4:15 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
> The WGLC for this document was scheduled to end today.  While there is
> support to move the document forward there is one minor comment that
> has been raised during the last call.
>
> The chairs would like to hear from other working group members as to what
> to do with this comment.  Rather than close the last call and risk another last
> call, we are extending this last call for another week.  If we can come to a
> consensus as to how to proceed before the end of last call than the
> document can stay on track to be submitted to the IESG after the last call.
>
> The WG last call will end at close of business on Friday, 9 October 2020.
>
>
> Here are the comments as seen on the mailing list.  Please respond with
> your suggestions regarding these two comments.
>
>
> James Gould:
>
> Yes, lumping the registrar object with the contact object under a single
> RDAP entity object interface is the rub.  We solved the problem in the
> RDAP Profile, by supporting entity lookup by IANA ID (number) and
> registrar name (string) for the registrar objects, and by ROID
> (“((\w|_){1,80}-\w{1,8}") for the contact objects.  Where there is
> overlap, which is registrar name (string) and ROID
> ((“((\w|_){1,80}-\w{1,8}") the contact takes precedence.  My
> recommendation is to provide guidance in the section 3.1.5 "Entity Path
> Segment Specification" for this real world case:
>
> The <handle> parameter represents an entity (such as a contact,
> registrant, or registrar) identifier whose syntax is specific to the
> registration provider.  For example, for some DNRs, contact
> identifiers are specified in [RFC5730] and [RFC5733], and
> registrar identifiers are specified using the IANA Registrar ID
> assigned by ICANN.  The server SHOULD define a scheme
> for the <handle> parameter to differentiate between the
> supported entity object types (e.g., contact and registrar),
> such as using different <handle> formats, using a <handle>
> precedence order, or a combination of formats and precedence
> order.
>
> The SHOULD could be a MUST, but the point is to provide guidance to
> implementers of the protocol.
>
> Two responses have been offered:
>
> Jasdip Singh response:
>
> One thought is if it could be in the RDAP profile doc for the DNRs
> (https://secure-web.cisco.com/1k4lL-
> ZaH_4UTeAlExqEDmWoj2i2M2JCucgN0US-
> ZRaw3P13LwsVyTwARJxQoKgUo1ceNGMGoZaum_o86c9qFXMK28e6HYprdo
> vBXG6JQKzs1SqqT5mQ_VEnMihHl3qiwMkTQ8qPKkPpbqOJbRIDs_UDppLFz2
> yhs97pm3Ssnh2DxotUzdWsgbWlESVZbLzMg5Z-
> ZTHevue2cVlwSwhdDlzQiyDBU4e0y9cLgcwXSXX7tJE5mUh04ocHwUI2Kcpqccf
> u_lM-
> d8029rv314sSAKQ/https%3A%2F%2Fwww.icann.org%2Fresources%2Fpages
> %2Frdap-operational-profile-2016-07-26-en).
> That way no need to update the spec.
>
> James Gould response:
>
> The RDAP Profile is dependent on the RFC, so I wouldn't create a
> circular dependency.  My recommendation is to take the lessons learned
> in implementing the RFC and provide guidance on how to handle it in the
> RFC directly.

[SAH] I don't think we reached consensus to change anything in the draft, so I left this one alone.

Scott