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

Jasdip Singh <jasdips@arin.net> Mon, 05 October 2020 15:21 UTC

Return-Path: <jasdips@arin.net>
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 B9DCE3A0B56 for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 08:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 bYQeE8pv6M1b for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 08:21:40 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [192.136.136.51]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B293A0A6C for <regext@ietf.org>; Mon, 5 Oct 2020 08:21:40 -0700 (PDT)
Received: from CAS02CHA.corp.arin.net (cas02cha.corp.arin.net [10.1.30.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTPS id 2034110757B1; Mon, 5 Oct 2020 11:21:39 -0400 (EDT)
Received: from CAS02CHA.corp.arin.net (10.1.30.63) by CAS02CHA.corp.arin.net (10.1.30.63) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 5 Oct 2020 11:21:10 -0400
Received: from CAS02CHA.corp.arin.net ([fe80::70b5:fa43:96a0:efad]) by CAS02CHA.corp.arin.net ([fe80::70b5:fa43:96a0:efad%17]) with mapi id 15.00.1104.000; Mon, 5 Oct 2020 11:21:10 -0400
From: Jasdip Singh <jasdips@arin.net>
To: "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>, "Hollenbeck, Scott" <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: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Thread-Index: AQHWjcL4th0h6vwX30+a/gHU++BHfamFGQeAgAC5H4CAA4RcAIAABD0A///gKwA=
Date: Mon, 5 Oct 2020 15:21:10 +0000
Message-ID: <17ADAF79-B272-4B47-B140-2A90DC2FEC2E@arin.net>
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> <40E0F905-C073-4B09-AB69-A07A00AC26EB@verisign.com>
In-Reply-To: <40E0F905-C073-4B09-AB69-A07A00AC26EB@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.136.136.37]
Content-Type: text/plain; charset="utf-8"
Content-ID: <26B01AC3B841384A8EAC6050869F74B8@corp.arin.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/w6iv5v1jj7EWww8_BMUFlXKwPGo>
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 15:21:42 -0000

Hi.

Section 5.1 of 7483bis ( https://tools.ietf.org/html/draft-ietf-regext-rfc7483bis-01#section-5.1 ) defines handle as:

  handle -- a string representing a registry-unique identifier of the entity

The phrase 'registry-unique identifier' connotes a unique lookup key for entities, irrespective of their type. It puts the onus on a registry to ensure so. Does that not suffice?

Jasdip

On 10/5/20, 9:15 AM, "regext on behalf of Gould, James" <regext-bounces@ietf.org on behalf of jgould=40verisign.com@dmarc.ietf.org> wrote:

    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>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%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
        
    
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext