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

[Mario Loffredo <[e-mail]>]

Hi Patrick,

your feedback is really welcomed. Better late than never.

My responses to your comments are included below.

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.

> 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. It's 
perfectly unuseful to multiply the field sets as well as

to let the same field sets have different contents.

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.

For the remaining field set, the WG considered that the document wasn't 
the right place to define its content.

> 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 :-(

> PS: the argument in A.1 about the complexity arising out of jCard can "soon"
> become obsolete if draft-loffredo-regext-rdap-jcard-deprecation goes through,
> so maybe some text should have addressed other non jCard cases (or explaining why
> even if jCard is dropped then problems remain)

Yes, it might become but presently it isn't obsolete. Anyway, the 
reasons why the "field set" approach should be preferred  even when 
jCard will be no more supported are reported before section A.1.

So I don't think section A.1 needs to be changed.


I would like the other WG members to manifest their opinions so that I 
could change the document where appropriate.

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: [phone]
Mobile: [phone]
Web: http://www.iit.cnr.it/mario.loffredo
#pleasestayathome