Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt

From: [email-masked]
Date: Mon, 26 Nov 2012 09:21:21 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF.

	Title           : Unified Registration Data Access Protocol Query Format
	Author(s)       : Andrew Lee Newton
                          Scott Hollenbeck
	Filename        : draft-ietf-weirds-rdap-query-01.txt
	Pages           : 11
	Date            : 2012-11-26

Abstract:
   This document describes uniform patterns to construct HTTP URLs that
   may be used to retrieve registration information from registries
   (including both Regional Internet Registries (RIRs) and Domain Name
   Registries (DNRs)) using "RESTful" web access patterns.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-query-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 26 Nov 2012 17:25:13 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Monday, November 26, 2012 12:21 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt
> 
> 

This version of the document is mostly complete (or so Andy and I think) with the exception of the Security Considerations section. I'll address that deficiency after we make decisions about the text in the new security considerations draft. I'll post rdap-sec-01 shortly.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2012 12:08:01 -0500

(Apologies in advance - I'm using a new mail client and fear that my formatting options are properly set.  If there's a problem seeing this, let me know.)

Comments on this document:

Overall I like this.  It's simple and enforces the idea that there are only five kinds (IP addresses, AS numbers, domain names, name servers and entities) of things that this protocol is supposed to be covering.  I had a problem with the idea that name servers would be in the list until I thought about the need to check a name server's address when it was used in a different registry (like inspecting this from the tld. registry "company.tld. NS ns1.dns.example."  might drive me to need the ns1.dns.example. address records from the example. registry.)

My two items here are basically nits.  The first is driven by wanting to avoid talking about what a technical standards body does and does not do.  And the second is to "put units" on two numbers.

> 	Filename    : draft-ietf-weirds-rdap-query-01.txt

Item #1:

This paragraph at the end of section 2 is well-intended but not quite worded properly.
   While HTTP contains mechanisms for servers to authenticate clients
   and for clients to authenticate servers (from which authorization
   schemes may be built), both authentication of clients and servers and
   authorization for access to data are out-of-scope of this document.
   In general, these matters require "policy" and are not the domain of
   technical standards bodies.

I'll suggest this:

HTTP contains mechanisms for servers to authenticate clients and for clients to authenticate servers (from which authorization schemes may be built) so such mechanisms are not described in this document.  Policy, provisioning, and processing of authentication and authorization are out-of-scope for this document as deployments will have to make choices based on local criteria.  So long as the solution chosen makes use of the HTTP mechanisms, implementations ought to be interoperable.
I'm avoiding this as it sounds a bit like lecturing on the structure of the Internet "standards" bodies:
In general, these matters require "policy" and are not the domain of technical standards bodies.
Item #2:
3.1.  IP Network Path Segment Specification

...
   a CIDR block with a length of 32 for IPv4 and a length of 128 for

s/length/bitmask length/g
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions and responses.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 27 Nov 2012 17:12:26 +0000

Thanks for the feedback, Ed. No disagreement from me on either point - and thanks for sending text.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Edward Lewis
Sent: Tuesday, November 27, 2012 12:08 PM
To: [email-masked]
Cc: Edward Lewis
Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt

On Nov 26, 2012, at 12:21, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Item #1:

I'll suggest this:

...

---

From: "John Levine" <[email-masked]>
Date: 28 Nov 2012 03:31:51 -0000

I agree this is mostly done, at least for RIRs, except for the
crufty bits around the edges.

Section 3: it looks to me like each URL can contain only one resource
type path segment. Are these wrong?  If not, what do they mean?

http://foo.example/weirds/ip/1.2.3.4/ip/2002::123
http://foo.example/weirds/domain/bar.example/ip/2002::123

End of section 4: "Servers SHOULD ignore unrecognized path segments."

What should a server do with these?

http://foo.example/weirds/custom_crud/fooble/parp/ip/1.2.3.0/24
http://foo.example/weirds/ip/1.2.3.0/24/custom_crud/fooble/parp

Since a path segment can contain a variable number of slashes, how can
a server do anything but fail the entire request, since it can't tell
where to start looking for the next segment?

Nit: top of page five, rather than "lowest IP network" say "smallest
IP network".  A sufficiently perverse reader might interpret lowest IP
network to be the network with the lowest base address which is
exactly wrong.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Wed, 28 Nov 2012 13:17:58 +0000

>http://foo.example/weirds/domain/bar.example/ip/2002::123

They are wrong.

>http://foo.example/weirds/custom_crud/fooble/parp/ip/1.2.3.0/24

If it understands custom_crud and the rest of that path looks correct,
then answer the query.
Otherwise send back a 400.

>http://foo.example/weirds/ip/1.2.3.0/24/custom_crud/fooble/parp

This is just wrong. Send a 400.

>network to be the network with the lowest base address which is

Agreed.

-andy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Nov 2012 09:04:46 -0500

On Nov 27, 2012, at 22:31, John Levine wrote:

> type path segment. 

I believe that is the intention.  I say "believe" because I can't find any requirement statement on this, but I do recall reading that the intent was for a one-object query and response protocol.  I'm not claiming consensus on that belief, I mean to comment to ask if that is the consensus.

Technically, I doubt that we could accommodate multiple questions in a query.  If we did pipelining or otherwise piggybacking questions in a query, we'd complicate the response language.  (I.e., having an answer for one object and a referral to another.)  [Once again a lesson from DNS: this is a design problem in DNS, the query can handle multiple questions but the response can contain only one response code.]

There are no answers - just tradeoffs, decisions, and responses.

---

From: "John R Levine" <[email-masked]>
Date: 28 Nov 2012 10:12:16 -0500

Looks like we agree.  Proposed text changes:

Section 3 old:

   The base URL will be appended with resource type specific path segments.

new:

   The base URL is followed by a resource type specific path segment.

Section 4 old:

   Servers SHOULD ignore unrecognized path segments.

new

   Servers MUST return an appropriate failure status code for
   a request with an unrecognized path segmenst.

I say MUST because it's important for for interop that clients are able to 
tell reliably that a request hasn't worked.

R's,
John

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 28 Nov 2012 15:18:16 +0000

> Behalf Of John R Levine
> Sent: Wednesday, November 28, 2012 10:12 AM
> To: Andy Newton
> Cc: [email-masked]
> I say MUST because it's important for for interop that clients are able
> to tell reliably that a request hasn't worked.

I'm OK with these changes.

Scott

---

From: Andy Newton <[email-masked]>
Date: Wed, 28 Nov 2012 15:53:29 +0000

>I'm OK with these changes.

+1

-andy

---

From: "John Levine" <[email-masked]>
Date: 28 Nov 2012 16:12:38 -0000

>Technically, I doubt that we could accommodate multiple questions in a query.

Pipelining already exists in http/1.1, send a series of requests, get
a series of responses.  I can't see any benefit in reinventing it inside
WEIRDS.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Nov 2012 11:30:58 -0500

I was referring to pipelining in the protocol under design.  As in (from the examples earlier in the thread):

Would implicate pipelining a request for 1234, then 2002::123...yes, not desired.

If there's sublayer shenanigans going on, the documents can ignore them - unless said shenanigans are a problem.

On Nov 28, 2012, at 11:12, John Levine wrote:

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: "John Levine" <[email-masked]>
Date: 28 Nov 2012 19:06:37 -0000

>Would implicate pipelining a request for 1234, then 2002::123...yes, not desired.

I think we're agreeing.  If a client wants to pipeline those two requests,
it can use existing http/1.1 pipelining to send

http://foo.example/weirds/ip/1.2.3.4

http://foo.example/weirds/ip/2002::123

and the server will pipeline the responses back as two separate HTTP
responses.  This already exists, libraries support it, nothing we need
to do about it either way.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 29 Nov 2012 16:12:36 -0800

What's missing for the names case?

---

From: "John R Levine" <[email-masked]>
Date: 29 Nov 2012 20:27:54 -0500

> What's missing for the names case?

The short answer is that nobody knows, since different TLDs accept varying 
sets of queries, and ICANN has a process going on where they're trying to 
figure out what else people want for WHOIS in the new TLDs.  Some whois 
servers accept wildcards for some or all queries, some don't, most provide 
for search by registrar and full vs. summary reports.

Here's the specs for WHOIS for the ICANN contracted TLDs.  Often the 
language is almost but not quite the same from one TLD to the next.

http://www.icann.org/en/about/agreements/registries/aero/aero-appendix-5-11jun09-en.htm
http://www.icann.org/en/about/agreements/registries/asia/appendix-s-06dec06-en.htm#6
http://www.icann.org/en/about/agreements/registries/biz/appendix-05-08dec06-en.htm
http://www.icann.org/en/about/agreements/registries/cat/cat-appendixs-22mar06-en.htm (part vi)
http://www.icann.org/en/about/agreements/registries/verisign/appendix-05-01mar06-en.htm
http://www.icann.org/en/about/agreements/registries/coop/appendix-s-01jul07-en.htm#part5
http://www.icann.org/en/about/agreements/registries/info/appendix-05-08dec06-en.htm
http://www.icann.org/en/about/agreements/registries/jobs/appendix-s-06aug10-en.htm#Part6
http://www.icann.org/en/about/agreements/registries/mobi/mobi-appendixs-23nov05-en.htm (part 6)
http://www.icann.org/en/about/agreements/registries/museum/appendix-05-03nov07-en.htm
http://www.icann.org/en/about/agreements/registries/name/appendix-05-15aug07-en.htm
http://www.icann.org/en/about/agreements/registries/net/appendix-5-01jul11-en.htm
http://www.icann.org/en/about/agreements/registries/org/appendix-05-08dec06-en.htm
http://www.icann.org/en/about/agreements/registries/post/post-appendix-s-11dec09-en.htm (part VI)
http://www.icann.org/en/about/agreements/registries/pro/pro-appendix-5-22apr10-en.htm
http://www.icann.org/en/about/agreements/registries/tel/appendix-s-02feb11-en.htm#Part6
http://www.icann.org/en/about/agreements/registries/travel/travel-appendix-s-12apr06-en.htm#part6
http://www.icann.org/en/about/agreements/registries/xxx/appendix-s-31mar11-en.htm (part 6)

The ccTLDs have their own requirements, as does IANA for the TLDs it 
manages (arpa and int).

This is one of the reasons why I pushed back so hard against coupling the 
numbers and names WEIRDS designs.  The people who want names need to 
figure this out and come up with at least an approximate set of query 
types and terms, but I haven't seen much progress in that regard.

Regards,

---

From: Byron Ellacott <[email-masked]>
Date: Fri, 30 Nov 2012 07:25:56 +0000

Hi John,

>for search by registrar and full vs. summary reports.

The current drafts only provide for lookups, not searches; this isn't part
of the charter, but I do seem to recall that it was discussed at some
point with an agreement at the time that searches should come later.

It's a useful simplification, since even in the numbers world the possible
search terms and query modes widen up quite dramatically when you move
away from simple lookup.

>types and terms, but I haven't seen much progress in that regard.

http://tools.ietf.org/html/draft-zhou-weirds-dnrd-ap-object-inventory is a
decent effort at the lookup side of this, by identifying the result terms
and by implication the object types.

  Byron

---

From: Edward Lewis <[email-masked]>
Date: Fri, 30 Nov 2012 09:11:15 -0500

On Nov 29, 2012, at 20:27, John R Levine wrote:
> 
> Here's the specs for WHOIS for the ICANN contracted TLDs.  Often the language is almost but not quite the same from one TLD to the next.
> ...
> The ccTLDs have their own requirements, as does IANA for the TLDs it manages (arpa and int).

This soapbox statement is driven by the concern that we sometimes seem to think that our requirements is to cover all of ICANN's requirements or to cover all current functionality across the board, or to just do something that works well in HTTP.  Each time specs and requirements of existing deployments are raised we need to recall whether or not we want to support what we see.   It would be good to document, as in something we can reference, the boundaries of what is to be solved and what is left off.

In as much as we say that the protocol under development in the WEIRDS WG is a replacement for WhoIs, it is a protocol that has its own set of requirements.  In that vein it doesn't really matter what WhoIs does in aggregate today.  What matters is that "this time" we get a directory lookup protocol that does the job right - more right that is, in the technical sense.  That's my opinion, not a WG statement.

It is worth doing a survey of existing implementations for ideas and to build up an idea of what should be included and what should be excluded from this protocol.  Research is good.  But that doesn't mean we have to (as in MUST) replicate all of features identified.

Down the road the regulator overseeing a TLD (not necessarily the operator) will consider the specification of this new protocol.  They may consult with the operator to make a decision on whether to deploy.  Perhaps the new protocol lacks a feature required by the regulator.  In that case they have three options.  Stick with the WhoIs as is and not deploy.  Deploy this protocol and retain the WhoIs service.  Extend the definition of this protocol to add the feature, staying with in the guidelines for extending this protocol.

The "success" of WEIRDS, in my opinion, is measured by the number of registries that ultimately deploy this new protocol, hopefully "right out of the box" or following the third choice above.

---

From: "John Levine" <[email-masked]>
Date: 30 Nov 2012 15:12:48 -0000

> The "success" of WEIRDS, in my opinion, is measured by the number of
> registries that ultimately deploy this new protocol, hopefully "right
> out of the box" or following the third choice above.

If it can't do all the stuff required by those ICANN contracts, how
likely do you think that will be?

R's,
John

---

From: Edward Lewis <[email-masked]>
Date: Fri, 30 Nov 2012 10:58:06 -0500

> likely do you think that will be?

(realizing that this is a very obtuse thread of conversation)

I assume you are asking "if the new protocol can't support each and every feature in the current union of ICANN contracted WhoIs servers, what chance does the new protocol have of displacing the existing WhoIs services?"

There are people on this list more aware of what ICANN wants than I.  They can answer this.

I don't know if each and every feature required in a current contract has to be in the new protocol, as far as ICANN is concerned.  What is apparent is that ICANN is dissatisfied with the current state of WhoIs and has asked the IETF to make something better.

...and ICANN is not the only consumer for this new protocol...

---

From: Andy Newton <[email-masked]>
Date: Fri, 30 Nov 2012 16:38:06 +0000

From: Edward Lewis <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 30, 2012 10:58 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Edward Lewis <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-...

I agree with this 100%. And I don't feel we should just stop work until such a time as ICANN is more clear about their desires.

-andy

---

From: "John Levine" <[email-masked]>
Date: 30 Nov 2012 23:48:03 -0000

>I don't know if each and every feature required in a current contract has to be in the new protocol, as
>far as ICANN is concerned.  What is apparent is that ICANN is dissatisfied with the current state of WhoIs
>and has asked the IETF to make something better.

FYI, the new .COM agreement published today says that ICANN can tell
Verisign to switch from thin to think WHOIS, or to provide whatever
WEIRDS comes up with so long as it's published as a draft standard and
is "commercially reasonable in the context of the overall operation of
the registry".  So it's still up to ICANN to decide what they want.

>I agree with this 100%. And I don't feel we should just stop work until such a time as ICANN is more clear

Agreed.  Given the limited interest shown by the names community here
(just Ed and Scott as far as I can tell), it makes sense to go ahead
with the numbers stuff.