Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-partial-response-04.txt

[Karl Heinz Wolf <[e-mail]>]

Hi Mario,


thanks for your clarifications. Having more definitions in RDAP profiles
makes sense to me.



Best,

Karl Heinz

On Tue, Jan 21, 2020 at 12:33 PM Mario Loffredo <[e-mail]>
wrote:

> Hi Karl Heinz,
>
> thanks a lot for your review.
>
> My comments are inline.
> Il 21/01/2020 08:40, Karl Heinz Wolf ha scritto:
>
> Mario,
>
>
>
> Here is my feedback regarding this draft:
>
>
>
> I think it is useful for clients to request a partial response as
> described in this draft.
>
>
>
> Chapter 2:
>
> The discussions of the different approaches to partial response, which I
> guess led to the decision of the WG to go for field sets, should be
> probably moved to some kind of appendix to not confuse the reader.
>
> ML: This section aimed to explain the reasons supporting the "field set"
> approach. Anyway, I have no problem to move it elsewhere in the document.
>
> However, it is interesting to read about the reasons and two comments on
> this chapter: it says "the request of some fields might not match the user
> access levels." You might also run into this when the request contains a
> field set that is not allowed for this user (this is also admitted in
> chapter 5) – so that is probably no advantage.
>
> ML: The "subsetting_metadata" element enables the server to provide the
> user with the allowable field sets.  A similar element could contain the
> allowable response fields which could be explicitly selected in a request
> but its implementation results in a more verbose content and is unpractical
> due to the fact that the RDAP response is not flat.
>
> In addition, the user can request for either an allowed or an unallowed
> field set so the management of error responses is easier than dealing with
> a mix of allowed-unallowed fields.
>
> Furthermore, you state that interoperability is facilitated with
> pre-defined filed sets while there is no exact definition of all field
> sets.
>
>
>
> ML: See the comment to the feedback below.
>
> Chapter 5:
>
> I noticed that older version of this draft had a more detailed description
> of the "brief" dataset, which is now removed. Do you think
> interoperability, as written in chapter 2, is still achievable?
>
> ML: Based on the outcomes of the analysis described in RFC 7485, I have
> defined a possible list of elements for a "brief" response but the WG
> clearly recommended to keep it out of the scope of the document in order to
> separate the technology, to be described in a RFC, from its operational
> aspects, to be described in an RDAP profile. The goal of Section 5 is only
> to propose some potential examples of field sets.
>
> I don't think that, in this way, interoperability could be limited. If,
> for example, the gTLD RDAP profile included some field sets, almost 50% of
> potential RDAP servers would be involved.
>
> And since server operators can add their own field sets: do they need to
> be registered somewhere or just be announced in the metadata with its human
> readable description of which fields are going to be returned?
>
>
>
> ML: I believe that, according to HATEOAS principles, a REST API should be
> as self-descriptive as possible. Obviously, an RDAP operator can add a
> "describedby" link in the "subsetting_metadata" element to furtherly
> describe the implemented field sets in a more exhaustive document.
>
> Is the "full" field set really required (and what is the difference of a
> response with the "full" field set and an response without this extension?
>
>
>
> ML: It depends on the field set the server provides as the default one.
> The default field set is applied when no field set is requested but it
> could be different from the "full" response.  In theory, the default field
> set should contain the information which is considered relevant in the
> majority (70-80%) of the requests which, in my experience, doesn't
> correspond to a full RDAP response regardless of the user access level.
> Anyway, this information as well as both the list of allowed field sets and
> the elements included in each field set should be defined in a profile.
>
> Cheers,
>
> Mario
>
> Best,
>
> Karl
>
> On Mon, Sep 2, 2019 at 11:31 AM Mario Loffredo <[e-mail]>
> wrote:
>
>> Hi all,
>>
>> this new version extends a review by Tom Harrison about including a
>> "self" link in the "id" field set. Now the draft recommends the RDAP
>> providers to include a "self" link in any field set other than the full
>> response.
>>
>> Thanks a lot Tom for your review.
>>
>> Best,
>>
>> mario
>>
>>
>> -------- Messaggio Inoltrato --------
>> Oggetto: New Version Notification for
>> draft-ietf-regext-rdap-partial-response-04.txt
>> Data: Mon, 02 Sep 2019 02:24:21 -0700
>> Mittente: [e-mail]
>> A: Maurizio Martinelli <[e-mail]>
>> <[e-mail]>, Mario Loffredo
>> <[e-mail]> <[e-mail]>
>>
>>
>> A new version of I-D, draft-ietf-regext-rdap-partial-response-04.txt
>> has been successfully submitted by Mario Loffredo and posted to the
>> IETF repository.
>>
>> Name: draft-ietf-regext-rdap-partial-response
>> Revision: 04
>> Title: Registration Data Access Protocol (RDAP) Partial Response
>> Document date: 2019-09-02
>> Group: regext
>> Pages: 13
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-regext-rdap-partial-response-04.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/
>> Htmlized:
>> https://tools.ietf.org/html/draft-ietf-regext-rdap-partial-response-04
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-partial-response
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-partial-response-04
>>
>> Abstract:
>> The Registration Data Access Protocol (RDAP) does not include
>> capabilities to request partial responses. In fact, according to the
>> user authorization, the server can only return full responses. A
>> partial response capability, especially in the case of search
>> queries, could bring benefits to both clients and servers. This
>> document describes an RDAP query extension that allows clients to
>> specify their preference for obtaining a partial response.
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> regext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/regext
>>
> --
> Dr. Mario Loffredo
> Servizi Internet e Sviluppo Tecnologico
> CNR - Istituto di Informatica e Telematica
> via G. Moruzzi 1, I-56124 PISA, Italy
> E-Mail: [e-mail]
> Phone: [phone]
> Mobile: [phone]
> Web: http://www.iit.cnr.it/mario.loffredo
>
>