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

Mario Loffredo <mario.loffredo@iit.cnr.it> Sat, 03 October 2020 07:21 UTC

Return-Path: <mario.loffredo@iit.cnr.it>
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 D7D433A07DE for <regext@ietfa.amsl.com>; Sat, 3 Oct 2020 00:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Level:
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 vV16ZLlOKQ2F for <regext@ietfa.amsl.com>; Sat, 3 Oct 2020 00:21:23 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx3.iit.cnr.it [146.48.98.150]) by ietfa.amsl.com (Postfix) with ESMTP id 9C32F3A044E for <regext@ietf.org>; Sat, 3 Oct 2020 00:21:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 7AD87600495; Sat, 3 Oct 2020 09:21:20 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx3.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx3.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id devvY3lOkzpD; Sat, 3 Oct 2020 09:21:17 +0200 (CEST)
Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id BA1EF600172; Sat, 3 Oct 2020 09:21:16 +0200 (CEST)
To: James Galvin <galvin@elistx.com>, regext@ietf.org
References: <D394EB73-FAA1-42E2-899B-8E188A78411F@antoin.nl> <4A5F8A5D-32E6-4666-898F-23B83C5CDB18@elistx.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
Message-ID: <69c45e88-78fe-8bbf-4ab1-ade50c0ac7a6@iit.cnr.it>
Date: Sat, 3 Oct 2020 09:17:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <4A5F8A5D-32E6-4666-898F-23B83C5CDB18@elistx.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: it
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/B5DPQb4XjYJHRjEpj87uE9p28vM>
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: Sat, 03 Oct 2020 07:21:26 -0000

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://www.icann.org/resources/pages/rdap-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


Best,

Mario

>
> Thanks!
>
> Antoin and Jim
>
>
>
>
>
> On 18 Sep 2020, at 9:52, Antoin Verschuren wrote:
>
>> The following working group document is believed to be ready for 
>> submission to the IESG for publication as a standards track document:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/
>>
>> This WG last call will end at close of business, Friday, 2 October 2020.
>>
>> Please review this document and indicate your support (a simple “+1” 
>> is sufficient) or concerns with the publication of this document by 
>> replying to this message on the list.
>>
>> The document shepherd for this document is Mario Loffredo.
>>
>> Regards,
>>
>> Jim and Antoin
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> regext mailing list
>> regext@ietf.org
>> https://www.ietf.org/mailman/listinfo/regext
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo