Subject: Re: [weirds] WGLC: draft-ietf-weirds-rdap-query-05

From: Olaf Kolkman <[email-masked]>
Date: Wed, 3 Jul 2013 17:05:42 +0200

Folk,

One more week to go, and no feedback yet.

In order to progress this document we need to have a reasonable sense of broad review. It helps if you go on record that you reviewed the draft and do not have any issues.

--Olaf

On Jun 25, 2013, at 2:38 PM, Olaf Kolkman <[email-masked]> wrote:

> 
> Colleagues,
> 
> It's time for a WGLC for de rdap-query document. We'll put the Last call up for two weeks, ending July 10.
> 
> The document can be found at:
> http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-05
> 
> 
> I will be the shepherd for this document. Which in this case brings a small logistical problem. When the WGLC terminates I will be on vacation, and not resurface before Berlin. That said, please send in your comments before July 10 so that editors can process your feedback.
> 
> 
> --Olaf
> 
> 
> 
> 
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 03 Jul 2013 12:16:51 -0300

I don't have issues with the document as is.

cheers,

~Carlos

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 3 Jul 2013 11:37:24 -0400

While doing the test plan and scripts, my colleague Jean-Philippe has already discovered a few issues, essentially under specified behaviors. We may find others as we test the current implementations.  My suggestion: delay the end of the wglc until end of IETF week in Berlin, when we would have a first interop testing event done that may raise up additional findings to improve the spec.

Marc.

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 03 Jul 2013 15:57:22 -0400

Comments on this draft.

p.2 enable lookups of:
    o  registrars by name, and
    o  entities (such as contacts) by identifier
But p.6 specifies the Entity Path Segment Specification as
Syntax: entity/<handle>
There is no direct way to look up registrars by name. A server that 
receives an entity request does not know if the parameter is a handle or 
a name. It can attempt a handle lookup and if it fails try a name 
lookup. It would be much better to have a separate request to look up a 
registrar (or entity) by name.

p.2 It is envisioned that other documents will describe these entities
--Update with reference to draft-ietf-weirds-json-response

p.3 HTTP contains mechanisms for servers to authenticate ...
--Update with reference to draft-ietf-weirds-using-http and 
draft-ietf-weirds-rdap-sec

p.3 The uniform patterns start with a base URL ...
--Some proposals for bootstrapping will not support this. Should Last 
Call on this document be deferred until the decisions on bootstrapping 
have been made?

p.4 Queries for information regarding autonomous system number 
registrations are of the form /autnum/XXX/... where XXX is an asplain
--Last phrase reads as a typo to those not familiar with the term. 
Change to:
where XXX is an "asplain"

p.5 and 6  If the client sends the server an IDN in U-label format, 
servers that support IDNs MUST convert the IDN into A-label format and 
perform IDNA processing as specified in RFC 5891 [RFC5891]
--RFC5891 specifies two slightly different processes (Section 3.1):
        Labels being registered MUST conform to the requirements of
        Section 4.  Labels being looked up and the lookup process MUST
        conform to the requirements of Section 5.
Can this reference be more explicit to section 4 or 5.

p.7 ... the process described in Section TBD of "Using HTTP for RESTful 
Whois Services by Internet Registries"
Update to ... the process described in Section 6 of "HTTP usage in the 
Registration Data Access Protocol (RDAP)"

p.10 Appendix A. seems like an interim note, should it be in a published 
RFC?

-Ernie

---

From: "John Levine" <[email-masked]>
Date: 4 Jul 2013 22:11:07 -0000

>Call on this document be deferred until the decisions on bootstrapping 

I was going to suggest taking out the bit about base URLs.  They add
no function, since anything you can do with a base URL you can do just
as well with a virtual domain, and they make the clients more complex.

>where XXX is an "asplain"

How about just "is a decimal number" since that's what an asplain is,
and refer to RFC 5396.  The asplain terminology exists only to
contrast with other ASN formats that nobody uses, so I don't see any
need to import it here.

>p.10 Appendix A. seems like an interim note, should it be in a published 

I think it's useful to answer the frequent questions about where are the
search patterns.

R's,
John

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 5 Jul 2013 11:17:55 -0400

> contrast with other ASN formats that nobody uses, so I don't see any

I disagree. I think it is the right approach to refer to the appropriate RFC that describes the formats in use for ASN. 

Marc.

---

From: "John Levine" <[email-masked]>
Date: 5 Jul 2013 21:08:41 -0000

>I disagree. I think it is the right approach to refer to the appropriate RFC that describes the formats in use for ASN. 

OK, then say both.  It seems cruel to send people running over to
anothe RFC just to find that an argument is a decimal number.

Still want to remove the URL prefixes though, since they are an actual complexity issue.

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 5 Jul 2013 20:56:22 -0400

> anothe RFC just to find that an argument is a decimal number.

I disagree. The referenced RFC is pretty short, so no pain to read it. And for anyone who cares about ASN, there are various formats and by giving the reference, we are sure that there is no ambiguity. We don't want to redefine something where it is defined somewhere else.

Marc.

---

From: Arturo Servin <[email-masked]>
Date: Mon, 08 Jul 2013 08:49:46 -0300

How about:

"where XXX is a decimal number as defined in RFC5396"

/as

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 8 Jul 2013 13:09:58 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Arturo Servin
> Sent: Monday, July 08, 2013 7:50 AM
> To: [email-masked]
> Subject: Re: [weirds] WGLC: draft-ietf-weirds-rdap-query-05
> 
> 
> 
>     How about:
> 

I like Ernie's suggestion to put asplain in quotes ('where XXX is an "asplain" autonomous system number [RFC5396]'). That makes it clear that we're talking about a very specific data type identified in 5396.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 8 Jul 2013 13:16:53 +0000

> Behalf Of Ernie Dainow
> Sent: Wednesday, July 03, 2013 3:57 PM
> Cc: [email-masked] Group

As currently specified the server should only receive entity handles when doing an exact match lookup.

We touched on this topic at some point in the past, but I'm having trouble finding the thread in the archives. I thought we had consensus to address entity name lookups in the search draft, so a method to look for a registrar by name is described in section 3.2 of draft-hollenbeck-weirds-rdap-search.

> --Update with reference to draft-ietf-weirds-json-response

OK.

> draft-ietf-weirds-rdap-sec

OK.

> where XXX is an "asplain"

OK.

> Can this reference be more explicit to section 4 or 5.

Since we're talking about a lookup process I don't see how the registration process described in Section 4 can be applied, but OK, it can't hurt to be more specific.

> Registration Data Access Protocol (RDAP)"

OK, thanks for catching that.

> p.10 Appendix A. seems like an interim note, should it be in a

It *is* more of a note than anything else, but I agree with John Levine's comment that "it's useful to answer the frequent questions about where are the search patterns". I can live with it being excised from here and added to the search draft I mentioned above.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 9 Jul 2013 11:51:44 +0000

Referencing some rdap-query last call comments from Ernie and John:

> It *is* more of a note than anything else, but I agree with John
> Levine's comment that "it's useful to answer the frequent questions
> about where are the search patterns". I can live with it being excised
> from here and added to the search draft I mentioned above.

This brings up a larger point: we still haven't made a decision about how to document search functionality. rdap-query punts it to a document that didn't exist when we first wrote rdap-query. Now we have draft-hollenbeck-weirds-rdap-search and draft-zhou-weirds-rdap-restful-search, but neither is a working group document. If we agree that basic search functionality needs to be documented we need to decide what it is and where it gets described. I don't think we can push rdap-query to IETF last call until we make a decision.

My suggestion: either add the functions described in draft-hollenbeck-weirds-rdap-search to rdap-query or adopt rdap-search and reference it. I tend to favor the former because it reduces the document count and puts a core set of client-sent commands in one place. We can still explore more advanced search functionality in draft-zhou as we see fit.

Scott

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Jul 2013 15:33:06 -0700

On Tue, Jul 9, 2013 at 4:51 AM, Hollenbeck, Scott
<[email-masked]>wrote:

> This brings up a larger point: we still haven't made a decision about how
> to document search functionality. rdap-query punts it to a document that
> didn't exist when we first wrote rdap-query. Now we have
> draft-hollenbeck-weirds-rdap-search and
> draft-zhou-weirds-rdap-restful-search, but neither is a working group
> document. If we agree that basic search functionality needs to be
> documented we need to decide what it is and where it gets described. I
> don't think we can push rdap-query to IETF last call until we make a
> decision.
>
> My suggestion: either add the functions described in
> draft-hollenbeck-weirds-rdap-search to rdap-query or adopt rdap-search and
> reference it. I tend to favor the former because it reduces the document
> count and puts a core set of client-sent commands in one place. We can
> still explore more advanced search functionality in draft-zhou as we see
> fit.
>

Olaf's the shepherd on this one, so speaking only as a participant here:

If the search functionality that we decide will be an integral part of RDAP
is relatively simple in terms of the query syntax and capabilities, I think
rolling it into rdap-query makes sense.  Creating a new document for
something very simple is possibly more work than it's worth, and it would
bring to four the number of documents about which we need to make a
processing decision (with the object inventory, search, and bootstrapping
already under discussion).  Keeping procedural work to a minimum is not a
bad thing.

-MSK

---

From: Andy Newton <[email-masked]>
Date: Tue, 16 Jul 2013 13:41:01 +0000

>as well with a virtual domain, and they make the clients more complex.

I'm hard pressed to see how it makes a client more complex. I've written a
client and it bore no difference in the string manipulation code needed
for acting on base urls.

On the flip side, I'm in the middle of writing ARIN's server
implementation and being forced to root the URL at a domain name only will
cause issues with deploying the code on our current RESTful
infrastructure. I'm not saying they are insurmountable, but its extra
machinery and that always leads to more complexity.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 16 Jul 2013 13:46:12 +0000

On 7/9/13 7:51 AM, "Hollenbeck, Scott" <[email-masked]> wrote:

>draft-hollenbeck-weirds-rdap-search to rdap-query or adopt rdap-search
>and reference it. I tend to favor the former because it reduces the
>document count and puts a core set of client-sent commands in one place.
>We can still explore more advanced search functionality in draft-zhou as
>we see fit.

I it was John Levine who did a quick survey of current Whois search
functions and found that they are not anywhere close to universally
supported.

As lookups are by far the predominate query type, I think holding our
specs to get a feature that doesn't meet the 80/20 rule is imprudent,
especially when it can be added later with little fuss.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 16 Jul 2013 10:10:03 -0400

> client and it bore no difference in the string manipulation code needed

It makes the bootstrap harder, since it has to find a complete URL, not 
just a host name.

> machinery and that always leads to more complexity.

I thought we agreed that given that there will be far more clients than 
servers, it's better to put the extra complexity on the server side.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 16 Jul 2013 14:12:29 +0000

> From: Andy Newton [mailto:[email-masked]]
> Sent: Tuesday, July 16, 2013 9:46 AM
> To: Hollenbeck, Scott; [email-masked]

Then rdap-query stills needs to be updated to close the loop on entity lookups by name (which aren't supported) and to make it clear that the search stuff is being deferred to an unnamed (and possibly non-existent) additional spec.

Scott

---

From: Andy Newton <[email-masked]>
Date: Tue, 16 Jul 2013 14:13:51 +0000

>It makes the bootstrap harder, since it has to find a complete URL, not

Care to elaborate? Because I ran into no such issue at all.

>servers, it's better to put the extra complexity on the server side.

I agree when it makes a difference. But in this instance it does not.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 16 Jul 2013 14:24:58 +0000

On 7/16/13 10:12 AM, "Hollenbeck, Scott" <[email-masked]> wrote:

>>Then rdap-query stills needs to be updated to close the loop on entity
>>lookups by name (which aren't supported) and to make it clear that the
>>search stuff is being deferred to an unnamed (and possibly non-existent)
>>additional spec.

Is this an ICANN requirement? I'm trying to remember where it comes from.

Regardless, I doubt this meets the 80/20 rule as well. How many queries
are entity lookup by name vs ip lookup by address or domain lookup by
domain name?

-andy

---

From: "John R Levine" <[email-masked]>
Date: 16 Jul 2013 10:27:49 -0400

>>> I'm hard pressed to see how it makes a client more complex. I've 
>>> written a client and it bore no difference in the string manipulation 
>>> code needed for acting on base urls.
>>

On the numbers side, it seems unlikely that there will be any bootstrap 
more complex than point your client at your local RIR or maybe use a 
lookup table you downloaded one time, and hope for the best, so I agree 
it's not a big deal there.

On the names side, there are hundreds of TLDs now, and will be thousands, 
and it is utterly implausible that TLDs would agree to forward misdirected 
requests like RIRs do.

The obvious bootstrap to use the TLD name as the key for a DNS lookup and 
tell all the TLDs to use the same URL format, e.g.

http://<tld>.domain.rdap-servers.arpa/domain/foo.<tld>

This bootstrap is trivial.  If the bootstrap requires finding extra cruft 
to insert into the URL, it is far more complex.

R's,
John

PS: Didn't we have this same discsussion a few weeks ago?

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 16 Jul 2013 14:45:40 +0000

> Sent: Tuesday, July 16, 2013 10:25 AM

Both John Levine and Ernie Dainow have asked about registrar lookups by name, which we don't describe in rdap-query. In both cases I've pointed them to rdap-search, which isn't a WG draft.

This type of lookup is a currently supported feature for .com and .net. I didn't check other TLDs so I don't know if others do it, too. I also don't know how many such queries Verisign receives, but I have someone looking into it.

Scott

---

From: Andy Newton <[email-masked]>
Date: Tue, 16 Jul 2013 15:28:35 +0000

>it's not a big deal there.

You are arguing that it impedes your favored method of bootstrap, not that
it causes client code complexity which is where you started your objection.

>and it is utterly implausible that TLDs would agree to forward

You keep saying this, but that isn't how the concept of a bootstrap server
has been described.

>to insert into the URL, it is far more complex.

Extra cruft? Care to elaborate?

As for code complexity:

1) your method

{ tld = domain.split( "\." ).last; url =
"http://#{tld}.domain.rdap-servers.arpa/domain/#{domain} }
# doesn't account for co.uk and the like

2) my way

{ url = "http://bootstrap.example/domain/#{domain}" }

-andy

---

From: "John R Levine" <[email-masked]>
Date: 16 Jul 2013 11:47:40 -0400

> it causes client code complexity which is where you started your objection.

Um, the bootstrap is part of the client.

>> On the names side, there are hundreds of TLDs now, and will be 
>> thousands, and it is utterly implausible that TLDs would agree to 
>> forward misdirected requests like RIRs do.

> You keep saying this, but that isn't how the concept of a bootstrap server

Aw, come on.  We've had lengthy arguments about exactly these issues on 
this list in the past month.

  ...

> { url = "http://bootstrap.example/domain/#{domain}" }

For numbers, it's basically what I said two messages ago, point your 
client at your RIR and it'll redirect you.

For names, there is an enormous amount of WHOIS traffic to Verisign, large 
amounts to Afilias and maybe Neustar and a trickle to everyone else.  An 
http bootstrap means that the bootstrap has to handle an RDAP load as 
great as Verisign's since they'll potentially be doing a redirect in front 
of every lookup.  (Web caches don't help unless you expect people to be 
making the exact same query over and over.)  While IANA has said they 
could do it if we asked them to, that seems like a lot of infrastructure 
for very little gain relative to a DNS bootstrap.

Also, given the financial stakes in the domain community, a third party 
server that knows all or most of the RDAP queries people are making is 
going to have a bullseye painted on it, both to DoS and even more to steal 
the logs.  A DNS bootstrap avoids those.

Finally, in case it's not obvious, I see no reason that numbers and names 
need the same bootstrap.  The questions and answers are different (some 
overlap, but basically different) and a different bootstrap is no big deal 
so long as it's simple.  Yes, I know it makes the client a smidgen more 
complex.

R's,
John

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 16 Jul 2013 12:24:01 -0400

On 7/16/2013 11:47 AM, John R Levine wrote:
> For names, there is an enormous amount of WHOIS traffic to Verisign, 
> large amounts to Afilias and maybe Neustar and a trickle to everyone 
> else.  An http bootstrap means that the bootstrap has to handle an 
> RDAP load as great as Verisign's since they'll potentially be doing a 
> redirect in front of every lookup.  (Web caches don't help unless you 
> expect people to be making the exact same query over and over.)  While 
> IANA has said they could do it if we asked them to, that seems like a 
> lot of infrastructure for very little gain relative to a DNS bootstrap.
>
> Also, given the financial stakes in the domain community, a third 
> party server that knows all or most of the RDAP queries people are 
> making is going to have a bullseye painted on it, both to DoS and even 
> more to steal the logs.  A DNS bootstrap avoids those.
>
> Finally, in case it's not obvious, I see no reason that numbers and 
> names need the same bootstrap.  The questions and answers are 
> different (some overlap, but basically different) and a different 
> bootstrap is no big deal so long as it's simple.  Yes, I know it makes 
> the client a smidgen more complex.
>

Here is what I see as the key points in the bootstrap debate for names.

The DNS solution seems simple from the client side, where the client 
simply uses
http://<tld>.domain.rdap-servers.arpa/domain/foo.<tld>

However, this solution has limitations because the server cannot be 
configured with a general url path.
1) all RDAP servers must be either http or https (http with redirect to 
https where necessary may address this adequately)
2) in a production environment it adds great flexibility to be able 
define a service with a url path.

It is not clear that the DNS solution is worth giving up the flexibility 
of the url path. A url table for names is not so very different from a 
url table for numbers. While there are many more providers for names, 
the large bulk of registered domains (and presumably RDAP lookups) will 
be for the large established TLDs, so a table built into the client will 
probably handle 90% or more of RDAP requests. For TLDs not in the table, 
an RDAP redirector can be used and a smart client can cache the 
redirected url for future lookups. As new TLDs come on line, it will 
take some time before they have a large number of registered domains. If 
the clients update their tables once a year they will continue to handle 
the majority of RDAP requests from the url table without falling back to 
the redirector.

In this scenario, I wouldn't necessarily expect names providers to 
provide redirects to other TLDs. It would be up to the client to use the 
correct url or else use the redirector.

The redirector should not have to handle a lot of requests. If 'lazy 
programmers' don't use a lookup table and just use the redirector for 
every request, the redirector can use rate limiting.

-Ernie

---

From: "John R Levine" <[email-masked]>
Date: 16 Jul 2013 12:43:40 -0400

> 1) all RDAP servers must be either http or https (http with redirect to https 
> where necessary may address this adequately)

Agreed.  I was previously arguing that everyone should use https, but 
people with more https experience than me persuaded me otherwise.

CA management is mess, particularly when you expect to have servers 
managed by hundreds of different organizations in every country of the 
world.  SSL failures will be frequent, due to either config errors or 
clients not knowing about a server's favorite CA.

Someone also noted that a later extension to add signatures to the JSON 
return values would not be hard, either what JOSE is doing or something 
much simpler with a signed hash of a canonicalized JSON string.

> 2) in a production environment it adds great flexibility to be able define a 
> service with a url path.

In an Apache web server it is literally a minute's work to create server 
config rules to rewrite URLs to map into whatever crufty underlying 
structure you want.  I've done it more times than I can remember.  Ditto 
Nginx.  Ditto lighttpd.  Ditto application level frameworks like Werkzeug.

What kind of web servers do registries use that can't do that?

R's,
John

---

From: MICHAEL YOUNG <[email-masked]>
Date: Tue, 16 Jul 2013 12:51:07 -0400

Has everyone looked the ICANN proposal for centralized RDDS for Registries and Registrars (GTLDs)?  Seems like a contributing factor to this discussion.

This would just leave the ccTLDs running their own Whois.

-Michael

On 2013-07-16, at 12:24 PM, Ernie Dainow <[email-masked]> wrote:

>> For numbers, it's basically what I said two messages ago, point your client at your RIR and it'll redirect you.
>> 
>> For names, there is an enormous amount of WHOIS traffic to Verisign, large amounts to Afilias and maybe Neustar and a trickle to everyone else.  An http bootstrap means that the bootstrap has to handle an RDAP load as great as Verisign's since they'll potentially be doing a redirect in front of every lookup.  (Web caches don't help unless you expect people to be making the exact same query over and over.)  While IANA has said they could do it if we asked them to, that seems like a lot of infrastructure for very little gain relative to a DNS bootstrap.
>> 
>> Also, given the financial stakes in the domain community, a third party server that knows all or most of the RDAP queries people are making is going to have a bullseye painted on it, both to DoS and even more to steal the logs.  A DNS bootstrap avoids those.
>> 
>> Finally, in case it's not obvious, I see no reason that numbers and names need the same bootstrap.  The questions and answers are different (some overlap, but basically different) and a different bootstrap is no big deal so long as it's simple.  Yes, I know it makes the client a smidgen more complex.
>> 
> 
> The DNS solution seems simple from the client side, where the client simply uses
> However, this solution has limitations because the server cannot be configured with a general url path.
> 1) all RDAP servers must be either http or https (http with redirect to https where necessary may address this adequately)
> 2) in a production environment it adds great flexibility to be able define a service with a url path.
> 
> It is not clear that the DNS solution is worth giving up the flexibility of the url path. A url table for names is not so very different from a url table for numbers. While there are many more providers for names, the large bulk of registered domains (and presumably RDAP lookups) will be for the large established TLDs, so a table built into the client will probably handle 90% or more of RDAP requests. For TLDs not in the table, an RDAP redirector can be used and a smart client can cache the redirected url for future lookups. As new TLDs come on line, it will take some time before they have a large number of registered domains. If the clients update their tables once a year they will continue to handle the majority of RDAP requests from the url table without falling back to the redirector.
> 
> In this scenario, I wouldn't necessarily expect names providers to provide redirects to other TLDs. It would be up to the client to use the correct url or else use the redirector.
> 
> The redirector should not have to handle a lot of requests. If 'lazy programmers' don't use a lookup table and just use the redirector for every request, the redirector can use rate limiting.
> 
> -Ernie
> 
> 

MICHAEL YOUNG
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 16 Jul 2013 16:56:24 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Has everyone looked the ICANN proposal for centralized RDDS for Registries and Registrars
>(GTLDs)?  Seems like a contributing factor to this discussion.
>

You're right, but since there are over 200 ccTLDs, I don't see a
bootstap issue for 200 TLDs as very different from 2000.

Also, it will be years if ever before the RDDS happens, but many of
the new TLD applicants say in their application that they'll implement
WEIRDS if we get it done.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 16 Jul 2013 13:20:02 -0400

Le 2013-07-16 à 12:51, MICHAEL YOUNG <[email-masked]> a écrit :

> Has everyone looked the ICANN proposal for centralized RDDS for Registries and Registrars (GTLDs)?  

yes.

> Seems like a contributing factor to this discussion.

right, we need to make sure (however, the work is still preliminary) that our bootstrap works in this context but also works with a) the current context (in case it does not go anywhere), b) with other tlds (cctlds). btw, both dns-based and IANA-registries based approaches work.  
I have one slide discussing this for our bootstrap discussion. 

Marc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Jul 2013 13:22:56 -0400

> Has everyone looked the ICANN proposal for centralized RDDS for Registries and Registrars (GTLDs)?  Seems like a contributing factor to this discussion.

If by "contributing factor" you mean "something to point and laugh
at", I would agree.

Not to put too fine a point on it, the evidence from ICANN's
performance with the recent TAS and other data projects (the
automation of the root zone registry is another one, although it was
nothing like the dramatic failure of the TAS) suggests that database
operations is not ICANN's strongest suit.  Also, while WEIRDS actually
can provide a mechanism for all old whois clients to continue working,
the centralized RDDS proposal breaks the entire world in one go.
Except, of course, for some ccTLDs.  What a wonderful idea.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 16 Jul 2013 10:26:30 -0700

> still explore more advanced search functionality in draft-zhou as we see
I provided a reply as an individual on this, but I've been the only one.
Can others weigh in?  We need to decide on a path forward, but so far I'm
the only respondent, which is hardly consensus.

Thanks,
-MSK

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 16 Jul 2013 13:32:32 -0400

my take: 
- search is complex, so it warrants a separate document that might progress at a different speed.
- the remaining question to me is how much of a basic search capability should we put in the base document that is a MUST or a SHOULD. If it becomes a MAY, then there is no point in having it in the base document.
- basic search is not really a client issue. it is a server issue. So I would like to get opinions on the server guys about this.

Marc.

Le 2013-07-16 à 13:26, "Murray S. Kucherawy" <[email-masked]> a écrit :

> On Tue, Jul 9, 2013 at 4:51 AM, Hollenbeck, Scott <[email-masked]> wrote:
> I provided a reply as an individual on this, but I've been the only one.  Can others weigh in?  We need to decide on a path forward, but so far I'm the only respondent, which is hardly consensus.
> 
> Thanks,
> -MSK

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 17 Jul 2013 11:42:40 +0800

If query combines with search document, will the response draft also need to
add a section about search response? 

Will it also have an impact on http, not sure.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marc Blanchet
Sent: Wednesday, July 17, 2013 1:33 AM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [weirds] WGLC: draft-ietf-weirds-rdap-query-05

my take: 

- search is complex, so it warrants a separate document that might progress
at a different speed.

- the remaining question to me is how much of a basic search capability
should we put in the base document that is a MUST or a SHOULD. If it becomes
a MAY, then there is no point in having it in the base document.

- basic search is not really a client issue. it is a server issue. So I
would like to get opinions on the server guys about this.

Marc.

On Tue, Jul 9, 2013 at 4:51 AM, Hollenbeck, Scott <[email-masked]>
wrote:

This brings up a larger point: we still haven't made a decision about how to
document search functionality. rdap-query punts it to a document that didn't
exist when we first wrote rdap-query. Now we have
draft-hollenbeck-weirds-rdap-search and
draft-zhou-weirds-rdap-restful-search, but neither is a working group
document. If we agree that basic search functionality needs to be documented
we need to decide what it is and where it gets described. I don't think we
can push rdap-query to IETF last call until we make a decision.

My suggestion: either add the functions described in
draft-hollenbeck-weirds-rdap-search to rdap-query or adopt rdap-search and
reference it. I tend to favor the former because it reduces the document
count and puts a core set of client-sent commands in one place. We can still
explore more advanced search functionality in draft-zhou as we see fit.

Thanks,

-MSK

---

From: Johan Åhlén <[email-masked]>
Date: Wed, 17 Jul 2013 10:06:28 +0200

On 16 Jul 2013, at 16:27, John R Levine <[email-masked]> wrote:

> On the numbers side, it seems unlikely that there will be any bootstrap more complex than point your client at your local RIR or maybe use a lookup table you downloaded one time, and hope for the best, so I agree it's not a big deal there.

I agree with this, coming from an RIR background I know for sure that we know which resources are managed by which RIR. If a client would query RIPE for an ARIN resource the RIPE service could redirect to ARIN straight away and vice versa. Here are some benefits I can think of:

- No need for bootstrap or lookup tables on the client side
- No need for an additional Redirection Service
- It doesn't matter which RIR you point the client to
- Client can't get more simple, you can even use wget for number queries

Regards,

Johan Åhlén

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Jul 2013 13:45:10 +0000

> Behalf Of Hollenbeck, Scott
> Sent: Tuesday, July 16, 2013 10:46 AM
> To: Andy Newton; [email-masked]
> Both John Levine and Ernie Dainow have asked about registrar lookups by
> name, which we don't describe in rdap-query. In both cases I've pointed
> them to rdap-search, which isn't a WG draft.
> 
> This type of lookup is a currently supported feature for .com and .net.
> I didn't check other TLDs so I don't know if others do it, too. I also
> don't know how many such queries Verisign receives, but I have someone
> looking into it.

Hard data: during one 24-hour period in December 2012, Verisign processed 180 million WHOIS queries across 4 resolution sites. 120,412 of those 180 million queries were for registrar names.

---

From: "John Levine" <[email-masked]>
Date: 17 Jul 2013 16:25:43 -0000

>add a section about search response? 

I would think so.  It'd need to describe how to return multiple
results, probably as a JSON array, and some codes to describe what
happened, e.g., all matches returned, some matches returned, nothing
matched.

R's,
John

---

From: Ernie Dainow <[email-masked]>
Date: Thu, 18 Jul 2013 13:33:19 -0400

OK, redirecting a url at the web server is not a big concern. Defining a
service by a name instead of an IP address is more of the flexibility
issue.

In a production environment, moving a service from one server to another
often requires changing the IP address. This is typically done in a
maintenance window, say 2 hours at a planned date and time. If Operations
must rely on a third party to reconfigure the DNS, they have less control
in a tight timeframe. All maintenance changes also require a backout plan,
so that if unanticipated problems are encountered, the maintenance can be
aborted. This might require the DNS be reconfigured back to the original IP.

To address these concerns, a DNS bootstrap should support CNAMES, not just
A/AAAA records. A provider would register a generic name that would never
require changing and then would have control over configuring the IP
address.

-Ernie

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2013 14:39:23 -0400

> require changing and then would have control over configuring the IP

Well,  sure.  That was always the plan as far as I know.

> maintenance window, say 2 hours at a planned date and time. ...

RDAP is a stateless read-only service.  I would think it would be easier 
and more robust to bring up the new server in parallel with the old one, 
point the DNS at it, then wait and turn off the old one when the traffic 
dies down.  This avoids having to do flash cutovers which work badly on 
the Internet.

R's,
John

---

From: Ernie Dainow <[email-masked]>
Date: Thu, 18 Jul 2013 15:51:08 -0400

> Well,  sure.  That was always the plan as far as I know.

The last few messages on this included only A/AAAA records, and CNAME is
not in the last  requirements list.

> dies down.  This avoids having to do flash cutovers which work badly on the
> Internet.
>
>
> Yes, you must run the old server for at least as long as the TTL on the
DNS record. Once TTL expires, nobody is going to be trying to reach the old
IP (unless some client is using hard coded IP addresses instead of DNS
names).

This doesn't change the maintenance issue. Generally customers need to be
informed in advance of changes in service, so you have to change the IP
address at a scheduled time and be prepared to roll back on short notice.

-Ernie