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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
