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

2017-12-30 Thread Patrick Mevzek
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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-12-28 Thread Hollenbeck, Scott
> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Patrick Mevzek
> Sent: Tuesday, December 19, 2017 11:54 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-
> rdap-object-tag-05.txt

[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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-12-13 Thread Andrew Newton



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



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,

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-12-13 Thread Patrick Mevzek
> 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
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-12-13 Thread Hollenbeck, Scott
> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Patrick Mevzek
> Sent: Tuesday, December 12, 2017 10:21 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-
> rdap-object-tag-05.txt
>
>
> 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.

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-12-12 Thread Patrick Mevzek

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-12-12 Thread Hollenbeck, Scott
> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Patrick Mevzek
> Sent: Monday, December 11, 2017 11:34 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-
> rdap-object-tag-05.txt
>
> 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?

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.

> 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.

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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-12-11 Thread Patrick Mevzek
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
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-10-24 Thread Hollenbeck, Scott
> -Original Message-
> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: Tuesday, October 24, 2017 9:02 AM
> To: i-d-annou...@ietf.org
> Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-rdap-object-tag-
> 05.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title   : Registration Data Access Protocol (RDAP) Object
> Tagging
> Authors : Scott Hollenbeck
>   Andrew Lee Newton
>   Filename: draft-hollenbeck-regext-rdap-object-tag-05.txt
>   Pages   : 12
>   Date: 2017-10-24
>
> Abstract:
>The Registration Data Access Protocol (RDAP) includes a method that
>can be used to identify the authoritative server for processing
>domain name, IP address, and autonomous system number queries.  The
>method does not describe how to identify the authoritative server for
>processing other RDAP query types, such as entity queries.  This
>limitation exists because the identifiers associated with these query
>types are typically unstructured.  This document describes an
>operational practice that can be used to add structure to RDAP
>identifiers that makes it possible to identify the authoritative
>server for additional RDAP queries.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-object-tag/

With thanks to Tom Harwood, this version includes a description of the 
implementation work done by OpenRDAP, https://www.openrdap.org.

Scott

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext