Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-partial-response

Mario Loffredo <mario.loffredo@iit.cnr.it> Tue, 28 April 2020 10:13 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 604CD3A1283 for <regext@ietfa.amsl.com>; Tue, 28 Apr 2020 03:13:17 -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 PJ5yBmbilVR6 for <regext@ietfa.amsl.com>; Tue, 28 Apr 2020 03:13:14 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BE03A1284 for <regext@ietf.org>; Tue, 28 Apr 2020 03:13:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 6C4ADB80322; Tue, 28 Apr 2020 12:13:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWseBdGaHObb; Tue, 28 Apr 2020 12:13:07 +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 C9111B801EA; Tue, 28 Apr 2020 12:13:07 +0200 (CEST)
To: Patrick Mevzek <pm@dotandco.com>, regext@ietf.org
References: <CF2EE8CE-DB07-4AFF-84D0-B80BA5E76D39@antoin.nl> <b79a4641-bade-4901-b3f0-bb7decbdb41e@www.fastmail.com> <50276493-87ad-291e-a6cd-ff26fce77868@iit.cnr.it> <9c9a9fa1-db18-4f85-b27a-cb73429d9801@www.fastmail.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
Message-ID: <9e91042e-42b7-7858-0eab-2d67194108f8@iit.cnr.it>
Date: Tue, 28 Apr 2020 12:10:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9c9a9fa1-db18-4f85-b27a-cb73429d9801@www.fastmail.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/UgBmiAngBBEiv16TLWmBtagkK_M>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-partial-response
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: Tue, 28 Apr 2020 10:13:18 -0000

Hi Patrick,

thank you for your quick reply.

My comments are included below.

Il 27/04/2020 17:45, Patrick Mevzek ha scritto:
> Hello Mario,
>
> A quick follow-up that could be a closure in fact, as your answer fills
> the missing points I had.
>
> On Mon, Apr 27, 2020, at 10:30, Mario Loffredo wrote:
>> Il 27/04/2020 07:45, Patrick Mevzek ha scritto:
>>> On Fri, Feb 28, 2020, at 09:43, 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-rdap-partial-response/
>>>>
>>>> This WG last call will end at close of business, Friday, 13 March 2020.
>>> I am too late, I know.
>>>
>>> But anyway I fear that at least the "brief" case will create interoperability
>>> problems, or at least complexity in clients because there is a risk of each
>>> RDAP server thinking of it differently.
>> I published a draft version, namely
>> draft-loffredo-regext-rdap-partial-response-03, including a definition
>> of the "brief" field set which was based on those WHOIS response fields
>> identified in RFC 7485 as mostly supported (i.e. by more than one third
>> of contacted services). As you can see from the "Change Log", that
>> definition was removed in draft-ietf-regext-rdap-partial-response-01
>> because the WG had clearly recommended to separate the technology,
>> described in the RFC, from its operational aspects, described in an RDAP
>> profile.
>>
>> The same feedback was recently provided by Karl Heinz Wolf and now I'm
>> giving you the same answer as I gave him.
>>
>> Anyway, if the WG members reconsider their position about this point, I
>> will be happy to refine my old proposal or work on a new one.
>>
>>> The "subsetting_metadata" is only a SHOULD not a MUST, so clients could
>>> remain completely without real explanations on why "brief" for server A
>>> is different from "brief" result for server B.
>> It's not a MUST because the available field sets could be defined in a
>> document published elsewhere, for example, in a specific RDAP profile.
>>
>> Therefore, in my opinion, it would be recommended but not required.
> I agree with all the above, in theory.
> My main fear is once the draft being put into active use, I am not sure people
> will bother creating other proper IETF documentation on what "brief" is,
> and hence the pretty much result I see coming is multiple servers using "brief"
> in completely different senses, without always to use the metadata, and hence clients
> will need again to hardcode on their side assumptions per server, which is very
> bad for interoperability.
>
> I do however profoundly disagree with:
>
>> because the WG had clearly recommended to separate the technology,
>> described in the RFC, from its operational aspects, described in an RDAP
>> profile.
> As this argument is used when wanted but not always. At the same time, we (the WG)
> see no problem (but I do) to define a BCP on "secure transfers", which is certainly
> just operational stuff and not protocol stuff, so sometimes we do hardcode operational
> stuff in WG documents. So we should either do it always, or never, but using that
> argument only in some case and not others is not something I find good process.
> That is just my generic view, nothing specific to the one draft discussed in this thread.

My humble opinion is that the definition of the "brief" field set would 
have made the document self-contained. I think we could start from the 
outcomes of RFC7485 to converge to a minimal set of recommended fields.

Anyway, I respected the WG decisions. Ubi major minor cessat!

>>> It would have been nice to provide a template for "brief", at least a SHOULD,
>>> per objects described in the RDAP RFCs.
>> See my response above.
>>> Specially since the document has this text:
>>> "the
>>>      name, as well as the list of fields for each field set, should be
>>>      shared by most of RDAP providers."
>> Obviously, the field set approach is valuable if there is a wide
>> consensus on both the name and the content of a possible field set.
> I agree, but I am not sure there is such consensus. Or even if there is here
> on the mailing-list how can be sure there will be among all RDAP servers working?

Sometimes it happens that a software artifact becomes a de-facto 
standard because it is largely shared by most of implementers. For 
example, a possible brief field set defined in the gTLD RDAP profile 
would affect 80% of RDAP providers.

This could be a similar situation.

>
>> Three possible field set names have been recommended in the document in
>> order to ease interoperability. For the field sets representing the two
>> extremes, namely "id" and "full", the corresponding content is evident.
> Yes, clearly my worries are about "brief".
>
>>> Written like that, this is not a protocol specification, and does not even
>>> give tools at the protocol level to enforce that.
>>>
>>> Or, and this could be an easy solution, another draft defining rdapConformance
>>> subsetting_brief_level_0
>>> should define exactly what is brief and then servers are free to properly
>>> signal if they adhere to this definition of fields or not.
>>> There could be multiple drafts in fact for multiple definitions.
>> This is an interesting solution but I dont' see, at least in the case of
>> "brief",  why the WG should approve to define in a separate draft what
>> has been considered unsuitable in this draft :-(
> Understood. I am probably once again possibly at odd's with the WG but it is not
> something unheard of already :-)
> So anyway, I believe we will see problems in the future, but we will have to wait
> and see them I guess.
>
>> I would like the other WG members to manifest their opinions so that I
>> could change the document where appropriate.
> As you said, the issue I raised was already discussed and settled so probably
> no need to rehash it, I was the one being late here, I should have taken
> more attention to the previous discussion, but I was not able to reserve
> the time I wanted to participate in this WG lately, sorry about that.
> So no need to spend energy on my late points.

Hope you can contribute more actively to other RDAP drafts still in 
progress.

Thanks again.

Best,

Mario

-- 
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
#pleasestayathome