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

"Gould, James" <jgould@verisign.com> Mon, 05 October 2020 13:15 UTC

Return-Path: <jgould@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 EC9913A0A25 for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 06:15:38 -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=unavailable 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 BUh8aCKxaU52 for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 06:15:36 -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 6BD913A0A24 for <regext@ietf.org>; Mon, 5 Oct 2020 06:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9434; q=dns/txt; s=VRSN; t=1601903737; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=ius/uoTU6W9umdF4JQijSvCEEcQOG21hQFBlYSrWwh0=; b=CWS1Z+xnYbOv7uz1h4Y0susR8UahwKylS6NW0BUYvLeO2Ld4mhYUdD0p K61GZukB8uBHYum6IVbzKEF3swIiXk63DwYZ51282H0dPcc3FtBeZpr3b 4RC+m+CBLo2txnW5oqOfE9XEcJbr7RVzYrCkhKZHnZR87WKsbChr2a8Ec 0LiiA8MRkZ3mQxDYjOkGXsUbSHz/m2N1tq5zFxZxUJ/VAwkge3qc2B/jJ 2QcciA/BZ8TEIUtiNwqEr/d5LMwiM7gE2vRraTDsp4n2eYyhgaWhXbOBW GgAjIx/lQDxP1hM/AKr7qn35qmZkD5jfWlDeYpKVqFYCoFePOVZhbhyXb w==;
IronPort-SDR: YznYxgkaFvufaQJmlJEFXYwQiCF9rXtzQmVzlxZ+Y26GkSTfK24ijM6EE9qiSjSfrF3DvbPVnD dZEiwQDaLCLW8XxsfoTsLX5gWeZHjw4Q9schnfVyrh6KRSza5nFPFvJWQ1Vb8wQ9Va4iKG6EDd 001lfWNW+T9ZYCdpij3p8cADZ13nKDTmRXdqgH2giuUAoSLcX8dvN3VG9FJl8oEEtTLtdbNHmn 28D78HTx+6BOPrXNnAF6c5ByAu2L9M3oMBAOSFfIFRDtvCS29aPqwG9NDMvy1t64lZ0VDu23an ARU=
X-IronPort-AV: E=Sophos;i="5.77,338,1596499200"; d="scan'208";a="3414334"
IronPort-PHdr: 9a23:NGAN5B9O5+EvAf9uRHKM819IXTAuvvDOBiVQ1KB+0O0UIJqq85mqBkHD//Il1AaPAdyEra4ewLSO+4nbGkU4qa6bt34DdJEeHzQksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1Ov71GonPhMiryuy+4ZLebxhKiTanbr5+Mhq6oATNusILnYZsN6E9xwfTrHBVYepW32RoJVySnxb4+Mi9+YNo/jpTtfw86cNOSL32cKskQ7NWCjQmKH0169bwtRbfVwuP52ATXXsQnxFVHgXK9hD6XpP2sivnqupw3TSRMMPqQbwoXzmp8qFmQwLqhigaLT406GHZhNJtgqJHrhyvpBJ/zIzab4GUKPVwcazScMgGRWVaW8ZdSzBND5m+YoYJEuEPPfxYr474p1YWoxewBA6sBP7ryjBVnnP9wKk03P4kEQ7YxwwsEc8FvXPWrNX6M6cSTOS1w7TTwDXdcfxWwzb96JPJchAup/GAR65/cc3UyUQ2EQ7Ok1qfp5D/MTyPyuQNr3aU7/BmVe+3j2MrtRx9rzqhy8owiYTFmJwZx1TY+Ch2wYs7JcC0RUF4bNO4E5ZdtiKXOYR3T84sQGxltjs3xLMatZO7YCUG1JIqzAPRZfyAdoiH+BPjVOCJLDdmmn1lYrO/hw2z8UivzO38V8+030pQoiVZldnMs2gB2ADS6sicVvR9+V2t1iqI1wDW8u1EIFw7mrDdK54n2LIwkYATsUvbEi/3hkr2kKGWel8j+uiy5OTqZKjtqJyEN4Jslw3yLr4iltG9DOk2KAQCQmiW9Oqm2LDs/kD1WKhGguEsnqXEsp3WOd4XqrO2DgJWyIov9hWyAjG729oCh3YHNkhKeBefgojsPFHBPe73AO+kg1SpjDdr3/fGPqD9ApnVLnjMjrPhfbFl5kNB1AQ91c1T6JJMBL8OIf3/RlL9uMbGDhAlNAy02f7nBM9n2YwDQ26PHLWZMLjUsVOS+u0vJOyMaJcUuDb7Nfcl++bjgWIllVMHYKWk35UaZGqlEvlmLUiVe3Xhj9QZHWcPpAU+TejqiFOYUT5UYna/R6A85j48CIK7CYfMW5uggKKf0yehH51WfWFGCl+KEXvya4qEXPIMZDqIIsB9ijwESaShS4g52BG1tA/6zL5nLu7K9S0erp3sysR65+7LmBw96TB0EdqS03uMT2Fvn2MISDk20Lpjrkx6z1eOyrV3g/lCGtxJ+/xFSAY6OoDAz+x0EdzyXRjBftiRQla8XtqmGS0xTs42w9IWZkZyAc+ijhHE3yawB78VkLKLBJIu8q3CwnfxIN1wy3fH1Kk9lVUpXs1PNXe8iq5+6wjZH5TJnFmBl6a2aaQc2zbA9GiZwmqKokFYUQhwXL7bUnAbZ0vWtsj550zYQ7CyDrQnNxNLydSeJatSdt3pkVJGSe/5ONvAbGK+hWixBQqTy7ONcoXqZ2sd0D/aCEgenABAtUqBYEIlBiClp2/YBjFlFgezO13h6+hlqXy9CEQzyimGakR73Py09wIbw/uGRLlbiqkEvyMlpjN+EV2+io6OFdeaphFgc6MaatQ4yFtC3HjS8Q1wIpLmKLpt0BpWOQF+pULpkRFwBItanMQthHIr0Ex5L7je0U8LP2ed1IrxPfvTLWf85h2jbIbX202Y29CMvKYTvrBw4VrquB+oEGIv93R8z8kT2HyZrN2eAwMWT5P3eksz9gNmt/fRZSxro8uez3BjPLmomj7Px9xvA/EqgF70ZdpQPbOYPA7/D8NcANKhfr8EgV+sO1grO/1W+Op8HcqjeuDMkPqpM+F9mD6Ok2ld4Zt83UTK/C15HL2bl60Zyu2Vi1PUHwz3i02s55j6
X-IPAS-Result: A2F9BAB8G3tf/zCZrQpdA4EJgU+DGoE0CoQzkTiDepdvFyYLAQEBAQEBAQEBCAEfEAQBAQKESAIXgiMmNwYOAgMBAQsBAQEFAQEBAQEGAwEBAQKGRQyCNyJ7PQk9AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQQCCAUCTQUCRwEeAQEBAQIBHQYROhcEAgEIEQQBAQMCJgICAjAVCAgCBAESgyYBglynGnaBMopVgQ4qhluGcYFCPoERJxyCTT6CIzkCAoFFJAsKJoJQM4ItBJATNoJwhyibYoEKAweCZ4h+hliLDh+DDoEoiFqUD5IODHqBeYcAEoFjkWeDQQIEAgQFAhWBaoF8cBU7KgGCPglHFwINjisXg06KVnQCDCYDAgYBCQEBAwmNN4ERAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) 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, 5 Oct 2020 09:15:34 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.1979.003; Mon, 5 Oct 2020 09:15:34 -0400
From: "Gould, James" <jgould@verisign.com>
To: "shollenbeck=40verisign.com@dmarc.ietf.org" <shollenbeck=40verisign.com@dmarc.ietf.org>, "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: AQHWmPjLes1mluvql0CMj6FOQNb2JamFu7qAgAOEXAD//8EvAA==
Date: Mon, 05 Oct 2020 13:15:34 +0000
Message-ID: <40E0F905-C073-4B09-AB69-A07A00AC26EB@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> <1df4862801334b71a4784ab11bb84f69@verisign.com>
In-Reply-To: <1df4862801334b71a4784ab11bb84f69@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.16.200509
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9AE2036047C38B48AFC8258ED1C5B1B8@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/N3FvH--SNFUE2mi8730pEmI9BW8>
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:15:39 -0000

Scott,

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

I believe that providing guidance in the protocol to the real-world overlapping of entity handles (contact and registrar) as necessary.  The protocol would have explicit language on how to handle the case of overlapping entity handles.  A discovery mechanism is not needed, since we didn't have a need to create one based on the approach taken.  

-- 
 
JG



James Gould
Fellow Engineer
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 10/5/20, 9:00 AM, "regext on behalf of Hollenbeck, Scott" <regext-bounces@ietf.org on behalf of shollenbeck=40verisign.com@dmarc.ietf.org> wrote:

    > -----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>; 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%2Fhttp://secure-web.cisco.com/1KzaMJBYCbHehlcyM7qgPzBHHaQvr1dOBGVjKZpsDWq867Y5KK33Xpj7gO1ijGMStZiT2-3TBK7ej3U5yYTxNbvIluknka0M48pQzXdUZwKvNgHeKhpieimICcERv8ytTgpOTh6oH_p_deFEo_xT15mJU5eJufBCSCEnu_AQMtR3VgaaURwLueY0Bw-Am4T5mb12dNiJHS_Uy6RpnXYUflqWBeQ0NCXczhOd7XkXyO62Kk1SHZ5UHdFFWrOFdBbuRuOkpX8FDJHhiWXx2xy2thQ/http%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
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://secure-web.cisco.com/14qQ5GBAbqizg1W93npsiyV-qaIPAEr0IPtYJq1e7X-_7EoaNxVfB1TEiGzncUFjJiWvcnx6HykFwrZ-ABrD6xiCsFOMEGvVa2nDcW_IEtcp3Kp7hIrt7QPfU1p8toWJrW6Cam0kzs62ESNznCXJSwbu2i9LvV_B2lJ_5iFZL_W3yetKjwXg0uiEC8RQ26Ce90KoEXMuk-nZ5uY-UUHWe1MXXF9N0PIwrFts920hzq-qzWa1SHCEGSw3o0Odax04AFTW15t-zXQUXQWTY0UPnWd5ve9mRKR1zu3ao84TP6yA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext