Subject: [weirds] Update to requirements

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Jan 2012 14:55:53 -0800

Hello all, Happy New Year and such.

Given the Taipei BoF, I think it's appropriate to update our requirements to match the direction we seem to have now.  So for the RIRs that have implemented a RESTful WHOIS system, do you happen to have a requirements document we could steal that might be a better starting point than the one we have now?

-MSK

---

From: Nikolay Shopik <[email-masked]>
Date: Tue, 10 Jan 2012 12:49:34 +0400

Hey,

 From what I see only ARIN and LACNIC implement restwhois based on 
current drafts. RIPE it seems have their on view on that or just no 
touched their previus rest system?

I'm unable to find working restwhois in APNIC or AfriNIC.

Also I find LACNINC doesn't accept "file extenstion" like ARIN does 
instead using header "Accept: text/plain".

And there no clear way to detect which RIR you should poll for now. So 
it's time to update drafts (expired for now).

On 10.01.2012 2:55, Murray S. Kucherawy wrote:
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 10 Jan 2012 10:47:31 -0200

Hello All,

we do plan to support file extensions in the future, we were just not
sure about how people felt about them.

I am not sure about the "which RIR you should poll for now", can you
clarify ?

warm regards

Carlos

On 1/10/12 6:49 AM, Nikolay Shopik wrote:
>> Given the Taipei BoF, I think it's appropriate to update our
>> requirements to match the direction we seem to have now.  So for the
>> RIRs that have implemented a RESTful WHOIS system, do you happen to
>> have a requirements document we could steal that might be a better
>> starting point than the one we have now?
>>
>> -MSK
>>
>>
>>
>>

-- 

--
Carlos M. Martinez
LACNIC R+D
http://www.labs.lacnic.net

---

From: Nikolay Shopik <[email-masked]>
Date: Tue, 10 Jan 2012 18:58:24 +0400

> sure about how people felt about them.

I don't think there disadvantages have it here, only advantages like 
easy accessible.

> I am not sure about the "which RIR you should poll for now", can you

s/poll/pull
This has been discussed previously, but no conclusion was made (DNS 
allocation publication). With current WHOIS and RestWHOIS, you must have 
local database of IANA allocation to know which RIR URL use to pull data.

I'm using debian whois client a lot, most of job I done by hands and it 
really annoy to know here new IANA allocation and you have to update app.

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 10 Jan 2012 14:08:28 -0200

Oh I see... the ye olde Joint WHOIS thing :-)

We are working on that and will have something to show really-soon-now
:-) Please stay tuned!

Carlos

On 1/10/12 12:58 PM, Nikolay Shopik wrote:
> allocation publication). With current WHOIS and RestWHOIS, you must
> have local database of IANA allocation to know which RIR URL use to
> pull data.
>
> I'm using debian whois client a lot, most of job I done by hands and
> it really annoy to know here new IANA allocation and you have to
> update app.
>
>>
>> warm regards
>>
>> Carlos
>>

--

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 11 Jan 2012 15:45:38 +1000

On 11/01/2012, at 12:58 AM, Nikolay Shopik wrote:

> s/poll/pull
> This has been discussed previously, but no conclusion was made (DNS allocation publication). With current WHOIS and RestWHOIS, you must have local database of IANA allocation to know which RIR URL use to pull data.

From recollection, Mark Kosters noted the RIRs' general desire for a good referral mechanism during the BOF in Québec.  I think you're right that drafts need updating, though right now I'm not quite sure how.

APNIC has no implementation of restwhois in any form at present, in case you're still looking for something that doesn't exist.

Speaking only for myself,
  Byron

---

From: Nikolay Shopik <[email-masked]>
Date: Wed, 11 Jan 2012 12:27:30 +0400

This bring up another question how do rate-limit works (if it will 
exist). Because for me this basically means I can be rate-limited at RIR 
which refer me to other RIR.

On 11.01.2012 9:45, Byron Ellacott wrote:
>  From recollection, Mark Kosters noted the RIRs' general desire for a good referral mechanism during the BOF in Québec.

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 11 Jan 2012 10:39:40 -0200

We are working on a proposal based on client-side redirects (based on
HTTP 301 result codes), so in this case no WHOIS proxies would be
present between client and servers, thus the rate-limiting policies of
each server would apply independently from one another.

I'll do my best to have something readable to share with the list today.

regards

Carlos

On 1/11/12 6:27 AM, Nikolay Shopik wrote:
> exist). Because for me this basically means I can be rate-limited at
> RIR which refer me to other RIR.
>
>>  From recollection, Mark Kosters noted the RIRs' general desire for a
>> good referral mechanism during the BOF in Québec.

--

---

From: SM <[email-masked]>
Date: Wed, 11 Jan 2012 12:26:29 -0800

At 21:45 10-01-2012, Byron Ellacott wrote:
>APNIC has no implementation of restwhois in any form at present, in 
>case you're still looking for something that doesn't exist.

And AfriNIC does not have one either.

Regards,
-sm

---

From: Arturo Servin <[email-masked]>
Date: Wed, 11 Jan 2012 19:13:04 -0200

Murray,

	In LACNIC we started our prototype with very basic requirements:

	- To comply with
	- Provide output in json and XML
	- Mimic the data model from the current whois
	- Prepara our code to migrate to a new data model with common elements between restwhois operators

	Other in our radar are:

	- Redirection to other operators for non-authoritative data.
	- Authentication and authorization to protect the data and the infrastructure agains abuse and attacks (rate limit, extended data model for authenticated users, etc.)

	And another that was not planned but we thought that it was handy:

	- Support of XML Stylesheets

	These are the requirements that we had got informally from people from now.

Regards,
/as

On 9 Jan 2012, at 20:55, Murray S. Kucherawy wrote:

> Given the Taipei BoF, I think it’s appropriate to update our requirements to match the direction we seem to have now.  So for the RIRs that have implemented a RESTful WHOIS system, do you happen to have a requirements document we could steal that might be a better starting point than the one we have now?
>  
> -MSK

---

From: SM <[email-masked]>
Date: Wed, 11 Jan 2012 13:35:01 -0800

Hi Arturo,
>- Mimic the data model from the current whois

This may be an issue as there isn't any documentation about 
this.  The "elephant in the room" is the data.  There are some RIR 
policies floating around.  That could be used to get a sense of what 
the output will be.

Speaking as an individual, do you think that the above approach may 
cause problems?  I am not going to ask you for an explanation about 
why it may be a problem.  Other people might ask.  I doubt that I 
will be able to convince them that it would not be a good idea to do so. :-)

Regards,
-sm

---

From: Arturo Servin <[email-masked]>
Date: Wed, 11 Jan 2012 20:04:48 -0200

SM

	We are not changing the data, we are not adding or removing fields, we are just changing the way we present it. I personally do not think this could be a problem, we are not changing any policy here, we are creating the technology to allow policy makers to build policies that today are impossible to make.

Regards,
/as

On 11 Jan 2012, at 19:35, SM wrote:

> This may be an issue as there isn't any documentation about this.  The "elephant in the room" is the data.  There are some RIR policies floating around.  That could be used to get a sense of what the output will be.
> 
> Speaking as an individual, do you think that the above approach may cause problems?  I am not going to ask you for an explanation about why it may be a problem.  Other people might ask.  I doubt that I will be able to convince them that it would not be a good idea to do so. :-)
> 
> Regards,
> -sm

---

From: SM <[email-masked]>
Date: Wed, 11 Jan 2012 14:48:18 -0800

Hi Arturo,
At 14:04 11-01-2012, Arturo Servin wrote:
>         We are not changing the data, we are not adding or removing 
> fields, we are just changing the way we present it. I personally do 
> not think this could be a problem, we are not changing any policy 
> here, we are creating the technology to allow policy makers to 
> build policies that today are impossible to make.

My comment was not about the above. :-)

I have some understanding of the policy process.  I was not talking 
about changing or discussing policy here.

Regards,
-sm