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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 05 October 2020 13:00 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 9E84E3A0A08 for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 06:00:28 -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 w9Tq58TTWrzM for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 06:00:27 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.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 07CF13A0A07 for <regext@ietf.org>; Mon, 5 Oct 2020 06:00:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=6176; q=dns/txt; s=VRSN; t=1601902828; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=zxVjPvGt9hvtV8kv3AE8czahVXMKYQ8yeP3lQgpmfDQ=; b=h0CcLvAvny87RKjypyB3AoEjK/5PuShJEHy8sZ4T68upJUbjtllNSEqz OMZ6oX4VD/pkwM5ZKy4uu+Us1W88iOMYI3ub3r1KiYgGBm0bgjo7VE3da rDD+7BkVSgDtj15n3FHYiSGRo6mY8aOgy8Ko4dmmsTH+ERlbxnhkblqnO rUQzaDax61np1pvyNI4P/LTqtxL70WJWFON2SlIz+yBDNUMSiCgPaHytY bV4CjD5pAo3e6LeK38HEQAxGw2p593f+Y2mSEC03EYG2qfrSK2NvWkZOR 8yUAFAbua7awDzDfmqRdXLG+f38PFSq28+cHZbhaKv6bT3Yktcho8pH7i g==;
IronPort-SDR: atqLw3DrBPUWjpV01SdnCIcijGAS9pnQ9127rly0w/JFJIN/zg2HgkcBXr8nCGmqPsNr3fUAHY uvIpuslhuiLupAdq4oELTNMx3GJu92uyiFvii1Dq6wShmjVIA9hiHUe2vmUzqhA4v2bFWc5UD7 0CM0SjYRKUgbs4yo1FnI4WjCNpEQBBM36gbo8SjRRj4VRDu4yyMtl8Dj5xzHC5uszoHl9YzP5I +TZ+Nz34SyXcE6pODzUItDBhODpjcs9WXVhY7ISEPfAnRdZxKAW3fTvxz/Y2oV4jS0Y/eCWHIu M78=
X-IronPort-AV: E=Sophos;i="5.77,338,1596513600"; d="scan'208";a="3067391"
IronPort-PHdr: =?us-ascii?q?9a23=3AIwiFJhzhIAmYt+HXCy+O+j09IxM/srCxBDY+r6?= =?us-ascii?q?Qd0usRKfad9pjvdHbS+e9qxAeQG9mCtLQY0aGL7OjJYi8p2d65qncMcZhBBV?= =?us-ascii?q?cuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx?= =?us-ascii?q?7xKRR6JvjvGo7Vks+7y/2+94fcbglVhjexe7x/IAu5oQjRtMQdnJdvJLs2xh?= =?us-ascii?q?bVuHVDZv5YxXlvJVKdnhb84tm/8Zt++ClOuPwv6tBNX7zic6s3UbJXAjImM3?= =?us-ascii?q?so5MLwrhnMURGP5noHXWoIlBdDHhXI4wv7Xpf1tSv6q/Z91SyHNsD4Ubw4RT?= =?us-ascii?q?Kv5LptRRT1iikIKiQ5/XnXhMJukaxbvByvqR9xw4HWYYGaKPVwcazGcNMGXm?= =?us-ascii?q?VBXNpdWzBdDo6+aYYEEuoPPfxfr4n4v1YCoxmwBQ6oBOPr1DBIgGT50rMm3O?= =?us-ascii?q?QiCQ3NwREuEM4JsHTIsNX5OroZXOeuzKnIyjXDa/dW1in76IfTbB8uvfKMUK?= =?us-ascii?q?luccXP00kvFhjFjlSfqYzjJT+ayuMNs22C4udmSOmghHIppRtrrTiz2scjlJ?= =?us-ascii?q?PJhoQNx13G6Sl0xIg7KcClREN7b9OqEJVduS6eOodqQs0uX2NltDg6x7MJu5?= =?us-ascii?q?O2fSYExZc7yxPBd/GKfJWE7w/+WOuVLzl1gm9udry4hxa360egy+v8W9Go31?= =?us-ascii?q?ZLtSpKjt7MumoR2BzU78iLUvp98Vu71jaJ0QDf8OZEIVo7lafdNpUvwaYwm4?= =?us-ascii?q?IOvUjfBCP6hUf7gaGMekk5+uWl5f7rb7riq5OEKoN4lhvyPrksl8CjG+g0Lw?= =?us-ascii?q?cDUmuB9eih17Du+1DyTq9Qgf0siKbZtYjXJcEcpqGkHQBYyp0j6xOjDze+19?= =?us-ascii?q?QYgGUHIEpFeB2Zi4jpPEnDLe3kA/mnnlijkC9lyf/HMbH9HJnBNGbDn6vmfb?= =?us-ascii?q?Zn805Q0hA8ws1F65JKELEBO/TzVlXtu9zfCx81Kw20w+D5B9Vhzo4SRH6DDr?= =?us-ascii?q?WEPK7Qv1KE/P8jLumCaYMPtzvwL+Ap5/v0gn84nV8dc7Op3ZwSaH2gBfRmI0?= =?us-ascii?q?KZYX7ogtgfF2cFpRQxQ/DpiFCZTz5ceWyyX6Mn5jE6B4KmC53PSZyqgLyExC?= =?us-ascii?q?u7BIFZZnhaClCQFnflb4CEVO0WaCKTJc9tiDgEVb+vS48vzxGhqhL1y718I+?= =?us-ascii?q?rV+y0YqYjv28Rz5+3Jjx0y9CB0BdyH026RV2F0gn8IRzgu0aBwu0N9zkmD0a?= =?us-ascii?q?l+g/FDC9NT4/JJUhwmNZ/T1eB1F9fyWgfZdNeTVFmmWsmmAS02Tt8p2d8BfU?= =?us-ascii?q?l9FMutjxDfxCeqAqEal6CFBJAu9aLcxXfxdI5BzCOM0aA7jl5gRsxBO3eriq?= =?us-ascii?q?lX9gnPQYXPiQOYi+ziIaEVxi/KsmOEw2SUsU1feA9xTePOW2pZZ1eA6Zyz6U?= =?us-ascii?q?rGUb6oIbkjMxBd2YiJLa4AIonmhFFYRfHLNdDfeH6h3Wy3AEDMjvmWYYXna3?= =?us-ascii?q?k13SjBBg4DiQ9ZtSKcOAczFjuJom/CAnppD125MG329uwr4lO8Sks5yQuHZE?= =?us-ascii?q?4ln4G+/QIJz7TIUPMU2rYJvi0soDZcAlun3snXBNzGrA1kKvYPKegh6UtKgD?= =?us-ascii?q?qK/zd2OYatevhv?=
X-IPAS-Result: =?us-ascii?q?A2F3BACpF3tf/zGZrQpggQmBT4MagTQKhDOROZtpPQsBA?= =?us-ascii?q?QEBAQEBAQEIARsUBAEBAoRIAheCIyY3Bg4CAwEBCwEBAQUBAQEBAQYDAQEBA?= =?us-ascii?q?oZFDII3Ins9CT0BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBBAINVEkBHgEBAQEDHQYROhcEAgEIEQQBAQMCJgICAjAVCAgCBAESCIMfq?= =?us-ascii?q?W52gTKKUYEOKoZbhnGBQj6BEYMQPoIjOQKBRyQLgwCCYASQEzaCcIcom2KBC?= =?us-ascii?q?gMHgmeIfoZYiwIrgw6KApQPkg4MeoF5mlyDQQIEAgQFAhWBaoF8cFCCaQlHF?= =?us-ascii?q?wINjisXg06KVnQ3AgYBCQEBAwmNN4ERAQE?=
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, 5 Oct 2020 09:00:24 -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, 5 Oct 2020 09:00:24 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "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: AQHWmPjLfeyhdS9JvkeXoVF1lYwy36mFu7qAgAM/uEA=
Date: Mon, 5 Oct 2020 13:00:24 +0000
Message-ID: <1df4862801334b71a4784ab11bb84f69@verisign.com>
References: <D394EB73-FAA1-42E2-899B-8E188A78411F@antoin.nl> <4A5F8A5D-32E6-4666-898F-23B83C5CDB18@elistx.com> <69c45e88-78fe-8bbf-4ab1-ade50c0ac7a6@iit.cnr.it>
In-Reply-To: <69c45e88-78fe-8bbf-4ab1-ade50c0ac7a6@iit.cnr.it>
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/3kEYuJBsSFS17nbR2ljSwFaFepM>
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, 05 Oct 2020 13:00:29 -0000

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of Mario Loffredo
> Sent: Saturday, October 3, 2020 3:18 AM
> To: James Galvin <galvin@elistx.com>om>; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
>
> Il 02/10/2020 22:15, James Galvin ha scritto:
> > 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/1_AKsyXhtRLN9h4LEAG65owtJMhHrfLUp94HAp7iv6U5KRK_-
> 2Mtzd56Rf4smGoyDJ4eiIqM3a4E73iWsnhGOX4YnFCyWF_xzCaslHxhJOxiqbH
> hiSRwAiyk8mMkECJoYKSlQ1kmb4u3-
> _sD2Be3SyrMHZApsS3iBtbY3MemXbSWSv4c6DFlq8sfMzGMjqy4PQekUbt9Lt
> HcNRfwPHXhN9IFFpecud-xKW8luC4RDIz7jmjeFU9N11h-
> lUPrhogswglEugCXCl95vnmjQ5lqytQ/https%3A%2F%2Fwww.icann.org%2Fre
> sources%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.
> >
> >
> The proposed update seems reasonable to me. However, we don't have to
> make assumptions regarding how handle is generated by RDAP servers. In
> my opinion, the document should simply give guidance to RDAP
> implementers about how to disambiguate cases where overlap may occur.
> Therefore, I would change the sentence as in the following:
>
> OLD
>
> The server SHOULD define a scheme
> for the <handle> parameter to differentiate
>
> NEW
>
> Where overlap may occur, the server SHOULD define a scheme for the
> <handle> parameter to differentiate

I'm still not comfortable with this. If we suggest that the server MUST or SHOULD do something to define a scheme, we leave open the issue of how a client discovers that scheme - and if we add a processing step to discover the scheme, we've changed the protocol from the client's perspective. I still believe that this is an issue best addressed in an implementation profile document and not the protocol specification.

Scott