Subject: [weirds] draft-newton-et-al-weirds-rir-query-00

From: Andy Newton <[email-masked]>
Date: Wed, 21 Sep 2011 15:25:57 +0000

Arturo, Kaveh and I have put together a new draft for a common RIR URL scheme:

http://www.ietf.org/id/draft-newton-et-al-weirds-rir-query-00.txt

Comments welcomed.

-andy

---

From: Nikolay Shopik <[email-masked]>
Date: Wed, 21 Sep 2011 20:47:24 +0400

Hi Andy,

Section 2. says about path specification, but doesn't say how client 
will locate such path. By which I mean different RIR will clearly could 
go with different path, and may do changes in time to this path, 
hardcoding this path in client isn't best solution.

Or this will be covered in another draft?

Please excuse my ignorance on topic.

Thanks

On 21.09.2011 19:25, Andy Newton wrote:
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 21 Sep 2011 18:58:52 +0200

> http://www.ietf.org/id/draft-newton-et-al-weirds-rir-query-00.txt

I'm unable to understand the need for the rDNS type of query.  How is
/rdns/2.0.192.in-addr.arpa different from /ip/192.0.2?  Possibly, the
latter could allow CIDR notation, e.g. /ip/192.0.2/24. Optional and
numeric, it allows any combination, e.g.:

  http://example.com/somepath/ip/192.0.2.0/operator
  http://example.com/somepath/ip/192.0.2.0/24/operator
  http://example.com/somepath/ip/192.0.2/24/operator
  http://example.com/somepath/ip/192.0.2.80/26/operator
  http://example.com/somepath/ip/192.0.2.80/26

With respect to the "quick fix using DNS", this one can certainly
serve more structure.  However, it misses some way of discovering the
"example.com" and "somepath" parts.

For a typo, s/maybe/may be/ in its only occurrence.

---

From: Andy Newton <[email-masked]>
Date: Wed, 21 Sep 2011 17:00:34 +0000

On Sep 21, 2011, at 12:47 PM, Nikolay Shopik wrote:

> Section 2. says about path specification, but doesn't say how client will locate such path. By which I mean different RIR will clearly could go with different path, and may do changes in time to this path, hardcoding this path in client isn't best solution.

>From the first paragraph of Section 2:

   The uniform patterns start with a base URL specified by each RIR or
   any other service provider offering this service.

That means the RIRs will have to publish their base URLs.

It also implies that a person of entrepreneurial spirit could go grab the IANA allocations of IP addresses and AS numbers, implement a server that issues HTTP Redirects for the given queries, and let it be known that they provide such a service.

-andy

---

From: Andy Newton <[email-masked]>
Date: Wed, 21 Sep 2011 17:26:32 +0000

On Sep 21, 2011, at 12:58 PM, Alessandro Vesely wrote:

> /rdns/2.0.192.in-addr.arpa different from /ip/192.0.2?  

It separates the queries for "when was this network registered, etc..." from "how is the reverse put together?" Perhaps "registration" under /rdns needs some clarification on that point.

> Possibly, the
> latter could allow CIDR notation, e.g. /ip/192.0.2/24.

Once you get into CIDR notation in queries, there are multiple issues to deal with. One is what are the matching semantics? Exact, more, less? Additionally, some network registrations do not neatly fall into a CIDR boundary and therefore results can be confusing. The vast majority of Whois queries (at least of ARIN) are straight IP lookups.

Also note that CIDR queries can easily yield more than one answer, and that all the queries in the document are intended to generate either one or no result.

> "example.com" and "somepath" parts.

See my response to Nikolay.

-andy

---

From: Nikolay Shopik <[email-masked]>
Date: Wed, 21 Sep 2011 21:26:44 +0400

> It also implies that a person of entrepreneurial spirit could go grab the IANA allocations of IP addresses and AS numbers, implement a server that issues HTTP Redirects for the given queries, and l…

We understand IANA have no more allocation in IPv4 so it more like one 
time work, but not for IPv6.

What I thinking was is some kind DNS query which helps detect URL or 
just subdomain at least, to help redirect request to proper server.

---

From: Andy Newton <[email-masked]>
Date: Wed, 21 Sep 2011 17:40:06 +0000

On Sep 21, 2011, at 1:26 PM, Nikolay Shopik wrote:

> We understand IANA have no more allocation in IPv4 so it more like one time work, but not for IPv6.

I doubt keeping up with the IANA IPv6 block allocations will be a daunting task.

And it is possible that ICANN could be sweet-talked into hosting such a service, especially since they seem keen on this RESTful idea too.

> What I thinking was is some kind DNS query which helps detect URL or just subdomain at least, to help redirect request to proper server.

I'm familiar with such things: IRIS did it; my name is on the S-NAPTR RFC; etc... However, such DNS infrastructure always seems to become a deployment liability rather than a clean solution. A lot of programmers really just want to deal with the HTTP client libraries they know and love, and such libraries will likely never contain the necessary DNS knowledge to accomplish this.

-andy

---

From: Nikolay Shopik <[email-masked]>
Date: Wed, 21 Sep 2011 22:11:29 +0400

> I'm familiar with such things: IRIS did it; my name is on the S-NAPTR RFC; etc... However, such DNS infrastructure always seems to become a deployment liability rather than a clean solution. A lot…

Fair enough. This is just require programmer to release new versions 
when there new allocations, as we having this with current WHOIS, which 
I would like to avoid and make it robust.

And from my point of view rollout new DNS record (i didn't read S-NAPTR 
RFC yet) much easier than doing new HTTP server rollout because of load 
(just random example). And I barely believe this add lot complexity, 
maybe I'm wrong?

It's just we have hierarchical DNS system, why not make use of it, same 
as IANA->RIRs->ISPs. And IANA could fill allocation in their DNS zone, 
just saying.

---

From: Andy Newton <[email-masked]>
Date: Wed, 21 Sep 2011 18:27:45 +0000

On Sep 21, 2011, at 2:11 PM, Nikolay Shopik wrote:

> Fair enough. This is just require programmer to release new versions when there new allocations, as we having this with current WHOIS, which I would like to avoid and make it robust.

While some Whois clients do have some knowledge of the IANA allocations, a lot of them simply query ARIN first and the assume a referral based on the output. ARIN does keep up with the IANA block allocations.

This is also possible with the RESTful interface. ARIN or LACNIC or the RIPE NCC could issue HTTP redirects to other RIRs based on their knowledge of IANA block allocations.

> And from my point of view rollout new DNS record (i didn't read S-NAPTR RFC yet) much easier than doing new HTTP server rollout because of load (just random example). And I barely believe this add lot complexity, maybe I'm wrong?
> 
> It's just we have hierarchical DNS system, why not make use of it, same as IANA->RIRs->ISPs. And IANA could fill allocation in their DNS zone, just saying.

I hear you. But not all programmers have access to the same tools you do. Nearly all of them can get their hands on an HTTP client library, but advanced DNS libraries are not that wide spread.

-andy

---

From: Arturo Servin <[email-masked]>
Date: Wed, 21 Sep 2011 18:41:44 -0300

Nikolay,

	I am not sure if I understand your question. We are not defining the answer yet for a query, but for example if you query RIR-x whois with a resource (IPv4, ASN or IPv6) which is not in the RIR-x pool the reply can have a re-direct field to the proper RIR (left-right) or the the top level (down-top), which is IANA. Then a query to IANA would have the redirect to the proper RIR (up-down).

	Regarding use of DNS, I would prefer to keep this our of DNS transport and to use only http.

Regards,
.as

---

From: Arturo Servin <[email-masked]>
Date: Wed, 21 Sep 2011 18:44:45 -0300

I meant "out of DNS transport".

.as

---

From: Leo Vegoda <[email-masked]>
Date: Wed, 21 Sep 2011 16:06:52 -0700

On Sep 21, 2011, at 11:11 am, Nikolay Shopik wrote:

[…]

> I would like to avoid and make it robust.

Not just a new version, but for everyone using it to install the new version. History shows that static configurations that need to manually be updated don't work well. I think that requiring a software update following an allocation event in an IANA registry is a bad idea. 

Regards,

Leo

---

From: "John Levine" <[email-masked]>
Date: 22 Sep 2011 05:21:28 -0000

>It also implies that a person of entrepreneurial spirit could go grab
>the IANA allocations of IP addresses and AS numbers, implement a
>server that issues HTTP Redirects for the given queries, and let it
>be known that they provide such a service.

You're not thinking like a lazy PHP programmer.  You just send the
same query to all the RIR and country registries, and pick the one
that doesn't 404.  Oh, are all those bogus queries a problem?  Well,
it's not MY problem.

It seems to me that if we're going to go to the effort to invent
something like this, it's worth figuring out a way to provide a
consistent namespace.

So long as we could persuade the RIRs to use consistent URLS, we lazy
non-PHP programmers would be inclined to do it in the DNS.  Assuming
the stuff is all at URLs like, say,

  http://<somehost>/ip/n.n.n.n/whatever

We could route stuff with rDNS style CNAMEs:

*.2.restwhois.net CNAME restful.ripe.net   ; 2/8 allocated to RIPE

*.202.restwhois.net CNAME restful.apnic.net ; 202/8 allocated to APNIC
*.0.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
*.1.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
*.2.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
*.3.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
*.4.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
*.5.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
*.6.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
*.7.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
*.8.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
*.9.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
*.10.123.202.restwhois.net CNAME restful.afrinic.net ; 202.123/19 to Afrinic
etc.

So then your URL is

  http://<d>.<c>.<b>,<a>.restwhois.net/ip/<a>.<b>.<c>.<d>/whatever

If we believe that web servers can see the URL, we can even leave the
IP address out of the local part.

R's,
John

PS: Yes, it's a kludge. It's no worse than a lot of other stuff.

---

From: Kaveh Ranjbar <[email-masked]>
Date: Thu, 22 Sep 2011 09:29:26 +0200

On 9/21/11 6:58 PM, Alessandro Vesely wrote:
...
> "example.com" and "somepath" parts.
...

Hello,

I see two different requirements here:

a) Discovery of "example.com" and "somepath" parts for any registry.
For this requirement, there are different technical solutions, an
example is use of UDDI. We can simply put together a public UDDI
Registry which publishes service endpoints for any registry. Clients can
automatically access these data then. Obviously there are other
solutions as well. I agree that we have to consider the "lazy PHP
programmer" if we aim for wide spread adoption.

b) Finding the responsible Registry for a given resource. Though this
might look simple, it is a lot more complicated. There is Early
Registration Space as well as Inter-RIR Transfers among other things
which makes creating a universal registry, or a clean look-up list close
to impossible. RIR's are working to improve the situation, by both
cleaning up data and implementing new tools (one example in RIPE is GRS
Whois) but that's still work in progress.

Personally I think it is better to tackle one problem at a time. First
let's start with making the general queries to RIRs standard (which we
are working on), then we can think about making the response more
generic and finally we can discuss service discovery and IANA Delegation
resolving.

Regards,
Kaveh.

---

From: Nikolay Shopik <[email-masked]>
Date: Thu, 22 Sep 2011 13:40:46 +0400

Arturo,

If we could do proper redirection via HTTP I'm fine with that. I'm just 
propose DNS because it just seems fit here as hierarchical system and 
easy to maintain.

Detect right whois server is pain right now. New ccTLD introduced and I 
have to update my whois client, same apply for new ASN.

---

From: Nikolay Shopik <[email-masked]>
Date: Thu, 22 Sep 2011 13:44:28 +0400

> I hear you. But not all programmers have access to the same tools you do. Nearly all of them can get their hands on an HTTP client library, but advanced DNS libraries are not that wide spread.

My assumption was most people will use generic implementation of WIERDS 
client, instead of writing their own. Or something I misunderstood in 
your sentence?

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 22 Sep 2011 10:54:19 +0100

> http://www.ietf.org/id/draft-newton-et-al-weirds-rir-query-00.txt

This is breaks the HATEAOS constraint of REST and is thus not RESTful.

It's possible to make this RESTful by introducing URI templates[1] and a
resource--a service document--describing the URI patterns. Thus the
only URIs that need to be well-known are those of the service documents
detailing the URI templates for WEIRDS databases.

Introducing these two introduces only minimal overhead as clients can
cache the service document after it has been initially fetched. Clients
are thus decoupled from having to be hardwired for a particular URI
namespace and servers are free to modify the URIs for various resources
as fits their needs.

Omitting any namespace declarations, an example of a minimal service
document would look like this:

<?xml encoding="UTF-8"?>
<weirds>
  <service>
    <!-- Various metadata about the WEIRDS service -->
  </service>
    <ip>
      <registration template="ip/{ip}/registration"/>
      <operator template="ip/{ip}/operator">
        <contacts template="ip/{ip}/operator/contacts"/>
        <by-type template="ip/{ip}/operator/contacts/{type}"/>
      </operator>
    </ip>
    <authnum template="authnum/{authnum}">
      <registration template="authnum/{authnum}/registration"/>
      <operator template="authnum/{authnum}/operator">
        <contacts template="authnum/{authnum}/operator/contacts"/>
        <by-type template="authnum/{authnum}/operator/contacts/{type}"/>
      </operator>
    </authnum>
    <rdns template="domain/{dn}">
      <registration template="domain/{dn}/registration"/>
      <operator template="domain/{dn}/operator">
        <contacts template="domain/{dn}/operator/contacts"/>
        <by-type template="domain/{dn}/operator/contacts/{type}"/>
      </operator>
    </rdns>
  </service>
</weirds>

I did this up in XML just for demonstration purposes, but that's really beside
the point: the important thing here is that clients no longer
care what the URIs are and servers are free to implement the namespace
as suits them. Even then, something like the example document wouldn't be
that hard for even a lazy PHP programmer to deal with: XPath is hardly rocket
science.

The one thing I can see people being worried about here is that URI templates
are not yet in the RFC phase, but are still in the ID phase. I don't see that
as being much of a problem myself: RIR query ID can specify the minimal stable
subset of URI templates as I've given above--simple placeholders--and later
when the URI templates ID becomes an RFC (which is pretty much guaranteed to
happen), the spec can be updated to reference that instead.

On the topic of the 'Accept' header, I don't think it's up to us to have to
work around idiot HTTP intermediaries. We could end up filling up half the ID
with various workarounds for that, and it only duplicates something already
specified in HTTP itself unnecessarily. If clients have to work around broken
intermediaries, they're frankly better off bunging a safe cache buster onto
the end of the URI.

K.

[1] http://tools.ietf.org/html/draft-gregorio-uritemplate-06

-- 
Keith Gaughan, Senior Developer
PGP/GPG key ID: 3E896381
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Sep 2011 12:32:56 +0200

> This is breaks the HATEAOS constraint of REST and is thus not

With the help of Wikipedia I figured out that nobody "hates AOS".
I'm also confident that I won't try to implement this "just for
fun".  (But I guess others will like it.)

> when the URI templates ID becomes an RFC (which is pretty much
> guaranteed to happen), the spec can be updated

One caveat here (wrt a normative reference) is "don't hold your
breath", the work on URI templates started (at least) five years
ago. [1]

-Frank

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 22 Sep 2011 12:11:39 +0100

> fun".  (But I guess others will like it.)

Sorry, typo. Meant HATEOAS: http://en.wikipedia.org/wiki/HATEOAS

> breath", the work on URI templates started (at least) five years

Yep, hence my minimal stable subset suggestion. We needn't depend on the ID
becoming an RFC any time soon, but the *concept* of URI templates is separate
from any particular syntax. That the ID specifies is a particular syntax, and
a minimal subset of that--simple placeholders bound by '{' and '}'--is stable
and can be specified making reference only to RFC2396 (section 2.4) to
specify how the values ought to be escaped before they're embedded in the
string. Here's the code to implement that minimal subset in Python:

import re
import urllib

def replace(template, values):
    result = ""
    start = 0
    for match in re.finditer(r"\{([a-z_]+)\}", template):
        result += template[start:match.start(0)]
        key, = match.groups()
        if key in values:
            result += urllib.quote(values[key])
        start = match.end(0)
    result += template[start:]
    return result

That was typed off the top of my head, contains little or no error handling,
and may contain minor bugs. Caveat lector.

K.

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 22 Sep 2011 12:25:57 +0100

> and may contain minor bugs. Caveat lector.

Felt guilty about not checking it, so here's a shorter version using the
sub() function that I've actually verified is correct:

import re
import urllib

def replace(template, values):
    def on_match(match):
        key = match.group(1)
        if key in values:
            return urllib.quote(values[key])
        return ''
    return re.sub(r"\{([a-z_]+)\}", on_match, template)

---

From: Arturo Servin <[email-masked]>
Date: Thu, 22 Sep 2011 08:30:34 -0300

Nikolay.

	There is no WEIRDS client (or there are many already there). That's why I like http and not dns.

	The client is any http agent (wget, curl, webkit, urllib, etc.). 

	For me it wouldn't be very difficult to build a whois server and even some API in python/java using restful services. Whilst with DNS, I wouldn't know where to start for the server and for the client I would use shell scripts (or to dig in some python/java libs). I guess it is not very different for many others trying to produce/use data to/from whois.

Regards,
/as

On 22 Sep 2011, at 06:44, Nikolay Shopik wrote:

> My assumption was most people will use generic implementation of WIERDS client, instead of writing their own. Or something I misunderstood in your sentence?

---

From: Andy Newton <[email-masked]>
Date: Thu, 22 Sep 2011 11:38:18 +0000

> intermediaries, they're frankly better off bunging a safe cache buster onto

Interesting. What's your proposal for the cache busting? We reserve a query parameter for clients to put in a random value?

-andy

---

From: Andy Newton <[email-masked]>
Date: Thu, 22 Sep 2011 11:50:41 +0000

> PS: Yes, it's a kludge. It's no worse than a lot of other stuff.

Doesn't seem kludgy to me. I kinda like it.

But I don't see how it takes care of the autnum space. I guess we could have a zone allocated with every autnum in it, but that would be a huge zone.

However, my biggest question is that if you have taken the time to capture "restwhois.net" or some other well-known domain name, why not just run an HTTP server on that domain that issues redirects?

As for the lazy PHP programmer... I'm well use to them. As I mentioned early, in the port 43 world a lot of queries start at ARIN and end up at RIPE or LACNIC, etc.... That's because ARIN attempts to keep track of IANA allocations in its Whois, and client writers have taken that to mean they can imply referrals. There is nothing stopping this model going forward, although Kaveh's suggestion does improve upon it.

-andy

---

From: Nikolay Shopik <[email-masked]>
Date: Thu, 22 Sep 2011 16:26:31 +0400

Arturo,

Thanks for clearing this up for me. I had doubts and small 
misunderstanding what it will be "WEIRDS" client. So I have to write my 
own script to do output for me.

And now I understand your position, about building whois server.

---

From: "John R. Levine" <[email-masked]>
Date: 22 Sep 2011 09:36:13 -0400

> But I don't see how it takes care of the autnum space. I guess we could 
> have a zone allocated with every autnum in it, but that would be a huge 
> zone.

You could do the usual rDNS trick, divide the number into smaller pieces 
and use wildcards.  For ASN 1234567890 it might be

  http://0.9.8.7.6.5.4.3.2.1.asn.restwhois.net/asn/1234567890/whatever

> However, my biggest question is that if you have taken the time to 
> capture "restwhois.net" or some other well-known domain name, why not 
> just run an HTTP server on that domain that issues redirects?

Scaling.  DNS is cached UDP queries, http is mostly uncached TCP queries. 
If someone's willing to provide the central http server and deal with the 
load, I wouldn't object, but I don't know who's likely to pay for it.  I 
expect the load on the thing would be at least as much as the load on 
ARIN's WHOIS server.

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: Frank Ellermann <[email-masked]>
Date: Thu, 22 Sep 2011 15:50:20 +0200

> Sorry, typo. Meant HATEOAS: http://en.wikipedia.org/wiki/HATEOAS

Oops, "re-sorry", what I wrote wasn't intended as a spelling joke:
I simply didn't know the abbreviation, let alone how it's spelled.

-Frank

---

From: Andy Newton <[email-masked]>
Date: Thu, 22 Sep 2011 14:41:02 +0000

On Sep 22, 2011, at 9:36 AM, John R. Levine wrote:

> You could do the usual rDNS trick, divide the number into smaller pieces and use wildcards.  For ASN 1234567890 it might be
> 

That's still a lot of records because autnum allocations don't occur on predictable boundaries. But I get the point.

> Scaling.  DNS is cached UDP queries, http is mostly uncached TCP queries. If someone's willing to provide the central http server and deal with the load, I wouldn't object, but I don't know who's likely to pay for it.  I expect the load on the thing would be at least as much as the load on ARIN's WHOIS server.

HTTP caching does exist, and the issues around scaling web services are well-trodden, even if the solutions don't use public infrastructure.
In our experience, the larger issues do not come from using TCP over UDP, but from expensive searches against our database... none of which are specified in this draft.

-andy

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 22 Sep 2011 15:44:00 +0100

On 22/09/11 12:38, Andy Newton wrote:

> Interesting. What's your proposal for the cache busting? We reserve
> a query parameter for clients to put in a random value?

Yup, that's basically what I'm proposing. I'd propose something that
definitely would never appear in a query string otherwise, such as
'__weirds__cachebust' or something along those lines. I'd also specify
that this is only to be used as a workaround for clients that have to
deal with misbehaving HTTP intermediaries.

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 22 Sep 2011 15:49:16 +0100

On 22/09/11 12:50, Andy Newton wrote:

> However, my biggest question is that if you have taken the time to capture
> "restwhois.net" or some other well-known domain name.

CenterGate currently have whois-servers.net, which provides the rather useful
service of having CNAME records for the various top-level domain pointing at
their WHOIS servers. Could we talk to them about using the domain for this
purpose?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 22 Sep 2011 20:04:11 +0200

On 22/Sep/11 07:21, John Levine wrote:
> 
> You're not thinking like a lazy PHP programmer.

Hear, hear.  It seems there is a sort of language-divide between the
web and email, except for web-mail.  PHP and Java, as well as HTTP,
are not commonly used for mail filters on traditional SMTP servers,
AFAIK.  While this shouldn't be a barrier for deployment, it may be
worth noting that the kind of client is yet another dimension of the
"general case" --besides the kind of underlying database and policies.

---

From: "John Levine" <[email-masked]>
Date: 23 Sep 2011 00:36:12 -0000

>	For me it wouldn't be very difficult to build a whois server
>and even some API in python/java using restful services. Whilst with
>DNS, I wouldn't know where to start for the server and for the client
>I would use shell scripts (or to dig in some python/java libs). I
>guess it is not very different for many others trying to produce/use
>data to/from whois.

This doesn't strike me as a very compelling argument.  There is a lot
of DNS server and client libraries and application software available,
both commercial and open source, that can do just about anything you
can imagine, including fetching responses from databases and
synthesizing results on the fly.

Personally, I'm much more familiar with DNS software than with web
server software, so I don't think we should specify anything that
would require that I learn about web servers.  It looke like you and I
cancel out here.

R's,
John

---

From: Arturo Servin <[email-masked]>
Date: Thu, 22 Sep 2011 21:53:10 -0300

John,
	
	I do not have problem to learn DNS tricks and tools. But there are a lot o people out there more familiar with webservices (thanks to twitter, google et al.) than with DNS. I would prefer to focus my effort in the former than in the later. IMHO I think that our effort would have more probabilities to succeed.

/as

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 23 Sep 2011 11:27:03 -0300

Hi all,

Regarding the I-D, I feel that it would be great if we added prefix
information to the URI, I think it would open new query possibilities.

I imagine something like this:

http://restwhois.net/ip/192.168.0.0/16/registration -> Returns ORG-BIGISP

http://restwhois.net/ip/192.168.0.0/24/registration -> Returns
ORG-CUSTOMER-OF-BIGISP

This would provide more precise querying in the case of ISPs/LIRs/NIRs
subdelegations.

Other possibility could be differentiating ip addresses from ip
prefixes in the path spec:

http://restwhois.net/ip/192.168.0.0/registration -> Given the example
above, the semantics of this operation needs to be further specified.
What do we do? Return records for every possible match? Return record
for longest matches ?

http://restwhois.net/ippfx/192.168.0.0/24 -> Would work in the same
way as spec'ed in the example above.

I like a future where wget is the only client I need :-)

regards

Carlos

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================

---

From: Andy Newton <[email-masked]>
Date: Fri, 23 Sep 2011 14:45:07 +0000

> This would provide more precise querying in the case of ISPs/LIRs/NIRs

Arturo and Kaveh and I have been talking about this privately.

One design consideration that is not explicitly given, is that all the queries result in either zero or one answer.
Once we get into queries that can return multiple answers, issuing redirects becomes problematic. That is why I initially shied away from CIDR.

However, a network lookup by an IP is the same thing as a network lookup by a /32 (v4 example obviously).
So if we allow CIDR notation and restrict the matching semantics to "most specific network containing" the query target, which is what we have right now with IP addresses, I think this will work. That should return either zero or one answer.

Does that sound correct?

> I like a future where wget is the only client I need :-)

... or curl or your web browser. And you also get cut&paste of URLs, etc...
The advantages of using web technologies are many. :)

-andy

---

From: Dave Piscitello <[email-masked]>
Date: Fri, 23 Sep 2011 08:17:35 -0700

> So if we allow CIDR notation and restrict the matching semantics to "most specific network containing" the query target, which is what we have right now with IP addresses, I think this will work. T…

I like it.

>> I like a future where wget is the only client I need :-)

You set the bar so low. I want a future where clients don't require a QWERTY keyboard.

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 23 Sep 2011 12:19:29 -0300

Hi ! (check between lines)

> So if we allow CIDR notation and restrict the matching semantics to "most specific network containing" the query target, which is what we have right now with IP addresses, I think this will work. T…

Yes, it does sound correct to me. I think we should make the semantics
as explicit as possible and I also agree with the zero-or-one answer
requirement in order to make redirects possible.

Let me know if we can help you with the text.

> The advantages of using web technologies are many. :)

+1 :-)

---

From: "John Levine" <[email-masked]>
Date: 23 Sep 2011 18:24:03 -0000

>So if we allow CIDR notation and restrict the matching semantics to
>"most specific network containing" the query target, which is what we
>have right now with IP addresses, I think this will work. That should
>return either zero or one answer.

In my existing web scraping scripts, that's what I do when it returns
multiple results, so, yes.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 24 Sep 2011 17:41:07 +0200

On 23/Sep/11 16:45, Andy Newton wrote:
> 
> One design consideration that is not explicitly given, is that all 
> the queries result in either zero or one answer. Once we get into
> queries that can return multiple answers, issuing redirects becomes
> problematic. That is why I initially shied away from CIDR.
> 
> However, a network lookup by an IP is the same thing as a network
> lookup by a /32 (v4 example obviously). So if we allow CIDR
> notation and restrict the matching semantics to "most specific
> network containing" the query target, which is what we have right
> now with IP addresses, I think this will work. That should return
> either zero or one answer.
> 
> Does that sound correct?

I like it too.

However, the zero-or-one rule can be path-specific.  Another kind of
query, namely rdns, can return a list without compromising overall
consistency.  BTW, I don't think it is necessary for rdns' argument
and results to be in in-addr.arpa format: that only introduces a
difficulty when clients have to compare or generate such values.

> ... or curl

BTW, curl 7.20.0 introduced SMTP support.  It is still very basic and
buggy compared with how HTTP and FTP are done, but I wouldn't despair.

> The advantages of using web technologies are many. :)

We should target web and mail usage on equal terms, though.

---

From: Andy Newton <[email-masked]>
Date: Sat, 24 Sep 2011 15:45:03 +0000

> difficulty when clients have to compare or generate such values.

Can you provide examples of what you are talking about here?

> We should target web and mail usage on equal terms, though.

What do you mean by that?

-andy

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 24 Sep 2011 19:25:01 +0200

> Can you provide examples of what you are talking about here?

Sure.  To get the delegation chain I'd use

   get http://restwhois.net/rdns/192.0.2.87

instead of the "in-addr.arpa format"

   get http://restwhois.net/rdns/87.2.0.192.in-addr.arpa

I'd imagine the answer --in plain text, for simplicity-- can be
something like this:

   192.0.2.87
   192.0.2.80/26
   192.0.2.0/24

Now I can take any element from the list, for example the second, and
use it as a link to an operator query

   get http://restwhois.net/ip/192.0.2.80/26/operator

The other way around, I start with, say,

   get http://restwhois.net/ip/192.0.2.87/contacts/abuse

and get

   inetnum: 192.0.2.80/26
   email: [email-masked]

Assume I'm not satisfied with this, e.g. because [email-masked]
bounces.  To get it's next-level-up contact I can use the inetnum from
the result, or the same IP I started with.  That is, I'd query
respectively

   get http://restwhois.net/rdns/192.0.2.80/26

(which I'd imagine returns just two items), or

   get http://restwhois.net/rdns/192.0.2.87

In the latter case I can reckon that the sought item must be the
third, but may still want to check that the second item compares equal
to the inetnum returned on the previous query.  If the other format is
used, both comparison and argument passing require an extra variable
where the bytes are reversed and ".in-addr.arpa" appended, a a
function that is cumbersome and error-prone to write if it's not
provided in the environment.

> What do you mean by that?

If we assume that clients operate in typical web environments, we may
come up with solutions that are hard to deploy for mail filters.

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 23 Sep 2011 12:15:21 -0300

Hi ! (look between lines): 

> So if we allow CIDR notation and restrict the matching semantics to "most specific network containing" the query target, which is what we have right now with IP addresses, I think this will work. T…

Yes, that sounds correct to me. And the requirement of zero -or-one answer sounds also right to me.

+1 :-)