Subject: Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-05.txt

From: Patrick Mevzek <[email-masked]>
Date: Tue, 12 Dec 2017 05:34:06 +0100

Hi Scott,

On Tue, Oct 24, 2017, at 14:04, Hollenbeck, Scott wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> >         Title           : Registration Data Access Protocol (RDAP) Object
> > Tagging

One comment on the draft itself.
While I think I can understand the need, I still feel very uneasy by the
solution of tackling two values together by a given separator.
In fact it shows even in the history of the document, where you had to
change the separator multiple times.

Even beside the fact that tilde looks like a dash inferior lookalike, I
think that you would get problems whatever separator value is used. This
shows in many sentences of the text.

Were other solutions already explored?

Like one the following two:
- instead of adding the service provider to the current handle, why not
having a new RDAP attribute, like handle_provider to store only this
value?
- or, even more radical, having the current handle element not a string
anymore but a dictionary/map with one or two keys, like value
(mandatory, would be the current text in the element) and provider
(optional).

Obviously these 2 solutions involve schema changes so are more difficult
to put in place,
but I see them are more future-proof.

Sorry if I'm late to the game and I revisit already rehashed grounds.

Regards,

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 12 Dec 2017 12:19:17 +0000

> -----Original Message-----
> From: regext [mailto:[email-masked]] On Behalf Of Patrick Mevzek
> Sent: Monday, December 11, 2017 11:34 PM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-
> rdap-object-tag-05.txt
>
> Hi Scott,
>

Thanks for the comments, Patrick.

I changed the character more than once only because we were trying to find one that was guaranteed (more or less) to not be part of the values currently in use. At least one of my earlier proposals was, in fact, a collision. As noted in the text, the concept described in the document is already implemented by multiple registries and is based on current RIR practice. It's not new.

No, I didn't consider other solutions because I thought the existing RIR practice would work just fine because it's working just fine right now.

> anymore but a dictionary/map with one or two keys, like value (mandatory,
> would be the current text in the element) and provider (optional).
>
> to put in place, but I see them are more future-proof.

As you said, both are more radical and thus probably more than we need. I'm just trying to find a simple way to add structure to an identifier so that queries can be bootstrapped in the same way other RDAP queries can be bootstrapped.

Scott

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 13 Dec 2017 04:21:28 +0100

On Tue, Dec 12, 2017, at 13:19, Hollenbeck, Scott wrote:
> I'm just trying to find a simple way to add structure to an identifier 

I agree, but I believe we have the JSON format to encode structure and
hence putting two loosely related items in a string with some separator
goes in my mind contrary to the idea of using JSON and departing from
all errors that were made with the whois format.

If this documents the current practice then it is what it is, but I
would be sad this becomes the canonical way to do this in the future.

I understand that it is too late to change anything, but I just wanted
to voice my concerns.

-- 
  Patrick Mevzek

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 13 Dec 2017 12:09:31 +0000

> Sent: Tuesday, December 12, 2017 10:21 PM
> To: [email-masked]
> goes in my mind contrary to the idea of using JSON and departing from all
> errors that were made with the whois format.

Think about this, though, Patrick: what the document describes is essentially how bootstrapping for domain name queries works, too. The only difference is that the separator is a "." and the operator identifiers are top-level domains.

Scott

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 13 Dec 2017 14:08:38 +0100

> Think about this, though, Patrick: what the document describes is
> essentially how bootstrapping for domain name queries works, too. The
> only difference is that the separator is a "." and the operator
> identifiers are top-level domains.

But in your case the domains are not into some kind of structured format
like JSON.
Where on the opposite, inside RDAP we have the luxury of the JSON
structure.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Andrew Newton" <[email-masked]>
Date: Wed, 13 Dec 2017 13:27:28 +0000

------ Original Message ------
From: "Patrick Mevzek" <[email-masked]>
To: [email-masked]
Sent: 12/13/2017 8:08:38 AM
Subject: Re: [regext] FW: I-D Action: 
draft-hollenbeck-regext-rdap-object-tag-05.txt

>Where on the opposite, inside RDAP we have the luxury of the JSON

Patrick,

Thanks for starting this conversation. I'm open to evolving this if 
that's what we need.

As a user, I would not want to enter JSON into an RDAP client to do a 
lookup. A simple and transcribable string is much easier to use.

I don't believe the goal here is to define more structure for entity 
identifiers. RDAP already provides URLs for entities, and that is 
probably enough structure.

All that said, I understand your hesitation here. This draft takes an 
unstructured field already in use and applies structure to it. That 
could be problematic, and care must be taken. Doing such a thing is not 
ideal, but we wouldn't be the first to do so. The xn-- signifier for 
IDNs comes to mind.

-andy

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 20 Dec 2017 05:53:51 +0100

> lookup. A simple and transcribable string is much easier to use.

I never suggested that. The JSON structure is what is exchanged on wire, it is independent on the kind of UI you want to present to your users.
 
> probably enough structure.

There does not need to have more structures... as everything is there
already I believe with PublicID defined in 4.8 of RFC7483

> ideal, but we wouldn't be the first to do so. The xn-- signifier for 

I agree... except that when IDNs were introduced there was already a not so small
population of clients (DNS resolvers) that had to be taken into account.
RDAP is still young, and far less used than whois.

I was amazed to see in fact just by chance that very recently many blogs tried
to make it more known, such as:
https://blog.apnic.net/2017/08/11/2017-still-whois-whats-holding-back-rdap/
https://www.farsightsecurity.com/2017/11/17/stsauver-rdap/

Like you say, the summary for me is that adding a structure into an unstructured
field after the fact is problematic. The problem is on the table, but it may be decided it is irrelevant or too late based on current deployments. I of course agree, I just think it is best to be clear about it. But if noone else speaks about it, case closed.

BTW even for DNS, there are also discussions/interrogations showing that changes
like IDNs to a core protocol were not necessarily the best choice.
See https://datatracker.ietf.org/doc/draft-klensin-dns-function-considerations/
(a very interesting read for history decisions)

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 28 Dec 2017 14:11:40 +0000

> Sent: Tuesday, December 19, 2017 11:54 PM
> To: [email-masked]

[snip]

> Like you say, the summary for me is that adding a structure into an
> unstructured field after the fact is problematic. The problem is on the
> table, but it may be decided it is irrelevant or too late based on current
> deployments. I of course agree, I just think it is best to be clear about
> it. But if noone else speaks about it, case closed.

...but this isn't really "after the fact". It's already being done in the RIRs, and since RDAP isn't yet widely deployed there's little risk of anything breaking in production services. A minor value change like this can be done easily in the context of a migration to RDAP.

Scott

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 31 Dec 2017 00:50:30 +0100

Hello Scott,

On Thu, Dec 28, 2017, at 15:11, Hollenbeck, Scott wrote:
> ...but this isn't really "after the fact". 

It is, because the RDAP RFCs are already done, and the main reason not to add
more structure to them and going the way you propose is that the structure is
already done and what you document is what is done on the field.

> A minor value change like 
> this can be done easily in the context of a migration to RDAP.

It may mean a small *technical* change but I believe it to be a big
*semantic* (design) change and not in the good direction to my thinking.

However I think the rough consensus on the issue is clear, so we will
remain in a disagreement on this specific issue, but the draft would go along.

-- 
  Patrick Mevzek