Subject: [weirds] Comments on draft-kucherawy-weirds-requirements-00

From: SM <[email-masked]>
Date: Sun, 26 Jun 2011 02:12:15 -0700

Hi Murray,

I have a few comments about draft-kucherawy-weirds-requirements-00.

In Section 4.1:

   "A client MAY be able to handle UDP replies, and if the server
    provides service with UDP, the client SHOULD attempt a UDP query
    prior to a TCP query."

That sounds like DNS.

In Section 4.2:

   "Limiting the number of queries per time interval from a
    particular source MUST NOT be done."

There is generally a limit on the number of queries as resources are 
always a constraint.  I think that such a requirement is unrealistic.

Regards,
-sm

---

From: Warren Kumari <[email-masked]>
Date: Mon, 27 Jun 2011 09:48:05 +0800

On Jun 26, 2011, at 5:12 PM, SM wrote:

> There is generally a limit on the number of queries as resources are always a constraint.  I think that such a requirement is unrealistic.

Yes -- there are also (obviously) technical limits in place (I can only shuffle queries at you at a rate limited by the size of (min(pipe, cpu, disk, etc)). If you force this as a MUST NOT, folk will artificially limit things with some bottleneck…

W

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

---

From: "John Levine" <[email-masked]>
Date: 27 Jun 2011 02:07:41 -0000

>    provides service with UDP, the client SHOULD attempt a UDP query

It's definitely DNS, but someone (not Murray) apparently thinks that
it might be a good idea to reinvent it on a different port.

>    particular source MUST NOT be done."

All the DNSBLs that are at all popular do rate limiting both for
anti-DDoS and to separate the small free users from the larger paid
users.  This seems a wee bit optimistic.

Perhaps it would be more realistic to say that servers SHOULD
provision adequate capacity to respond to the anticipated number of
queries, and SHOULD disclose policies that provide different levels of
service to different categories of clients.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Mon, 27 Jun 2011 11:08:31 +0800

> service to different categories of clients.

Oooh, that's much better than my earlier snarky comments…

W

---

From: SM <[email-masked]>
Date: Mon, 27 Jun 2011 01:17:27 -0700

>service to different categories of clients.

It's better to keep technical specifications and policy separate.

The document mentions that "IRIS has seen little to no deployment for 
various reasons, mostly its complexity  compared to WHOIS and some 
political and technical inertia".  Should this effort go down that 
path, it may result in a similar outcome.  BTW, some of the text in 
the Abstract section is not reflected in the body of the document.

Whois services are operated by several organizations; gTLDs, ccTLDs, 
RIRs, etc.  Some of these organizations are not bound by some 
top-down policy.  Some of them don't even disclose their policies.

Some of the I-Ds that have been posted are from RIRs.  As they have 
jumped on the RESTful bandwagon, is there any interest in developing 
a different protocol?

Section 2 of draft-kucherawy-weirds-requirements-00 mentions that 
"the intent to publish one of the API specifications as a standards 
track document, and the remainder (including this memo) as 
informational documents".  In my book, standardization is about "this 
is how we all agree to do it".  In general, various I-Ds can be used 
as input to the (IETF) work. What's the argument for one of the RIRs 
to publish their API specifications as an Informational document?

Regards,
-sm

---

From: Andy Newton <[email-masked]>
Date: Mon, 27 Jun 2011 10:34:42 -0400

> It's better to keep technical specifications and policy separate.

I totally agree.

> The document mentions that "IRIS has seen little to no deployment for various reasons, mostly its complexity  compared to WHOIS and some political and technical inertia".  Should this effort go down that path, it may result in a similar outcome.  BTW, some of the text in the Abstract section is not reflected in the body of the document.
> 
> Whois services are operated by several organizations; gTLDs, ccTLDs, RIRs, etc.  Some of these organizations are not bound by some top-down policy.  Some of them don't even disclose their policies.
> 
> Some of the I-Ds that have been posted are from RIRs.  As they have jumped on the RESTful bandwagon, is there any interest in developing a different protocol?

Thanks for injecting perspective into this thread.

With regards to UDP/DNS, I think there are 3 issues being intermingled here.

1) The use of DNS as protocol infrastructure, such as using SRV or NAPTR records, use of wildcards, etc.... IRIS does this; it is one of those things that I believe makes it too complex. None of the single technologies in IRIS are complex or hard to understand, but taken together they present a significant implementation/deployment burden.

2) The use case of a protocol for checking if a domain is available for registration over UDP. This is what DCHK does, and is the only part of IRIS that has seen real deployment. It is used by some of the ccTLDs.

3) The use case of a protocol for obtaining registration meta-data useful for real-time reputation services. This is what John was talking about, DNS records for domain registries to spell out how long a domain has been registered and when it might expire. I assume this is useful for fighting spam from bad actors acquiring new domains. John proposes DNS, which I think makes sense given this specific use case but no other (there are other anti-abuse use cases for Whois data).

> Section 2 of draft-kucherawy-weirds-requirements-00 mentions that "the intent to publish one of the API specifications as a standards track document, and the remainder (including this memo) as informational documents".  In my book, standardization is about "this is how we all agree to do it".  In general, various I-Ds can be used as input to the (IETF) work. What's the argument for one of the RIRs to publish their API specifications as an Informational document?

As the author of the ARIN draft, I guess that question might be directed at me. But I'm not really sure what you are asking. Each RIR could publish an informational, but what's the point?

-andy

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Jun 2011 08:31:13 -0400

> service to different categories of clients.

I think the goal of this passage is to try to say, "Don't have some
lame limit like 3 queries/minute" or something like that.  At least
one large gTLD registry operator has a very low limit, and it
interferes with some users' purposes (yes, one of those purposes is
"harvesting", but only one).

A

-- 
Andrew Sullivan
[email-masked]

---

From: MICHAEL YOUNG <[email-masked]>
Date: Mon, 27 Jun 2011 12:05:28 -0400

I can guess which provider you are hinting at. That same provider (if I am
correct on who it is) provides different rate limiting policies for a
separate class of user.

Right now they do that by running separate server instances and providing
IP restricted access, this, to my mind, is a clumsy way to address the
issue.

I think, given whois has many stakeholders and therefore potentially many
use cases, rate-limiting and user classes should be up to the whois
operator and its constituents.

IMHO this work should enable those choices,....rate-limiting itself is not
inherently bad or good, that depends entirely on how and to whom its
applied.  If you try to prevent it in the protocol, I can safely say you
just guaranteed a pretty common protocol violation.

-M

---

From: SM <[email-masked]>
Date: Mon, 27 Jun 2011 10:58:19 -0700

Hi Andy,
At 07:34 27-06-2011, Andy Newton wrote:
>1) The use of DNS as protocol infrastructure, such as using SRV or 
>NAPTR records, use of wildcards, etc.... IRIS does this; it is one 
>of those things that I believe makes it too complex. None of the 
>single technologies in IRIS are complex or hard to understand, but 
>taken together they present a significant implementation/deployment burden.

There is a learning curve for DDDS as there isn't widespread 
implementation experience.

[snip]

>3) The use case of a protocol for obtaining registration meta-data 
>useful for real-time reputation services. This is what John was 
>talking about, DNS records for domain registries to spell out how 
>long a domain has been registered and when it might expire. I assume 
>this is useful for fighting spam from bad actors acquiring new 
>domains. John proposes DNS, which I think makes sense given this 
>specific use case but no other (there are other anti-abuse use cases 
>for Whois data).

Here are some use cases:

  (i)  Day Old Bread domains - The data required is date of registration

  (ii) Domains contact information - The data required is the contact

  (iii) Relevant contact information for IP address space that has 
been allocated

The data for cases (ii) and (iii) is not only used for fighting spam; 
other businesses have sprung up and they consume that data for 
enforcement, take down notices, etc.

The "need" is to provide structured instead of freeform data for 
public access.  There is also data available only through 
authenticated access.  John commented on some of the limits set by 
DNSBLs (high volume queries).

Quoting a message from Jay Daley [1]:

   "I struggle with a document that gets down to the UDP level before
    we have agreed what the technology needs to do".

draft-kucherawy-weirds-requirements-00 is a starting point.  The 
first step is to identify the use cases.  It's up to this group (I 
assume that this is what this group is about) to see whether they can 
be addressed in practical terms.

>As the author of the ARIN draft, I guess that question might be 
>directed at me. But I'm not really sure what you are asking. Each 
>RIR could publish an informational, but what's the point?

I don't see the point of having a standardized API and ARIN or some 
other RIR publishing its own API.  Are ICANN, ARIN and RIPE okay with 
implementing the standardized API and not  having their own version of the API?

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/weirds/current/msg00022.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Jun 2011 11:26:32 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Sunday, June 26, 2011 2:12 AM
> To: [email-masked]
> Subject: [weirds] Comments on draft-kucherawy-weirds-requirements-00
> 
> Hi Murray,

Hi Sub,

>     provides service with UDP, the client SHOULD attempt a UDP query

DNS was one of the possible implementation ideas, but it wasn't the specific target of the requirement.  Any lightweight method is what I was trying to capture.

> always a constraint.  I think that such a requirement is unrealistic.

I said earlier on the list that the point of the requirement is to ensure that the throttling isn't arbitrary.  Presuming that someone sending you lots of queries must be up to no good removes an important service from parties that really need it and are using it legitimately.  Specifically, a WHOIS service provider assuming that just about anyone out there is doing queries for the purpose of poaching customers is one of the things that seriously degrades the value of WHOIS today.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Jun 2011 14:28:10 -0400

On Mon, Jun 27, 2011 at 10:58:19AM -0700, SM wrote:
> other RIR publishing its own API.  Are ICANN, ARIN and RIPE okay
> with implementing the standardized API and not  having their own
> version of the API?

I can't speak for others, but I cannot imagine why anyone would
participate in this effort without planning to make something
interoperable.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Jun 2011 11:28:20 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Sunday, June 26, 2011 7:08 PM
> To: [email-masked]
> Subject: Re: [weirds] Comments on draft-kucherawy-weirds-requirements-00
> 

I'd be totally fine with something that says "unlimited (subject to resources) queries that return only this small subset of a registration, but we're free to rate-limit you for the full data set".  I think this would cater sufficiently to security service providers while inhibiting customer poaching.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Jun 2011 11:31:34 -0700

> Sent: Monday, June 27, 2011 10:58 AM
> To: Andy Newton
> Cc: [email-masked]

Such could go directly to Historic status just for the sake of documenting history and making an explicit statement that people should move toward the standards track thing.  We did that with DomainKeys, for example.

---

From: "Michael Young" <[email-masked]>
Date: Mon, 27 Jun 2011 14:52:52 -0400

>I'd be totally fine with something that says "unlimited (subject to
resources) queries that return only this small subset of a registration, but
we're free to rate-limit you for the full data set".  I think this would
cater sufficiently to security service >providers while inhibiting customer
poaching.

I think don't think we can determine all the reasons "why" a whois operator
would rate limit.  Therefore I think we can't determine limits or exceptions
to said rate limiting.

---

From: "John R. Levine" <[email-masked]>
Date: 27 Jun 2011 14:54:55 -0400

> would rate limit.  Therefore I think we can't determine limits or exceptions

I agree.  This strikes me as basically a side issue, since WHOIS providers 
will do rate limiting no matter what we tell them to do.

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: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Jun 2011 11:56:18 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Monday, June 27, 2011 11:55 AM
> To: Michael Young
> Cc: Murray S. Kucherawy; [email-masked]
> Subject: RE: [weirds] Comments on draft-kucherawy-weirds-requirements-00
> 

Alas, I probably agree too.  I guess this could be relegated to an appendix where at least this perspective is relayed to the WHOIS providers.

---

From: Andy Newton <[email-masked]>
Date: Mon, 27 Jun 2011 15:12:38 -0400

> participate in this effort without planning to make something

Well said.

-andy

---

From: Peter Koch <[email-masked]>
Date: Tue, 28 Jun 2011 08:42:20 +0200

> participate in this effort without planning to make something

so, how long have you now been around the IETF? ;-)

The draft (admittedly a -00) does not focus on interoperability,
but attempts to phrase operational or user requirements without
clearly stating what constituency's requirements these are.

Rate limiting, for one, is a MUST from some data protection
authority's angle, so any "requirement" to the contrary is, say,
interesting.  Actually, back to interoperability, when it says

   1.  A server MUST accept and process all queries except when in a
       defensive posture against a denial-of-service or other security
       attack.  Limiting the number of queries per time interval from a
       particular source MUST NOT be done.

would a server that acknowledges the connection and sends back a "no, thank
you", fulfill the requirement?

-Peter

---

From: "Smith, Bill" <[email-masked]>
Date: Tue, 28 Jun 2011 04:02:07 -0600

Which data protection authority requires rate limiting? Can you provide the relevant regulatory language?

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 28 Jun 2011 12:13:51 +0200 (CEST)

Hi Bill

> the relevant regulatory language?

At least for .ch domain names there is such a regulatory requirement
(art 14h bis AEFV) that leads to rate limiting for whois service:

   http://www.admin.ch/ch/d/sr/784_104/a14h.html [German]
   http://www.admin.ch/ch/f/rs/784_104/a14h.html [French]
   http://www.admin.ch/ch/i/rs/784_104/a14h.html [Italian]

[Sorry, no English version.]

cheers,
  Bernie

--

http://ucom.ch/
Tech Consulting for Internet Technology

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Tue, 28 Jun 2011 10:19:57 +0000

Bernie

That doesn't say anything about rate limiting that I can see. 

Looking at the French version I see:

"Le registre prend des mesures adéquates afin d’empêcher une utilisation abusive des données mises à la disposition du public, en particulier leur utilisation à des fins de publicité ou de promotion commerciale."

That's pretty much the same as the "no marketing / no abuse" clause in ICANN's RAA.

Regards

Michele

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://b.log.ie/
http://invadeeurope.eu/
http://www.gettingbusinessonline.ie/
http://rss.me/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Twitter: http://twitter.com/mneylon

PS: Check out our latest offers on domains & hosting: http://domainoffers.me/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

---

From: "Smith, Bill" <[email-masked]>
Date: Tue, 28 Jun 2011 04:25:10 -0600

It all hinges on how "adequate measures" is defined.

Sent from my iPhone

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Tue, 28 Jun 2011 10:32:56 +0000

> It all hinges on how "adequate measures" is defined.

Which it probably isn't .. 

Mr Michele Neylon
Blacknight Solutions

---

From: Arturo Servin <[email-masked]>
Date: Tue, 28 Jun 2011 08:33:51 -0300

> Which it probably isn't .. 

	But it is easy and cheap.

	Try to substitute that with something complex and expensive and your interoperability will go no where.

-as

---

From: "Smith, Bill" <[email-masked]>
Date: Tue, 28 Jun 2011 06:02:32 -0600

It may be easy and cheap, but that does *not* make it a regulatory mandate.

Sent from my iPhone

---

From: Arturo Servin <[email-masked]>
Date: Tue, 28 Jun 2011 09:24:48 -0300

> It may be easy and cheap, but that does *not* make it a regulatory mandate.

	Totally agree with that.

-as

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 28 Jun 2011 19:20:15 +0200 (CEST)

Hi Michele & Bill

You might want to have a closer look into the corresponding implementation 
policies issued by the regulator (SR 784.101.113/2.13 art 8):

  http://www.bakom.admin.ch/org/grundlagen/00563/00564/00681/index.html?lang=de
  http://www.bakom.admin.ch/org/grundlagen/00563/00564/00681/index.html?lang=fr
  http://www.bakom.admin.ch/org/grundlagen/00563/00564/00681/index.html?lang=it

There it explicitly specifies the rate limitation to be applied by the 
registry:

  "Beschränkung des Zugriffs auf den Whois-Dienst von der gleichen und/oder
  ähnlichen IP-Adresse auf 40 Zugriffe pro 10 Minuten;"

in English:

  "Limitation of access to the Whois service from the same and/or
  a similar IP-Adresse to 40 queries per 10 minutes;"

cheers,
  Bernie

---

From: "John Levine" <[email-masked]>
Date: 28 Jun 2011 18:38:27 -0000

It seems to me that it is a simple fact that people who run WHOIS
servers provide more access to some clients than to others.  That
doesn't mean they're evil, it means that too many of the people trying
to do high rate queries are.  We all know that spammers scrape WHOIS,
I get paper junk mail all the time to addresses that have never
appeared anywhere other than WHOIS.

With this in mind, it would be nice if clients known to the WHOIS
operator could identify themselves in ways less kludgy than keying
it to an IP address.

R's,
John

---

From: Michael Young <[email-masked]>
Date: Tue, 28 Jun 2011 16:03:44 -0400

I agree!

Michael Young

M:647-289-1220

---

From: SM <[email-masked]>
Date: Wed, 29 Jun 2011 01:55:34 -0700

>That's pretty much the same as the "no marketing / no abuse" clause 

I gather that the RAA document is the one at 
http://www.icann.org/en/registrars/ra-agreement-21may09-en.htm

The last compliance report mentions that:

   - Most registrars provide access to Whois data in a manner reasonably
     compliant with Section 3.3 of the RAA; representing a 99% compliance rate

   - Out of 970+ accredited registrars, 11 registrars had non-functioning Whois
     service.

   - Five registrars had overly aggressive rate-limiting policies.

Whois usage is commonly brought up in discussions about port 43 (e.g. 
draft-brunner-rfc954-historic).  I'll quote some text from denic.de:

   "This data has to be made publicly available for several reasons.  One
    evident reason is that it must be possible to contact domain holders if
    their domains as such or the use of them cause technical difficulties
    that might lead to disturbances for others."

 From nominet.co.uk:

   "The WHOIS makes it easier to identify the legal registrant of a domain
    name and should therefore help build more confidence in the use of the
    Internet."

I'll leave it to whoever knows the answer to elaborate on whether the 
RAA covers, for example, these two operators of Whois services.  The 
discussion about variants ( see 
http://www.ietf.org/mail-archive/web/dnsext/current/msg11080.html ) 
might shine some light on the scope of a somewhat similar problem.

In the words of Viviane Reding, "I always meet people who are 
astonished that Christmas is on the 25th of December".

Regards,
-sm

---

From: "Smith, Bill" <[email-masked]>
Date: Wed, 29 Jun 2011 04:11:58 -0600

Country code top level domains sit outside ICANN's purview. Each ccTLD sets it's own WHOIS policy.

Sent from my iPhone