Subject: Re: [weirds] I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt

From: Antoin Verschuren <[email-masked]>
Date: Tue, 1 May 2012 10:19:30 +0200

On 01-05-12 04:46, John Levine wrote:
> 
> For a name registry or registrar, I'd be thrilled to get a list of 
> name servers they know about that resolve to that IP.  A common
> bad guy trick is to register a bunch of names, stick them all on
> the same servers, but use a different subdomain name for each one,
> e.g. foo.biz has name server ns1.foo.biz and bar.biz has
> ns1.bar.biz , but they're really the same IP.

Before people are getting too wet erotic area's, I think the request
is not about names.
For a names registry, only forward lookups are permitted, so query a
name, and get back IPs'. Querying for an IP and getting back names
from a names registry is, although perhaps technically viable, not
permitted by at least European database law.
I can imagine that it's cool info though, I would certainly like a
query for a postal code and get a list of all Internet resources
listed at that physical address. Great marketing info, but not the
info a registry is supposed to deliver.

The IP query is for RIR's I suppose. They deliver IP blocks, so
querying for an IP there will give you their registration data for
that block. No reverse search.

The ID search is something registrars indeed sometimes use to see if
the object that exists in their internal DB still exist in the
registries DB so they link the correct objects. But also here, it's
only a forward object search, no information on what other objects are
linked to it in the registry DB.
Or to give an example: I want to know when registering a new object if
my role-object in the registry DB is still correct, so I query for it
by object-ID, that I know by heart or is in my own administration. I
then only get back that object, and not all the resources that it is
used in.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Dave Piscitello <[email-masked]>
Date: Tue, 1 May 2012 05:03:47 -0700

+1

In a searchable world, sometimes all you have is the IP of the name server that's resolving the malicious/harmful domain. So asking "what other domains host zone files at this IP?", "who registered those domains?", and "what registrar is sponsoring the registrations?" are all useful crumbs that often help you identify names used by in a campaign, or the registrant names used in association with a criminal enterprise. 

On Apr 30, 2012, at 10:46 PM, John Levine wrote:

>> I find the notion of asking a domain registrar for information about an
>> IP address to be confusing.  Is the user expecting to know who they
>> should contact about that IP address, are they expecting to find all the
>> possible mappings of labels to that IP address , or are they expecting
>> to have the domain query service perform a reverse lookup for them? 
> 
> name servers they know about that resolve to that IP.  A common bad
> guy trick is to register a bunch of names, stick them all on the same
> servers, but use a different subdomain name for each one, e.g. foo.biz
> has name server ns1.foo.biz and bar.biz has ns1.bar.biz , but they're
> really the same IP.
> 
> R's,
> John
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Dave Piscitello <[email-masked]>
Date: Tue, 1 May 2012 05:18:12 -0700

Well, I think you may have a different notion of how the protocol would be used; in particular, I think you are only considering "public access".

I'll ask the questions that seems to be unanswered:

- Are we designing the queries to be only useful for user to name registry, name registrar "web pages"?
- Do we intend to accommodate automated queries, where software/scripts ask queries using http/https and get JSON/XML whatever responses?
- Do we intend to accommodate queries that one might make on sets of name registration data that have been collected over time and now form a local data repository?

I believe the answer is yes to all three. While "public" searchable Whois (or in general query by object/argument) may not initially be permitted by law or policy, shouldn't the protocol take into consideration how researchers, investigators, etc. make use of collected data today - and make it easier and more robust.

On May 1, 2012, at 4:19 AM, Antoin Verschuren wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJPn5ySAAoJEDqHrM883AgnkosIAM1JQE8FE4QSLPy0/hZOiC13
> pLYr62vN6FZ4KINLHHqrwkvGO97exen8EV/1wG3f8bPNkbZE1104pWJVqh//YSFq
> 7lH7aCPhi6aZH0hbtNe0HPO8/FLDEfucElqsevsRR/NdarqQ2Ahd+7ul4pCUB3zY
> R8x4/9MjGaUqpcOx3tglXFqb3sU/W0oFUrIfMwXklI0B7GpcbEvOj3ul1yqYSRmi
> H0X6vskeo+LmuYXgjWg98JRhdx/Z/s2/WA8A7g0zw8MV3yvQMs1gbrRFu/gZ/KIi
> GaAU5iTkTool9bggA1vPWWgIxEbkzjt69YSNeAiajW1iKa/tjOeJw2HAmBiTHiA=
> =TQ+5
> -----END PGP SIGNATURE-----

---

From: Andy Newton <[email-masked]>
Date: Tue, 1 May 2012 08:49:02 -0400

> In a searchable world, sometimes all you have is the IP of the name server that's resolving the malicious/harmful domain. So asking "what other domains host zone files at this IP?", "who registered…

Are you gonna hit up every registry or registrar in the world looking for your answer? I'm a little fuzzy on the use case.

And does this feature already exist in many registry Whois servers?

-andy

---

From: Patrick Vande Walle <[email-masked]>
Date: Tue, 01 May 2012 14:49:19 +0200

-1.

While I can see the usefulness of such an information in specific criminal investigations, I think the registry or registrar could provide this information out of band to the relevant law enforcement authorities, when asked properly.

As mentioned already, IP addresses are considered as personal data under some jurisdictions.

If anything, this thread also shows the need to come up with an authentication framework. It is not just a nice to have option, but should be an integral part of the deliverables.

Patrick Vande Walle

Dave Piscitello <[email-masked]> a écrit :

>+1
>
>In a searchable world, sometimes all you have is the IP of the name
>server that's resolving the malicious/harmful domain. So asking "what
>other domains host zone files at this IP?", "who registered those
>domains?", and "what registrar is sponsoring the registrations?" are
>all useful crumbs that often help you identify names used by in a
>campaign, or the registrant names used in association with a criminal
>enterprise. 
>

-- 
Envoyé de mon téléphone. Excusez la brièveté.

---

From: Don Blumenthal <[email-masked]>
Date: Tue, 1 May 2012 09:24:39 -0400

I used to be in Internet LE. Out of band may not be sufficient for legal reasons or because of timeliness. It's obviously better than nothing and often all that's available currently but I thought I should clarify the point.

FWIW, relative old timers in Internet LE miss the days when Whois records often included registrant ID numbers.

Don

From: Patrick Vande Walle <[email-masked]<mailto:[email-masked]>>
To: Dave Piscitello <[email-masked]<mailto:[email-masked]>>, John Levine <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt

-1.

Patrick Vande Walle

Dave Piscitello <[email-masked]<mailto:[email-masked]>> a écrit :

+1

On Apr 30, 2012, at 10:46 PM, John Levine wrote:

>> to have the domain query service perform a reverse l
 ookup
for them?
> servers, but use a different subdomain name for each one, e.g. foo.biz<http://foo.biz>
> has name server ns1.foo.biz<http://ns1.foo.biz> and bar.biz<http://bar.biz> has ns1.bar.biz<http://ns1.bar.biz> , but they're
> really the same IP.
>
> R's,
> John
>
________________________________

> weirds mailing list
> [email-masked]<mailto:[email-masked]>

________________________________

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 May 2012 13:28:37 +0000

Doesn’t http/https already include an authentication framework for clients?

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Patrick Vande Walle
Sent: Tuesday, May 01, 2012 5:49 AM
To: Dave Piscitello; John Levine
Cc: [email-masked]
Subject: Re: [weirds] I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt

-1.

Patrick Vande Walle

+1

 ookup

for them?

weirds mailing list

---

From: Michael Young <[email-masked]>
Date: Tue, 1 May 2012 09:29:15 -0400

Well registry operators have been listing "bulk Whois" in their to be developed list right in the registry agreements for some time. 

I think what the protocol needs is an option to request a large task ( such as "develop a specified report") and a subsequent notification mechanism to alert the requester the report (or data collection) is ready to retrieve. 

Michael Young

---

From: Michael Young <[email-masked]>
Date: Tue, 1 May 2012 09:40:49 -0400

You need a license to operate a Hamm radio or broadcast pretty much anything, this begs the question - should registrants have to apply and receive an ICANN issued ID in order to operate a domain and "broadcast" to the Internet?

Michael Young

M:647-289-1220

---

From: Dave Piscitello <[email-masked]>
Date: Tue, 1 May 2012 07:49:16 -0700

> Are you gonna hit up every registry or registrar in the world looking for your answer? I'm a little fuzzy on the use case.

This would be inefficient. As I said in a subsequent email, at least some of the use cases I'm familiar with are databases of whois records associated with malicious registrations or domains associated with criminal activities. However, I wouldn't discount hitting up the "top suspects" if I were investigating a campaign that seemed to concentrate on a small number of registries. Sampling might fall within scale, too.

> And does this feature already exist in many registry Whois servers?

Few I imagine. I know of some research and private applications where this feature is either present or would be attractive. 

Are we only interested in replicating what exists today?

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 1 May 2012 10:57:55 -0400

> You need a license to operate a Hamm radio or broadcast pretty much anything, this begs the question - should registrants have to apply and receive an ICANN issued ID in order to operate a domain a…

Gonna be tough to enforce that given that ICANN has no authority of
any kind over vast chunks of the DNS.  Anyway, the analogy is pretty
weak.  The reason you need a broadcast license is because the spectrum
is a scarce resource, and because what you do inevitably affects
others using the spectrum.  DNS names aren't scarce, even if TLDs are
artificially scarce, and if nobody ever looks you up then nobody even
knows you're there.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andy Newton <[email-masked]>
Date: Tue, 1 May 2012 11:01:05 -0400

> Are we only interested in replicating what exists today?

Given the scope creep seen in this thread (not picking on this particular function), I think it would be wise to do that. There's nothing stopping us from coming back around and adding things later.

-andy

---

From: Arturo Servin <[email-masked]>
Date: Tue, 1 May 2012 12:20:47 -0300

Agree with Patrick.

	I do not really see the relevance to include that field. 

	And as Andy mentioned in another e-mail, where is that info in the current whois and more important, why?

/as

---

From: Arturo Servin <[email-masked]>
Date: Tue, 1 May 2012 12:24:36 -0300

+1

	We can enhance the protocol in round two. 

/as

---

From: Kaveh Ranjbar <[email-masked]>
Date: Tue, 1 May 2012 17:39:36 +0200

+1

---

From: "John R. Levine" <[email-masked]>
Date: 1 May 2012 11:40:30 -0400

> Are you gonna hit up every registry or registrar in the world looking for your answer? I'm a little fuzzy on the use case.

Typically the bad guys use one or two TLDs, so probably not.

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: "John R. Levine" <[email-masked]>
Date: 1 May 2012 11:43:25 -0400

> As mentioned already, IP addresses are considered as personal data under some jurisdictions.

That horse left the barn a decade ago.  If you sign up for zone file 
access, you get all of the name servers and all of the IPs.  This feature 
would just make it available to people who aren't able to download and 
index the entire multi-gigabyte .COM zone file.

In the unlikely event that there are legal constraints on the data that a 
registrar returns, they'll always be able to return an error code that 
means "we can't answer that question."

Regards from someone who does download and index the .COM zone file,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: SM <[email-masked]>
Date: Tue, 01 May 2012 08:55:01 -0700

Hi Patrick,
>under some jurisdictions.

There was a presentation within the IETF in the context of the E.U. 
about this recently.  The answer is more complicated than: IP address 
= personal data.

Some of the consumers of the information are:

  (i)   Self-organized groups

  (ii)  IPR "enforcers"

  (iii) Law enforcement groups

The case of the third group is generally put forward by the rest of 
the consumers.

Regards,
-sm

---

From: Dave Piscitello <[email-masked]>
Date: Tue, 1 May 2012 09:22:41 -0700

So we're clear, this increases the likelihood that other implementations than registry/registrar might extend the protocol in non-uniform manners. Would be nice to avoid but I'm not going to fall on my sword on this issue in this working group.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 01 May 2012 12:33:54 -0400

On 5/1/12 11:43 AM, John R. Levine wrote:
> access, you get all of the name servers and all of the IPs.  This
> feature would just make it available to people who aren't able to
> download and index the entire multi-gigabyte .COM zone file.

you really could be less indirect about identifying the least policy
business model, and the specific instance of the least policy business
model, for which the association of names to addresses is not only not
one-to-one, but names-of-rights-of-others-interest to addresses is
more than one to one.

this is a cnobi problem, and overwhelmingly a .com problem, and so not
a general problem for which a solution -- likely to be imposed by a
frequently problematic actor upon a vastly larger set of registries,
independent of business model, or market share.

> In the unlikely event that there are legal constraints on the data
> that a registrar returns, they'll always be able to return an error
> code that means "we can't answer that question."

"rar returns", a typo?

if an operator is advised that a jurisdiction exists in which such a
constraint exists, how could it partition its response to allow an
error code and other data?

> Regards from someone who does download and index the .COM zone file,

likewise, and some others.

-e

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 1 May 2012 16:49:19 +0000

Ø  Where is that info in the current whois and more important, why?

One example: Verisign currently supports whois host lookup by IP address for .com and .net. I don't know why that capability was added originally, but I believe it's been there for as long as com/net whois service has been available.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Arturo Servin
Sent: Tuesday, May 01, 2012 11:21 AM
To: Patrick Vande Walle
Cc: John Levine; [email-masked]
Subject: Re: [weirds] I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt

          Agree with Patrick.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 May 2012 16:56:43 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Piscitello
> Sent: Tuesday, May 01, 2012 9:23 AM
> To: Arturo Servin
> Cc: [email-masked]
> So we're clear, this increases the likelihood that other
> implementations than registry/registrar might extend the protocol in
> non-uniform manners. Would be nice to avoid but I'm not going to fall
> on my sword on this issue in this working group.

Such could be developed as individual submissions until this group finishes its first set of deliverables, and then we could re-charter to take on the extensions.

Just one possible path forward.

-MSK

---

From: Andy Newton <[email-masked]>
Date: Tue, 1 May 2012 13:19:05 -0400

> So we're clear, this increases the likelihood that other implementations than registry/registrar might extend the protocol in non-uniform manners. Would be nice to avoid but I'm not going to fall o…

Nobody knows if it increases the likelihood, but the probability of protocol extensions is there any way. If we attempt to throw every feature into the protocol now in fear of not being able to add extensions later, then it is gonna be really difficult to get the first revision out the door and thus will validate the fears of some of the critics of this work.

Maybe we should keep a list of features desired but not for the first pass. Often the more complex use cases are clarified after an initial go round with the base features.

-andy

---

From: Arturo Servin <[email-masked]>
Date: Tue, 1 May 2012 15:10:48 -0300

This seems that is because access restrictions, which I think it could be done with several methods: IP address, certificates, API keys, etc.

	Anyhow, if you are going to authenticate by IP address you are going to see the source address of the connection, not the IP address of the query. Isn't it?

Regards,
as

On 1 May 2012, at 13:49, Hollenbeck, Scott wrote:

> One example: Verisign currently supports whois host lookup by IP address for .com and .net. I don’t know why that capability was added originally, but I believe it’s been there for as long as com/net whois service has been available.
>  
> Scott
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 1 May 2012 18:44:04 +0000

I'm talking about a query like this, not authentication by IP address:

whois -h whois.verisign-grs.com 198.41.1.1

Are we talking about the same thing?

Scott

From: Arturo Servin [mailto:[email-masked]]
Sent: Tuesday, May 01, 2012 2:11 PM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [weirds] I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt

Regards,
as

On 1 May 2012, at 13:49, Hollenbeck, Scott wrote:

>  Where is that info in the current whois and more important, why?

Scott

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Arturo Servin
Sent: Tuesday, May 01, 2012 11:21 AM
To: Patrick Vande Walle
Cc: John Levine; [email-masked]<mailto:[email-masked]>
Subject: Re: [weirds] I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt

          Agree with Patrick.

---

From: Arturo Servin <[email-masked]>
Date: Tue, 1 May 2012 16:28:23 -0300

Probably not.

	Now, after clearing the confusion, the reply of this query looks like an RIR reply and I still not see why we would want it in the name world.

Regards,
.as

On 1 May 2012, at 15:44, Hollenbeck, Scott wrote:

> I’m talking about a query like this, not authentication by IP address:
>  
> whois –h whois.verisign-grs.com 198.41.1.1
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 1 May 2012 20:12:47 +0000

From: Arturo Servin [mailto:[email-masked]]
Sent: Tuesday, May 01, 2012 3:28 PM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [weirds] I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt

          Probably not.

Possibly because different information is returned. In the com/net case Verisign returns information that describes DNS delegations to the host.  An RIR response describes address assignment.

Scott

---

From: Arturo Servin <[email-masked]>
Date: Tue, 1 May 2012 17:27:27 -0300

Ok, I get it now.

Regards,
as

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 2 May 2012 09:36:47 +1000

Given this case could be generalised to a reverse lookup search function based on arbitrary attributes, including name server IP address, I would support an approach around an individual submission for a search API extension.  I could see this as generic across names and numbers, if it is merely asking, essentially, for all <x> type records where attribute <x->a> is some value <v>.

Privacy concerns about whether this function should be provided for a particular attribute, or at all, with or without authorisation, should remain a local operator decision - the draft should follow the rir-response aim of minimising policy decisions taken within a technical protocol specification.

  Byron

---

From: "John Levine" <[email-masked]>
Date: 2 May 2012 04:02:51 -0000

> Querying for an IP and getting back names

I know that many people believe that, but I'm fairly sure you're
mistaken.  (Feel free to provide case law.)

As I pointed out to someone else, anyone can get zone file access for
gTLDs which provides all of that information and more.

R's,
John

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 2 May 2012 15:16:17 +0800

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> James Mitchell
> Sent: Tuesday, May 01, 2012 1:06 PM
> To: John Levine; [email-masked]
> Registries will limit the number of hosts returned from an IP address
query.
> This limit might be lifted should the registry offer different classes of
service for
> consumers such as law enforcement agencies etc.
> Knowing the limit has been reached would be useful.

Agree. This is might be one option. So requirements scope seems important.

> One should note that Base Agreement & Specifications (Specification 4) of
the
> new gTLD Applicant Guidebook
> <http://newgtlds.icann.org/en/applicants/agb/base-agreement-specs-11jan12
> -e
> n.pdf> requires Registries to provide name server responses for IP address
> input.
> 
Yes, the specification 4 of the AGB specifies the query format, whois
"NS1.EXAMPLE.TLD" or whois "nameserver (IP Address)". At least, new gTLD
applicants will follow the current specification and implement this
function.

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 2 May 2012 14:52:16 +0200

On 02-05-12 06:02, John Levine wrote:

> As I pointed out to someone else, anyone can get zone file access
> for gTLDs which provides all of that information and more.

Please broaden your scope if this is to fly.
Most ccTLD's don't provide zone file access.

Let's please focus on the main functionality that's needed, and don't
let this WG get hyjacked by maslow's hammer guys.

- -- 
Antoin Verschuren

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 02 May 2012 09:05:24 -0400

On 5/2/12 12:02 AM, John Levine wrote:

>> at least European database law.

case law would be definitive if europe was a common law jurisdiction,
as most of it isn't, prudent reading of the data protection directive
literature could support the belief you are sure is mistaken.

the authors of the w3c p3p spec (self included) anticipated that
personally identifying information was present in, or derivable from,
a portion of an ipv4 endpoint identifier. the spec group as a whole
settled on a /24 as sufficiently anonymous, i thought a larger bit
mask was prudent. i understand you think us mistaken, not as to fact,
but as to necessity.

> gTLDs which provides all of that information and more.

the gtld registries are permitted by their contract with the party
currently executing the iana contract to make zone file access subject
to conditions. the aggregate of the initial access cost (in time and
{e}paper touched and the conditions on continuous access, one of which
includes the bandwidth/storage cost of transferring the zone file of
principal interest, as well as access policy updates, are sufficiently
large to distinguish this use case from an unauthenticated transaction
with a payload containing a query with search terms to be executed by
the server.

-e

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 2 May 2012 09:29:12 -0400

> let this WG get hyjacked by maslow's hammer guys.

Indeed, it is this sort of rathole that some sceptics about names work
were thinking of when they argued that the names work would never
complete.  I'd like for us to show why that's mistaken.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Wed, 2 May 2012 14:33:22 +0000

+1

let's get the pure name stuff done first - IMHO "id" and "host" queries are too tied to particular data models and per-TLD policy.

Ray

---

From: Patrick Vande Walle <[email-masked]>
Date: Wed, 02 May 2012 17:01:43 +0200

> mistaken.  (Feel free to provide case law.)
<http://www.mondaq.com/x/162538/Copyright/ECJ+Confirms+That+IP+Addresses+Are+Personal+Data>
As Eric pointed out, there is no need for case law, although you will
find several judgements from the Europe an Court of Justice, national
courts, as well as opinions from the Article 27 Working Party and the
European Data Protection office that will all say that IP addresses are
personal data.  Google's your friend.  Now of course, there is a
difference in concept between an IP address assigned to your home CPE
and one assigned to a  DNS server.  This would require careful analysis.

This begs a question. Being rather new here, I would like to know if the
IETF has a process  in place for WGs to obtain  independent legal
guidance, rather than just engineers playing at being lawyers ? 

Patrick Vande Walle

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 2 May 2012 11:07:04 -0400

> guidance, rather than just engineers playing at being lawyers ? 

The IETF has legal counsel.  I think it's the IAOC that has to make
decisions about using it, since there's money involved.  I imagine an
AD would need to make a request, but I have no idea.  This came up for
me recently in the context of SPFBIS, and the answers were all "good
question", so I don't think there's a real procedure in place.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 2 May 2012 16:15:48 -0000

><http://www.mondaq.com/x/162538/Copyright/ECJ+Confirms+That+IP+Addresses+Are+Personal+Data>

That case was about mandatory web filtering, and presumably logging addresses
of individual http clients.  I see no relationship to the addresses of
name servers, which by their nature are unlikely to be on an individual's
computer and which are already published.

In any event, as I've said several times, this would be a useful
query, and if there are services that can't provide responses, so be
it.  Put it on the list of things that it would be to have and move
ahead.

>guidance, rather than just engineers playing at being lawyers ? 

No, the IETF develops standards, the use of which is entirely
voluntary.  It's up to you to obey the law of the jurisdiction where
you live.

R's,
John

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 02 May 2012 12:30:06 -0400

> 
> This begs a question. Being rather new here, I would like to know if the IETF has a process  in place for WGs to obtain  independent legal guidance, rather than just engineers playing at being lawyers ?  

it is sufficient to for the specification to support a scoping
mechanism which may be mapped to jurisdictional bounds on any of
connection formation, query, and response data.

note that historically, attempts to "fix" rfc954 have been had the
feature (or flaw) of asserting that no scope other than global was
necessary or sufficient, though ad hoc limitations on endpoints and
rates of query have been broadly adopted, and one or more limitations
on response data are contained in a registry contract with the party
currently executing the iana contract.

-e

---

From: Francisco Arias <[email-masked]>
Date: Thu, 3 May 2012 16:56:12 -0700

Hello,

Steve and I believe we may benefit by agreeing in a few basic principles
to guide our work. From this and previous discussions we'd suggest the
following guiding principles:

1. The protocol MUST enable policy options, not dictate them. (We should
specify all the features that are requested, subject to principle #2
below, without requiring them to be implemented. What to implement is a
registry/registrar/policy-maker decision outside of the scope of this
effort.)

2. We MUST only specify features that are already required/implemented by
registries/registrars. )Other features can be specified later by those
interested in extensions to the protocol.)

Thoughts?

__

Francisco.

---

From: Francisco Arias <[email-masked]>
Date: Thu, 3 May 2012 17:29:23 -0700

In the context of queries, the complexity starts when we talk about
searches as opposed to lookups. Perhaps we should separate those in two
different drafts.

The lookup specification (draft-hollenbeck-dnrd-ap-query) already
specifies a simple lookup mechanism for each object. I think it should
stay that way.

The search specification (no I-D yet) would specify how to do searches
that involve multiple search parameters and returns multiple objects
(perhaps it should return references to objects). For example we could
have something like:

/dnrd-ap/search/host/by?ip=1.2.3.4
/dnrd-ap/search/domain/by?registrant_id=ABC123&nameserver=ns.foo.bar

What search parameters a registry/registrar supports over each object, or
whether it implements searches at all, will be a registry/registrar's
policy-maker decision.

Thoughts?

__

Francisco.

On 5/1/12 10:19 AM, "Andy Newton" <[email-masked]> wrote:

>>non-uniform manners. Would be nice to avoid but I'm not going to fall on
>>my sword on this issue in this working group.
>
>Nobody knows if it increases the likelihood, but the probability of
>protocol extensions is there any way. If we attempt to throw every
>feature into the protocol now in fear of not being able to add extensions
>later, then it is gonna be really difficult to get the first revision out
>the door and thus will validate the fears of some of the critics of this
>work.
>
>Maybe we should keep a list of features desired but not for the first
>pass. Often the more complex use cases are clarified after an initial go
>round with the base features.
>
>-andy

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 3 May 2012 20:58:11 -0400

> registry/registrar/policy-maker decision outside of the scope of this

that is essentially what Wendy Seltzer said at the mic during last IETF. And it seems appropriate (to me).

> interested in extensions to the protocol.)

over design is often not good.

> Thoughts?

make sense to me.

Marc.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 03 May 2012 21:48:10 -0400

On 5/3/12 7:56 PM, Francisco Arias wrote:
> 1. The protocol MUST enable policy options, not dictate them.

in so far as that result scales, sure.

let us suppose some proposal is that queries may originate from any
routed address, at any rate (in effect, the current sla/tos for some
entities). this doesn't scale, and various address and rate limiting
schemes are in production.

the auth-optional policy (ok, so it is a auth-prohibited policy)
current has created an interoperable mess in the names playpen. could
we try not to repeat what we know isn't working now?

-e

ps: wendy, your comments at the last meeting were just cited, you may
want to read some back traffic.

---

From: Peter Koch <[email-masked]>
Date: Fri, 4 May 2012 10:57:21 +0200

> specify all the features that are requested, subject to principle #2

if only the boundary was that sharp. ("now that we have this nice
specification of the Guillotine, we really should do something with the
self sharpening blades ...")

> interested in extensions to the protocol.)

Limiting scope makes sense, but where's the threshold? At least one? The "majority"?
Is the ICANN/gTLD world what counts?

-Peter

---

From: Dave Piscitello <[email-masked]>
Date: Fri, 4 May 2012 06:04:37 -0700

I'm reminded of the Pirate's Code (Pirates of the Caribbean):

"There more like guidelines".

If I understand the original suggestion, we want a successor that has the features required and implemented today by registries and registrars. And we want extensibility to accommodate features that may be required in the future or are implemented by folks other than registries/registrars implement today.

The line doesn't have to be sharply defined in the guidelines.

Does anyone doubt that the parties to this list won't serve as satisfactory filters to assure that self-sharpening blades don't work their way into the drafts?

This said, I'm OK with proceeding as suggested.

---

From: Gavin Brown <[email-masked]>
Date: Fri, 04 May 2012 14:07:58 +0100

> searches as opposed to lookups. Perhaps we should separate those in two

I think this distinction is very important and I support the idea of
having a separate drafts to cover each scenario.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 4 May 2012 13:33:30 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Francisco Arias
> Sent: Thursday, May 03, 2012 4:56 PM
> To: [email-masked]
> Subject: [weirds] Scope and guiding principles (was Re: I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt)
> 
> 1. The protocol MUST enable policy options, not dictate them. (We
> should specify all the features that are requested, subject to
> principle #2 below, without requiring them to be implemented. What to
> implement is a registry/registrar/policy-maker decision outside of the
> scope of this
> effort.)
> 
> 2. We MUST only specify features that are already required/implemented
> by registries/registrars. )Other features can be specified later by
> those interested in extensions to the protocol.)

These make sense from a specification standpoint.  Where we need to be careful is that if such limitations end up being complete (i.e., no extensions to the current query model are ever implemented), then it still has to have been worthwhile to both clients and servers.

-MSK

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 4 May 2012 09:35:45 -0400

> These make sense from a specification standpoint.  Where we need to be careful is that if such limitations end up being complete (i.e., no extensions to the current query model are ever implemented…

right. the principles put foreword seems fine. However, the devil is in the details… Marc.

---

From: Arturo Servin <[email-masked]>
Date: Fri, 4 May 2012 10:42:26 -0300

As said, they are two different problems and should be deal differently IMHO.

	I support the idea of having the search functionality in another document.

Regards,
as

---

From: Arturo Servin <[email-masked]>
Date: Fri, 4 May 2012 10:43:58 -0300

As guidelines not written in stone I am ok with them.

	I'll be happier having a SHOULD in the second one but I am not opposed to the current form.

Regards,
as

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 4 May 2012 14:23:35 +0000

> Sent: Thursday, May 03, 2012 7:56 PM
> To: [email-masked]

[snip]
> by

I'm definitely in favor of this idea. Not supporting current use cases will have a negative impact on adoption.

It would be very helpful to identify the query parameters that registries and registrars currently support. As a start, here's what we currently support at Verisign for lookups:

Domain: by domain name (example.com)
Name server: by host name (ns1.example.com) and by IP address (v4 and v6 text format)
Registrar: by registrar name (text string case insensitive match) and by registrar ID
Contact: by EPP contact ID and by EPP ROID

Scott

---

From: Ray Bellis <[email-masked]>
Date: Fri, 4 May 2012 14:33:46 +0000

> Contact: by EPP contact ID and by EPP ROID

.uk only supports "domain: by domain name".

Ray

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 04 May 2012 10:35:31 -0400

> "There more like guidelines".

rfc954, page 1, paragraph 4:

"DCA requests that each individual with a directory on an ARPANET or
MILNET host, who is capable of passing traffic across the DoD
Internet, be registered in the NIC WHOIS Database.  MILNET TAC users
must be registered in the database."

the document was pre-upper-case-must, and the dca "request" was the
funding and contract managing agency. non-compliance was remarkably
rare, and due to policy constraints external to 954, use of
directories on hosts attached to nets 26 and 10 excited no interest in
civilian law and/or rights enforcements.

"guidelines" can't be standards track. a spec that substantively
narrows the existing, and reduces the necessity for new, divergence in
data models, access and authentication mechanisms, and data exchange
formats, in globally unique endpoint identifier registries may be
advisory (and obviously compelled by some contracting regime for some
set of registries), and it may also be required.

the latter may be preferable to the former, so long as it remains
broadly applicable and not marred by errors of restriction of
applicable scope.

-e

---

From: Andy Newton <[email-masked]>
Date: Fri, 4 May 2012 14:54:44 +0000

> 	I support the idea of having the search functionality in another document.

+1.

-andy

---

From: Andy Newton <[email-masked]>
Date: Fri, 4 May 2012 14:54:45 +0000

> interested in extensions to the protocol.)

I agree.

-andy

---

From: Andy Newton <[email-masked]>
Date: Fri, 4 May 2012 14:59:56 +0000

> Contact: by EPP contact ID and by EPP ROID

Given Francisco's suggestion, would it be worth teasing each of these out into separate drafts? That way ICANN can say that it's regulated registries support must support RFC 1, RFC 2, RFC 3, while other registries can simply say "we support RFC 1 and RFC 3". Or maybe put the domain name lookup in its own draft and the rest in a draft intended as a collection of the other things ICANN registries must do. Just a thought.

No matter what, I think registrar-by-name should be a separate draft as it seems like a search and not a lookup.

-andy

---

From: "Luis Diego Espinoza S." <[email-masked]>
Date: Fri, 4 May 2012 09:08:50 -0600

+1

-- 
Luis D. Espinoza
Chief Technology Officer
NIC-Internet Costa Rica
National Academy of Science
San Jose, Costa Rica
Cel:   +506.8850.9018
Tel:     +506.2280.6453
Tel/fax: +506.2280.5361
Skype: lespinoz

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 04 May 2012 11:09:18 -0400

On 5/4/12 10:23 AM, Hollenbeck, Scott wrote:
> It would be very helpful to identify the query parameters that registries and registrars currently support.

c: have you got any jacks?
s: go fish.

in the conficker .C scenario, it was useful to ask "have you got any
of {enumerated set of strings}?" as the set was algorithmically
generated, the query could have been "if you have, or when you have,
an instance of an algorithm of interest registered, or presented to be
registered, do something." this was done out of band, manually.

for instances of distributed systems with automated rendezvous point
generation, for which the system can be caused to fail, or at least
stall on resource wait, a query on a static enumerated identifier set,
or an algorithm to produce a dynamic enumerated identifier set,
appears (to me) to be useful, in theory.

there are a bunch more use cases to scratch out, from
names-containing-nike to addresses-in-botc&c-block, etc.

scott's got an idea, document what exists.

i've another. document what is advisable for operators (this assumes
that some operators will adopt advice, which in turn assumes that some
operators will use platform resources other than those which now
exist) for their use case.

as no one is asking complex questions of gtld registries with
restrictions on registrations, e.g., aero, coop, museum, cat, and
perhaps others, there isn't a lot of search term relevant advice to
offer. as lots of queries are generated daily asking complex questions
of gtld registries with no restrictions on registrations, e.g., com,
net, org, biz, info, and perhaps others, there is some search term
relevant advice to offer.

-e

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 4 May 2012 15:14:41 +0000

> From: Andy Newton [mailto:[email-masked]]
> Sent: Friday, May 04, 2012 11:00 AM
> To: Hollenbeck, Scott
> Cc: Francisco Arias; [email-masked]
> Subject: Re: [weirds] Query Parameters
> 
> 
> > It would be very helpful to identify the query parameters that
> registries and registrars currently support. As a start, here's what we
> currently support at Verisign for lookups:
> >
> Given Francisco's suggestion, would it be worth teasing each of these
> out into separate drafts? That way ICANN can say that it's regulated
> registries support must support RFC 1, RFC 2, RFC 3, while other
> registries can simply say "we support RFC 1 and RFC 3". Or maybe put
> the domain name lookup in its own draft and the rest in a draft
> intended as a collection of the other things ICANN registries must do.
> Just a thought.

Maybe, I'm not sure. If I'm writing client code I would probably want to support as many query parameters as possible to work with as many servers as possible, and having all client query parameters specified in one document would probably be easier than having to worry about multiple documents. A server operator that doesn't support a particular type of query can just return an appropriate HTTP response.

I guess I'm saying that I don't think we should be writing clients on a per-registry basis.

Scott

---

From: Andy Newton <[email-masked]>
Date: Fri, 4 May 2012 15:54:38 +0000

> I guess I'm saying that I don't think we should be writing clients on a per-registry basis.

Good point. I still agree with Francisco's idea of separating search drafts out.

Perhaps we should think about an Informational that describes everything and references all the drafts. I think the original URN working group did this.

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 4 May 2012 16:26:20 +0000

> Sent: Friday, May 04, 2012 11:55 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> > Maybe, I'm not sure. If I'm writing client code I would probably want
> to support as many query parameters as possible to work with as many
> servers as possible, and having all client query parameters specified
> in one document would probably be easier than having to worry about
> multiple documents. A server operator that doesn't support a particular
> type of query can just return an appropriate HTTP response.
> >

I do, too.

> Perhaps we should think about an Informational that describes
> everything and references all the drafts. I think the original URN
> working group did this.

That sounds like a good idea.

Scott

---

From: Hugo Salgado <[email-masked]>
Date: Fri, 04 May 2012 13:12:01 -0400

In the .CL case, we as a registry allow approximate search queries in
the domain name, and were thinking in something like

 /dnrd-ap/search/domain/by?name=<query>;match=begining

as we have 3 types of matching: begining (^query*), ending (*query$)
and in-between (*query*).

We know this is something unusual, so it's something we can cope with
a protocol extension.

Hugo

---

From: "John Levine" <[email-masked]>
Date: 4 May 2012 17:17:47 -0000

>> 1. The protocol MUST enable policy options, not dictate them.

Yes.  It is in the nature of standards that they can't force anyone to
do anything, just tell people how to interoperate.

>> interested in extensions to the protocol.)

Yes.  It would be fine to keep a laundry list of features that someone would
like to add eventually but don't currently qualify.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 4 May 2012 17:19:30 -0000

>These make sense from a specification standpoint.  Where we need to be careful is that if such
>limitations end up being complete (i.e., no extensions to the current query model are ever
>implemented), then it still has to have been worthwhile to both clients and servers.

If it provides what the current WHOIS is supposed to provide, but with
consistent query syntax and machine parsable results, that would be
plenty worthwhile.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 4 May 2012 17:53:55 -0000

>> out into separate drafts? 

No, definitely not.  The draft should say here's how a client asks question X, and
the server can either return a response in the presribed format, or an error
code that means "I don't know" or "I won't tell you."

I don't think it's unreasonable to ask registries to implement the trivial
amount of extra code to return don't know responses to queries they don't
handle.

R's,
John

---

From: Francisco Arias <[email-masked]>
Date: Fri, 4 May 2012 11:20:10 -0700

>Is the ICANN/gTLD world what counts?

At least one.

And to clarify, I'm not proposing to do an inventory of all the registries
and registrars are doing, but if/when someone comes here and says ABC
registry/registrar is doing XYZ.

__

Francisco.

---

From: Francisco Arias <[email-masked]>
Date: Fri, 4 May 2012 11:51:06 -0700

On 5/4/12 7:59 AM, "Andy Newton" <[email-masked]> wrote:

>Given Francisco's suggestion, would it be worth teasing each of these out
>into separate drafts? That way ICANN can say that it's regulated
>registries can simply say "we support RFC 1 and RFC 3". Or maybe put the
>domain name lookup in its own draft and the rest in a draft intended as a
>collection of the other things ICANN registries must do. Just a thought.

Yes, but I thing it goes beyond that. A registry(ar) would say "we support
RFC 1 (lookup) and RFC 3 (searches) on the following objects ... using the
following elements ..."

I'm thinking the searches document should probably simply specify how to
do the searches on any single object, using any combination of its
respective elements/attributes. But it would be up to each registry(ar) to
choose which combination to support. Therefore, as someone else suggested,
there has to be a response that signals "search not supported" or
something similar.

__

Francisco.

---

From: Steve Sheng <[email-masked]>
Date: Fri, 4 May 2012 11:51:36 -0700

-----Original Message-----
From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 4 May 2012 07:23:35 -0700
To: Francisco Arias <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: [weirds] Query Parameters

>It would be very helpful to identify the query parameters that registries
>and registrars currently support. As a start, here's what we currently
>support at Verisign for lookups:
>

For each gTLD registry contracts with ICANN, it contain specifications on
how a registry is to offer WHOIS service, I surveyed all those
specifications (18 gTLD + new gTLD applicant guidebook) yesterday and here
is what I found: 

 /domain/  - 100% allow query by the domain name.
	 - 1 offer query by ACE of the domain name. (.CAT)
	 - 1 offer query by domain ID (.CAT)

 /contact/ - 100% of the thick registries offer query by contact ID
	  - functionality not offered in thin registries
	  - no other searches are allowed

 /nameserver/ - 100% allow queries by the fully qualified hostname
	     - 100% allow queries by the IP address
	     - 2 allow queries by host id maintained by registry (.CAT, .TEL)

 /registrar/  - 100% allow queries by registr name.
	    - 3 allows queries by registrar ID (.NAME, .CAT, .TEL) 		

/default/ -domain name is searched.

Spreadsheet attached, I hope this would be of some use to the group. Let
me know what further work is needed to help make progress.

Kind regards, 
Steve

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 04 May 2012 14:54:07 -0400

steve,

that was useful work. thanks.

-e

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 4 May 2012 19:03:46 +0000

Excellent - thanks! I'll use this to update our draft.

Scott

> From: Steve Sheng [mailto:[email-masked]]
> Sent: Friday, May 04, 2012 2:52 PM
> To: Hollenbeck, Scott; Francisco Arias; [email-masked]
> For each gTLD registry contracts with ICANN, it contain specifications
> on how a registry is to offer WHOIS service, I surveyed all those
> specifications (18 gTLD + new gTLD applicant guidebook) yesterday and
> here is what I found:
> 
> 
> Spreadsheet attached, I hope this would be of some use to the group.
> Let me know what further work is needed to help make progress.
> 
> Kind regards,
> Steve

---

From: Frederico A C Neves <[email-masked]>
Date: Sat, 5 May 2012 22:32:46 -0300

On Fri, May 04, 2012 at 02:23:35PM +0000, Hollenbeck, Scott wrote:
...
> Contact: by EPP contact ID and by EPP ROID

.br supports,

Domain: by domain name (dns.br)
Owner: by Public OwnerID returning a list domains 
Registrar: by registrar ID (P23)
Contact: by EPP contact ID (FAN)

> Scott

Fred

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 8 May 2012 09:43:59 +0200

On 04-05-12 20:20, Francisco Arias wrote:
>>> 2. We MUST only specify features that are already
>>> required/implemented by registries/registrars. )Other features
>>> can be specified later by those interested in extensions to the
>>> protocol.)
>> 
>> Limiting scope makes sense, but where's the threshold? At least
>> one? The "majority"? Is the ICANN/gTLD world what counts?
> 
> At least one.

I disagree. I'd say majority or consensus, otherwise we'll not succeed
to create anything and be discussing for the next 20 years for the
feasibility of a registry specific feature, or local law specific
request. Let's start with what's out there today.

And since it is protocol, it must fit RIR's/gTLD's/ccTLD's, where some
RIR queries are not used by TLD's and visa versa, but anyone
understands a TLD does not have to implement f.e. route objects.

- -- 
Antoin Verschuren

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 8 May 2012 09:47:54 +0200

On 04-05-12 16:33, Ray Bellis wrote:
>> Domain: by domain name (example.com) Name server: by host name
>> (ns1.example.com) and by IP address (v4 and v6 text format) 
>> Registrar: by registrar name (text string case insensitive match)
>> and by registrar ID Contact: by EPP contact ID and by EPP ROID
> 

.nl only supports "domain: by domain name" as well.

- -- 
Antoin Verschuren

---

From: Jim Galvin <[email-masked]>
Date: Tue, 08 May 2012 11:01:35 -0400

-- On May 3, 2012 4:56:12 PM -0700 Francisco Arias 
<[email-masked]> wrote regarding [weirds] Scope and guiding 
principles (was Re: I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt) 
--

> Steve and I believe we may benefit by agreeing in a few basic
> principles to guide our work. From this and previous discussions we'd
> suggest the following guiding principles:
>
> required/implemented by registries/registrars.

I agree in principle.  As with many things, it's about how we as a 
group and our chairs manage things, as has been mentioned by others 
responding to this thread.

I'm reminded of a quote often used in development groups:  The 
difference between theory (principle?) and practice in practice is much 
greater than the difference between theory and practice in theory.

Jim

---

From: Jim Galvin <[email-masked]>
Date: Tue, 08 May 2012 11:03:45 -0400

-- On May 3, 2012 5:29:23 PM -0700 Francisco Arias 
<[email-masked]> wrote regarding [weirds] Lookups vs 
Searches (was Re: I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt) --

> searches as opposed to lookups. Perhaps we should separate those in
> two different drafts.

+1

Jim

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 08 May 2012 12:45:17 -0400

On 5/8/12 3:43 AM, Antoin Verschuren wrote:
> ... I'd say majority or consensus, otherwise we'll not succeed
> request. ...

i lack your foresight. i've no idea if accommodating a specific
requirement, that is, ensuring that over-specification is avoided,
will result in no specification (that seems to be contradictory) and
twenty years of discussion.

in passing, the .cat rsep to distinguish between registry published
data (on port 43) for natural persons and legal persons (aka "people"
and "businesses") was approved at the current iana contractor's board
meeting of 2012.05.06, see item 2 on the consent agenda.

> ... Let's start with what's out there today.

the current iana contractor has accepted over 2,000 applications for
delegations from the iana root to be made as early as the orlando
meeting, completing no later than the honolulu meeting. the plan of
record of the current iana contractor is to repeat the process it
began this year periodically.

wglc on work product may occur prior to new delegations from the iana
root, but it may not. in any event, the utility of a standard for the
2000-2012 domains-and-addresses allocators and allocatees is bounded.

> And since it is protocol, it must fit RIR's/gTLD's/ccTLD's ...

i'm not quite as optimistic about the proper scope of a standards body
drafted specification of an endpoint identifier allocation query
mechanism.

i can hope it must fit rirs, but it may be prudent to ensure it fits
another ir regime.

i can hope it must fit a gtld contractual regime, but i know it would
be no less useful if it is capable of fitting at last one additional
regime, and is, in general, contractor and regime independent.

i can hope it must fit a useful set of ccTLDs, but these are, in
general, arbitrary sources of requirements.

To restate peter koch's reasonable query: "limiting scope makes sense,
but where's the threshold? at least one? the "majority"? is it the
icann/gtld world what counts?"

exclusion of a requirement must not be capricious, it must be the
consequence of an inability to reconcile that requirement with other
requirements.

my impression, from the domain tasting period, the fastflux working
group, the conficker .c response effort, and incidental conversations
with individuals professionally engaged in rights enforcement, private
and public, is that registration policy -- actual cost in complexity
(time cost) and cash (real dollar cost), are at least as useful as
registry types (supra) at determining utility and necessity of use
cases and therefore requirements.

-e