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

Jasdip Singh <jasdips@arin.net> Thu, 24 September 2020 16:35 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 EAD843A1075 for <regext@ietfa.amsl.com>; Thu, 24 Sep 2020 09:35:59 -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=unavailable 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 PRSsr-dgTdwX for <regext@ietfa.amsl.com>; Thu, 24 Sep 2020 09:35:58 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:110:201::51]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A233A1068 for <regext@ietf.org>; Thu, 24 Sep 2020 09:35:58 -0700 (PDT)
Received: from CAS01CHA.corp.arin.net (cas01cha.corp.arin.net [10.1.30.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTPS id 6171210757B9; Thu, 24 Sep 2020 12:35:57 -0400 (EDT)
Received: from CAS02CHA.corp.arin.net (10.1.30.63) by CAS01CHA.corp.arin.net (10.1.30.62) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Sep 2020 12:35:36 -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; Thu, 24 Sep 2020 12:35:35 -0400
From: Jasdip Singh <jasdips@arin.net>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, "jgould=40verisign.com@dmarc.ietf.org" <jgould=40verisign.com@dmarc.ietf.org>, "ietf@antoin.nl" <ietf@antoin.nl>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Thread-Index: AQHWjcL4th0h6vwX30+a/gHU++BHfalzfX0AgAAsm4CAAAcigIAElsiA//++BQA=
Date: Thu, 24 Sep 2020 16:35:35 +0000
Message-ID: <45C0CC94-8BED-4939-A5FB-2A302C1FF996@arin.net>
References: <D394EB73-FAA1-42E2-899B-8E188A78411F@antoin.nl> <335D8D72-0A90-4E99-B21E-D5E991D61A96@verisign.com> <d10f32c645454c358f50e043e5ab508b@verisign.com> <C368041A-5CF3-4EE6-9848-9E15F55D6945@verisign.com> <e770a58145ec4c84b0dd769ef86cfe5d@verisign.com>
In-Reply-To: <e770a58145ec4c84b0dd769ef86cfe5d@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: <FD62EB9BAE57964BBF2A1F52B9B7F02A@corp.arin.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/vvlVgGMIUkIGTn_NJjvewbSNtKM>
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: Thu, 24 Sep 2020 16:36:00 -0000

Hello Scott, James.

One thought is if it could be in the RDAP profile doc for the DNRs (https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en). That way no need to update the spec.

Jasdip

On 9/24/20, 12:31 PM, "regext on behalf of Hollenbeck, Scott" <regext-bounces@ietf.org on behalf of shollenbeck=40verisign.com@dmarc.ietf.org> wrote:

    > -----Original Message-----
    > From: Gould, James <jgould=40verisign.com@dmarc.ietf.org>
    > Sent: Monday, September 21, 2020 2:27 PM
    > To: Hollenbeck, Scott <shollenbeck@verisign.com>; ietf@antoin.nl;
    > regext@ietf.org
    > Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
    >
    > Scott,
    >
    > 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.
    
    I'd like to see some discussion of this suggestion, too. What do people think? Is it necessary?
    
    Scott
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext