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

[Mario Loffredo <[e-mail]>]

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] <mailto:[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] <mailto:[e-mail]>
>     A: 	Maurizio Martinelli <[e-mail]>
>     <mailto:[e-mail]>, Mario Loffredo
>     <[e-mail]> <mailto:[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 <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>     _______________________________________________
>     regext mailing list
>     [e-mail] <mailto:[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