Subject: [regext] WGLC: draft-ietf-regext-rdap-object-tag

From: "James Galvin" <[email-masked]>
Date: Fri, 06 Apr 2018 09:59:04 -0400

The document editors have indicated that the following document is ready 
for submission to the IESG to be considered for publication as a Best 
Current Practice:

Registration Data Access Protocol (RDAP) Object Tagging
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/

Please indicate your support for the publication of this document.

If any working group member objects to the publication of this document 
please respond on the list by close of business everywhere, Friday, 20 
April 2018.  If there are no objections the document will be submitted 
to the IESG.

During the last call the chairs are looking for a document shepherd for 
this document.  If you are interested in being the document shepherd 
please let the chairs know.  The document editors cannot be the document 
shepherd.

If you’ve never been a document shepherd before don’t worry.  It’s 
a great way to understand the IETF process and your chairs would be 
delighted to help you through it.

Thanks,

Antoin and Jim
WG Co-Chairs

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 13 Apr 2018 10:54:35 +0000

> -----Original Message-----
> From: regext [mailto:[email-masked]] On Behalf Of James Galvin
> Sent: Friday, April 06, 2018 9:59 AM
> To: Registration Protocols Extensions <[email-masked]>
> Subject: [EXTERNAL] [regext] WGLC: draft-ietf-regext-rdap-object-tag
>
> April 2018.  If there are no objections the document will be submitted to
> the IESG.

It's been one week with no feedback at all. Come on, folks, please speak up! One of our obligations as working group members is to review and discuss the documents being developed in the group. It helps the document shepherd, the WG chairs, and the IESG to get a better measure of consensus based on the discussion. It's OK to say, "I've read the document and I have no concerns"! The IETF doesn't charter "lurking" groups, people!

> please let the chairs know.  The document editors cannot be the document

I've found someone who is willing to be the document shepherd. I'll give him a "please identify yourself" poke shortly.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 13 Apr 2018 11:24:07 +0000

I volunteer to be the document shepherd.

Thanks,

Jim

> On Apr 6, 2018, at 9:59 AM, James Galvin <[email-masked]> wrote:
> 
> The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Best Current Practice:
> 
> If any working group member objects to the publication of this document please respond on the list by close of business everywhere, Friday, 20 April 2018.  If there are no objections the document will be submitted to the IESG.
> 
> During the last call the chairs are looking for a document shepherd for this document.  If you are interested in being the document shepherd please let the chairs know.  The document editors cannot be the document shepherd.
> 
> If you’ve never been a document shepherd before don’t worry.  It’s a great way to understand the IETF process and your chairs would be delighted to help you through it.
> 
> Thanks,
> 
> Antoin and Jim
> WG Co-Chairs
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "James Galvin" <[email-masked]>
Date: Fri, 13 Apr 2018 09:10:00 -0400

Thanks to James Gould for volunteering to be document shepherd!

Please folks, as Scott says, respond to this message and indicate your 
support or at least no objection.

Thanks!

Antoin and Jim

On 6 Apr 2018, at 9:59, James Galvin wrote:

> The document editors have indicated that the following document is 
> ready for submission to the IESG to be considered for publication as a 
> Best Current Practice:
>
> If any working group member objects to the publication of this 
> document please respond on the list by close of business everywhere, 
> Friday, 20 April 2018.  If there are no objections the document will 
> be submitted to the IESG.
>
> During the last call the chairs are looking for a document shepherd 
> for this document.  If you are interested in being the document 
> shepherd please let the chairs know.  The document editors cannot be 
> the document shepherd.
>
> If you’ve never been a document shepherd before don’t worry.  
> It’s a great way to understand the IETF process and your chairs 
> would be delighted to help you through it.
>
> Thanks,
>
> Antoin and Jim
> WG Co-Chairs

---

From: Andrew Newton <[email-masked]>
Date: Fri, 13 Apr 2018 11:52:09 -0400

I support... but I'm also a co-author. :)

-andy

On Fri, Apr 13, 2018 at 9:10 AM, James Galvin <[email-masked]> wrote:
>> please respond on the list by close of business everywhere, Friday, 20 April
>> 2018.  If there are no objections the document will be submitted to the
>> IESG.
>>
>> this document.  If you are interested in being the document shepherd please
>> let the chairs know.  The document editors cannot be the document shepherd.
>>
>> If you’ve never been a document shepherd before don’t worry.  It’s a great
>> way to understand the IETF process and your chairs would be delighted to
>> help you through it.
>>
>> Thanks,
>>
>> Antoin and Jim
>> WG Co-Chairs
>
>

---

From: Marcos Sanz <[email-masked]>
Date: Fri, 13 Apr 2018 18:06:47 +0200

I support it and think it's a good idea.
Marcos

   Andrew Newton --- Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag --- 
    De:"Andrew Newton" <[email-masked]>A:"James Galvin" <[email-masked]>Cc:"Registration Protocols Extensions" <[email-masked]>Fecha:vie., 13 abr. 2018 17:52Asunto:Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag
  
    I support... but I'm also a co-author. :)-andyOn Fri, Apr 13, 2018 at 9:10 AM, James Galvin <[email-masked]> wrote:> Thanks to James Gould for volunteering to be document shepherd!>> Please folks, as Scott says, respond to this message and indicate your> support or at least no objection.>> Thanks!>> Antoin and Jim>>>>>> On 6 Apr 2018, at 9:59, James Galvin wrote:>>> The document editors have indicated that the following document is ready>> for submission to the IESG to be considered for publication as a Best>> Current Practice:>>>> Registration Data Access Protocol (RDAP) Object Tagging>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/>>>> Please indicate your support for the publication of this document.>>>> If any working group member objects to the publication of this document>> please respond on the list by close of business everywhere, Friday, 20 April>> 2018.  If there are no objections the document will be submitted to the>> IESG.>>>> During the last call the chairs are looking for a document shepherd for>> this document.  If you are interested in being the document shepherd please>> let the chairs know.  The document editors cannot be the document shepherd.>>>> If you’ve never been a document shepherd before don’t worry.  It’s a great>> way to understand the IETF process and your chairs would be delighted to>> help you through it.>>>> Thanks,>>>> Antoin and Jim>> WG Co-Chairs>>> _______________________________________________> regext mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/regext_______________________________________________regext mailing [email-masked]://www.ietf.org/mailman/listinfo/regext

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 13 Apr 2018 14:03:29 -0300

> Please indicate your support for the publication of this document.

I support this document,

Fred

---

From: Patrick Mevzek <[email-masked]>
Date: Sat, 14 Apr 2018 04:19:09 +0200

On Fri, Apr 13, 2018, at 12:54, Hollenbeck, Scott wrote:
> It's OK to say, "I've read the 
> document and I have no concerns"! The IETF doesn't charter "lurking" 
> groups, people!

FWIW and speaking just about myself, it is not that I am just lurking in the LCs it is that I have various issues with the 4 current LCs (this rdap-objet-tag, the fees one, and the two organization ones, though I need to carefully re-read these last 2 to implement them and see differences), for which I already raised concerns here that were or were not adressed.

So I can not support them, and this is why I say nothing, and while objecting to them at various degrees, I have no strong enough feelings to be vocal about them.

-- 
  Patrick Mevzek
  [email-masked]

---

From: George Michaelson <[email-masked]>
Date: Mon, 16 Apr 2018 08:58:58 +1000

I have read this draft. I work for an agency which has deployed RDAP
in a globally connected context. I would welcome this draft
progressing because we are already in a situation where public
services designed to unite RDAP services could leverage this draft,
and I want to see strong coherence between the names and numbers RDAP
system behaviours.

I think this draft should be sent forward.

-George

On Fri, Apr 6, 2018 at 11:59 PM, James Galvin <[email-masked]> wrote:
> The document editors have indicated that the following document is ready for
> submission to the IESG to be considered for publication as a Best Current
> Practice:
>
> During the last call the chairs are looking for a document shepherd for this
> document.  If you are interested in being the document shepherd please let
> the chairs know.  The document editors cannot be the document shepherd.
>

---

From: Pieter Vandepitte <[email-masked]>
Date: Mon, 16 Apr 2018 08:58:25 +0200

Hi, my 2 cents:

(1) I think the solution is just not right. It's a quick and dirty way of doing these things. The right way imo is defining a new RDAP extension (with a dedicated attribute to identify the authoritative source)
(2) In my opinion there are other, existing, mechanisms for discovering entities (and mentioned in the draft: self links).

So, for me, it's a no, I don't support it as it is now.

Kind regards

Pieter

> On 13 Apr 2018, at 12:54, Hollenbeck, Scott <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 16 Apr 2018 10:10:41 +0200

I support it.

Regards
Mario

Il 13/04/2018 15:10, James Galvin ha scritto:
>> ready for submission to the IESG to be considered for publication as 
>> a Best Current Practice:
>>
>> If you’ve never been a document shepherd before don’t worry. It’s a 
>> great way to understand the IETF process and your chairs would be 

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 16 Apr 2018 11:03:43 +0000

From: regext [mailto:[email-masked]] On Behalf Of Pieter Vandepitte
Sent: Monday, April 16, 2018 2:58 AM
To: [email-masked]
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag

Hi, my 2 cents:

I think you have the use case incorrect. This isn't about discovering entities, it's about being able to bootstrap a query for an entity when you have no other information available in much the same way that domain queries can be bootstrapped as described in RFC 7484. You can't use self links if all you have to start with is something that looks like "ABC123". So please fill me in if you can think of a way for a client to receive an entity handle like "ABC123" and determine which is the authoritative server for that entity in the absence of any other information.

Scott

---

From: Pieter Vandepitte <[email-masked]>
Date: Mon, 16 Apr 2018 15:39:37 +0200

> I think you have the use case incorrect. This isn’t about discovering entities, it’s about being able to bootstrap a query for an entity when you have no other information available in much the same way that domain queries can be bootstrapped as described in RFC 7484. You can’t use self links if all you have to start with is something that looks like “ABC123”. So please fill me in if you can think of a way for a client to receive an entity handle like “ABC123” and determine which is the authoritative server for that entity in the absence of any other information.
>  

No, indeed it isn't about discovering entities, but discovering the authoritative server for an entity, basically wat is meant with bootstrapping. 

There are basically 2 use cases I can think of: (1) you need to discover an entity referred to by another object (e.g. domain) and (2) you need to discover an entity for which you only have the handle.

For the first one, RFC 7484 gives some hints how this could be achieved and I think alternatively you could introduce a new attribute or use the self links. Maybe we agree on that one?

For the second use case, as you noticed rightly, there's currently no way a client can guess where the query should be sent to, if you only have the handle. I agree upon that. 
The solution now is: let's extend the handle, and append it with the repo, then the client needs to parse it, discover the URL and send the entity lookup request to that URL.
My solution would be: let's extend the client and let it accept a second argument for the repo. The client still needs to discover the URL (using the second argument), but you can skip that parsing thing in the clients and no need for an RFC to solve this issue.  (I agree we need a "Bootstrap Service Registry for Entities")

So my final vote on this draft: if there's a need for "globally unique handles" (I'm not convinced they are needed to help the clients), then yes, go ahead, but I would prefer a hyphen (it works, as long as the repos do not have hyphens), the same as roid in EPP.

Kind regards,

Pieter

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 16 Apr 2018 15:07:42 +0000

From: Pieter Vandepitte [mailto:[email-masked]]
Sent: Monday, April 16, 2018 9:40 AM
To: Hollenbeck, Scott <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag

   [SAH] Maybe, if one wants to assume that authority is extended by association. I don’t think that such implicit assumptions are a good idea when they are exceptions from the way that authority is derived for other objects.

   [SAH] Unfortunately, the hyphen-minus character won’t work for reasons explained in the draft. Repos *are* currently using that character in their entity identifiers.

   Scott

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 18 Apr 2018 08:44:30 +0200

Pieter,

On Mon, Apr 16, 2018, at 15:39, Pieter Vandepitte wrote:
> No, indeed it isn't about discovering entities, but discovering the 
> authoritative server for an entity, basically wat is meant with 
> bootstrapping. 

[..]

> So my final vote on this draft: if there's a need for "globally unique 
> handles" (I'm not convinced they are needed to help the clients), then 
> yes, go ahead, but I would prefer a hyphen (it works, as long as the 
> repos do not have hyphens), the same as roid in EPP.

FWIW, note that I completely share both your observations and your conclusions.
So that you do not feel alone :-), we are at least too, but clearly the minority. Such is life.

More broadly, I am doubly sad that hyphen is rejected because already seen elsewhere.

First, because RDAP for domain names has not reached critical mass and far from it in fact (newer discussions on GDPR should have ressuscited it since it is clearly suited for it, but things being done at the last time did not make
it possible I guess to think about it, and I applaud Scott's energy and experiments on authentication models for it), so no characters should be ignored just because some other registries did start to use it.
When IDNs started, before IDNA became a standard, names were sold and used with the bq-- prefix. This was absolutely not a reason not to choose a "proper" prefix, even if it meant at the time to break any existing bq-- domain names

Secondly, not using hyphens will make it very hard for anyone to convince me that there is really an overlap between EPP and RDAP (which was a core justification to create this WG), as hyphen is clearly the choice in EPP.

The rdapConformance part could have a "objectTag-0" token whose presence would signal the client that the hyphen in object IDs has a special meaning because it is a separator. This would allow current registries using hyphens not as separator to continue working in the same way as they would not present this "extension" in their response. Client would just need to adapt, but it is the case what ever happens and characters is used since there is no guarantee that all IDs, even in the same repository, will be formatted with it.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 18 Apr 2018 11:07:51 +0000

> From: regext [mailto:[email-masked]] On Behalf Of Patrick Mevzek
> Sent: Wednesday, April 18, 2018 2:45 AM
> To: [email-masked]
> First, because RDAP for domain names has not reached critical mass and far
> from it in fact (newer discussions on GDPR should have ressuscited it
> since it is clearly suited for it, but things being done at the last time
> did not make it possible I guess to think about it, and I applaud Scott's
> energy and experiments on authentication models for it), so no characters
> should be ignored just because some other registries did start to use it.
> When IDNs started, before IDNA became a standard, names were sold and used
> with the bq-- prefix. This was absolutely not a reason not to choose a
> "proper" prefix, even if it meant at the time to break any existing bq--
> domain names

Remember, though, that the situation with bq-- is precisely why a decision was made to use xn-- instead.

> Secondly, not using hyphens will make it very hard for anyone to convince
> me that there is really an overlap between EPP and RDAP (which was a core
> justification to create this WG), as hyphen is clearly the choice in EPP.
>
> The rdapConformance part could have a "objectTag-0" token whose presence
> would signal the client that the hyphen in object IDs has a special
> meaning because it is a separator. This would allow current registries
> using hyphens not as separator to continue working in the same way as they
> would not present this "extension" in their response. Client would just
> need to adapt, but it is the case what ever happens and characters is used
> since there is no guarantee that all IDs, even in the same repository,
> will be formatted with it.

This is worth exploring. What do people think about going back to HYPHEN MINUS as a separator and noting the significance of the character with an "objectTag-0" token in the rdapConformance array? The draft should probably include text requiring addition of an "objectTag-0" token in the rdapConformance array to note support for this practice no matter which separator character is used.

Scott

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 20 Apr 2018 02:13:52 +0200

On Wed, Apr 18, 2018, at 13:07, Hollenbeck, Scott wrote:
> This is worth exploring. What do people think about going back to HYPHEN 
> MINUS as a separator and noting the significance of the character with 
> an "objectTag-0" token in the rdapConformance array? The draft should 
> probably include text requiring addition of an "objectTag-0" token in 
> the rdapConformance array to note support for this practice no matter 
> which separator character is used.

Whatever character is used, I think it creates no harms and only benefits to put something (whatever token is best) inside the rdapConformance array to signal to clients that object IDs are returned with some specific format, so that they are aware of it.

And things remain compatible with current registries not using a specific format and hence not adding this token.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 20 Apr 2018 10:59:03 +0000

> Sent: Thursday, April 19, 2018 8:14 PM
> To: [email-masked]
> > This is worth exploring. What do people think about going back to
> > HYPHEN MINUS as a separator and noting the significance of the
> > character with an "objectTag-0" token in the rdapConformance array?
> > The draft should probably include text requiring addition of an
> > "objectTag-0" token in the rdapConformance array to note support for
> > this practice no matter which separator character is used.
>
> Whatever character is used, I think it creates no harms and only benefits
> to put something (whatever token is best) inside the rdapConformance array
> to signal to clients that object IDs are returned with some specific
> format, so that they are aware of it.
>

Agreed, I'll add that text.

Last call ends today, folks. Anything else?

Scott

---

From: Andrew Newton <[email-masked]>
Date: Fri, 20 Apr 2018 11:08:11 -0400

> This is worth exploring. What do people think about going back to HYPHEN MINUS as a separator and noting the significance of the character with an "objectTag-0" token in the rdapConformance array?…

I like this idea a lot.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 20 Apr 2018 11:09:44 -0400

> Last call ends today, folks. Anything else?

In my opinion, going back to hyphen and introducing "objectTag_0" is a
conformance identifier is a significant change. I support it, but we
should probably give people time to comment on it.

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 20 Apr 2018 19:06:57 +0000

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, April 20, 2018 11:10 AM
> Cc: [email-masked]; [email-masked]

Agreed - chairs, can we extend the last call by one week to give people time to think about the change and extend statements of support or concern? For the record, I support it, too.

Scott