Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt

From: Bob Bruen <[email-masked]>
Date: Tue, 12 Jun 2012 13:17:10 -0400 (EDT)

Hi Andrew,

People want the information in one go because they want the information, 
not just because they have tools. If you want to offer
something better, you should not offer less. I am one of those people who 
use the information in whois (not for marketing or
spam).

Murray and John and some LE folks may be willing to trade off, but a lot 
of us are not. I also think there is a difference
between individuals and businesses - if you to differentiate a service 
level, this could be one.

              --bob

On Tue, 12 Jun 2012, Andrew Sullivan wrote:

> On Tue, Jun 12, 2012 at 11:02:45AM -0400, Andy Newton wrote:
> >
> > How did you make that logic jump? Redacting information isn't rocket
> > science.
>
> I suppose the alternative is to redact information in responses
> according to the credentials presented.  We could use some sort of
> http header to warn that some data has been redacted because of lack
> of authentication?
>
> > Our experience is that people want all the information in one go.
>
> I'm sure this is true.  Of course, this is partly because everyone has
> a large number of tools built around the assumptions of WHOIS.  I
> think our hope is to offer something better, right?
>
> > Finally, this seems like a corner case. There has yet to be a single
> > example given on this list of any authorization scheme or needed
> > authentication mechanism.
>
> That's not true.  First, Murray and John have both said that they'd be
> entirely willing to trade away the accessibility of contact
> information for authenticated confirmation that two resources
> (e.g. two names or two netblocks) are related according to some
> criteria.  I've heard law enforcement people say the same thing, so
> I'm sure it's valuable.  Second, we know that name registrants
> frequently futz with their contact data in a bid to protect their
> personally identifying information from being completely and trivially
> public.  Addressing any of these cases is going to require rules about
> authentication and authorization.
>
> Best,
>
> A
>

-- 
Dr. Robert Bruen
http://knujon.org
http://coldrain.net/bruen
+1.802.579.6288

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 14 Jun 2012 20:33:09 +0200

On Tue 12/Jun/2012 19:17:10 +0200 Bob Bruen wrote:
> 
> Murray and John and some LE folks may be willing to trade off, but
> a lot of us are not. I also think there is a difference between
> individuals and businesses - if you to differentiate a service 

LE and gov (especially for CCTLDs) agencies would be better qualifiers
than business/ individual --what business?  CAs are a business that
should qualify for such differentiation, whether they have a VAT
number or not.

How do WHOIS providers currently manage group authorizations?

Will the 1.For-all-implementers structure that Olaf mentioned in
http://www.ietf.org/mail-archive/web/weirds/current/msg01131.html
also define an auth layer, OAuth or similar?

---

From: Bob Bruen <[email-masked]>
Date: Thu, 14 Jun 2012 15:13:50 -0400 (EDT)

Hi Alessandro,

This is just my opinon:

The difference is between individuals, protected by EU privacy rules (and 
should be protected in other countries), and organizations that make 
money, not privacy protected. Spammers and other criminals make money, 
thus should not have their whois information protected from public access, 
any more than a business selling grapefruit.

            --bob

On Thu, 14 Jun 2012, Alessandro Vesely wrote:

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

---

From: "\"Michele Neylon :: Blacknight\"" <[email-masked]>
Date: Thu, 14 Jun 2012 19:20:37 +0000

On 14 Jun 2012, at 20:13, Bob Bruen wrote:

> 
> Hi Alessandro,
> 
> This is just my opinon:
> 
> The difference is between individuals, protected by EU privacy rules (and should be protected in other countries), and organizations that make money, not privacy protected. Spammers and other criminals make money, thus should not have their whois information protected from public access, any more than a business selling grapefruit.

And I'd actually agree with that (personally), though the privacy debate is probably way off topic here :) 

Regards

Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
http://www.blacknight.com/
http://blog.blacknight.com/
http://mneylon.tel/
Intl. +353 (0) 59  9183072
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Fax. +353 (0) 1 4811 763
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 14 Jun 2012 16:00:06 -0400

>> > The difference is between individuals, protected by EU privacy rules (and should be protected in other countries), and organizations that make money, not privacy protected. Spammers and other cr…

at first glance this appears to be an add to the data model, inserting
the unfortunate epp binary publish/don't-publish toggle into the data
at the registrant, natural person / legal person indicator.

of course, that indicator doesn't exist or is inferred heuristically,
making automated processing problematic.

to add to the complexity, there is the for-profit (and profitable) vs
non-profit ...

work on the p3p spec was illuminating. the treaty of europe is
cognizant of past harms to religious and ethnic social identities and
the data protection directive attempts to prevent these harms by
preventing targeting religious and ethnic social identities. it is a
stretch to think the protection is restricted to individuals, not to
associations of individuals, such as synagog members and rom speakers.

> And I'd actually agree with that (personally), though the privacy debate is probably way off topic here :) 

its not so much a "privacy debate" as it is an vague and probably
quite difficult data model proposal.

-e

---

From: "\"Michele Neylon :: Blacknight\"" <[email-masked]>
Date: Thu, 14 Jun 2012 20:32:54 +0000

> quite difficult data model proposal.

Agreed.

---

From: Alan Maitland <[email-masked]>
Date: Thu, 14 Jun 2012 21:57:19 -0600

Respectfully, privacy is very important as it relates to design 
considerations and discussions for what is and what may not be 
releasable information from the registries and how that information may 
be switched on or off at the registries for each other or public data 
consumers.

I absolutely agree with Bob on his point.  Logically, I cannot think of 
any reason that a commercial business should ever be entitled to privacy 
in the sense of being able not being able locate and identify the 
business - especially so when that "business" reaches out to touch my 
own business or those of my clients in a less than neighborly way.

Alan Maitland

On 6/14/2012 1:20 PM, "Michele Neylon :: Blacknight" wrote:
> Hosting&  Colocation, Brand Protection

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 15 Jun 2012 00:11:46 -0400

On 6/14/12 11:57 PM, Alan Maitland wrote:
> Respectfully, privacy is very important ...

and you're the first person to ever think of that.

> Logically, I cannot think of any reason that a commercial business ...

and how, mr. spock, do you propose to distinguish "commercial
business" {numbers,names} registrants from any other registrants?

-e

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 15 Jun 2012 00:16:28 -0400

On Thu, Jun 14, 2012 at 09:57:19PM -0600, Alan Maitland wrote:

> I absolutely agree with Bob on his point.  Logically, I cannot think
> of any reason that a commercial business should ever be entitled to
> privacy in the sense of being able not being able locate and

None of that is relevant to this question.  Whether something is a
particular policy that we think ought to be implemented in some
particular case is not the question; the question is, does the
protocol need to accommodate the use case under some circumstances?

We have at least one use case ("ordinary schlub who has registered a
domain name for other than commercial purposes") where it seems
important to be able to make distinctions between completely anonymous
access to that data, and access to that data when the requester has
been authenticated and is authorized to collect the data.  If there is
reason to believe that the use case is one we should worry about (and
I think there is such a reason), then we need that mechanism in the
protocol.  How that mechanism gets used in the future is not our job
to decide.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 15 Jun 2012 04:40:41 -0000

>business" {numbers,names} registrants from any other registrants?

Seems like an ideal application for RFC 3514.

R's,
John

---

From: Alan Maitland <[email-masked]>
Date: Thu, 14 Jun 2012 22:44:58 -0600

> and you're the first person to ever think of that.

Taking a list member's statement out of context for effect is arguably a 
cheap shot.  The original poster appeared to think that privacy was not 
relevant to the discussion at hand.  I disagreed as regards design 
considerations and discussions focused on the WIERDS specification.

> business" {numbers,names} registrants from any other registrants?

It does not take much to actually ask in the registrant's registry 
application for {names,numbers}.  Also logically, it would make sense to 
have a penalty associated with providing a provably invalid or 
inaccurate response.

That said, this is the kind of thing is something for the registries to 
determine how they would like to implement or not.  The point is that 
the specification must be flexible enough to address the need.

> -e
Alan

---

From: Alan Maitland <[email-masked]>
Date: Thu, 14 Jun 2012 23:01:07 -0600

> protocol need to accommodate the use case under some circumstances?

Your point is well taken.

> protocol.  How that mechanism gets used in the future is not our job

Agreed.  The Internet has changed remarkably over the past 20 years and 
some of the issues we have today were apparently not seen or not 
considered worthy of addressing (for whatever reasons) in the days of 
some of the earlier RFCs.

Hopefully many who develop specification documents would agree that it 
seems misguided to develop a specification designed to address a need 
without considering the environment in which the specification 
addressing the need will reside.  Perhaps this might be why you think 
that there is a reason to add a mechanism for authentication of the 
requester and authorization to use specific data in part or in total - 
that kind of thinking in the specification design allows the actual 
implementers of the specification more choice and flexibility in their 
implementations while maintaining interoperability... which is almost 
always a good thing.

Alan

---

From: Alan Maitland <[email-masked]>
Date: Thu, 14 Jun 2012 23:09:26 -0600

> Seems like an ideal application for RFC 3514.

Of course... along with the ultimate sure fire application solution 
which solves all security problems...  What was that acronym used a lot 
in a list working to address email "issues"?  Thought you may have 
coined it...

Thank you for improving the mood, really quite a fun RFC to read - date 
noted.

Alan

---

From: SM <[email-masked]>
Date: Thu, 14 Jun 2012 23:44:47 -0700

Hi Alan,
At 22:01 14-06-2012, Alan Maitland wrote:
>Agreed.  The Internet has changed remarkably over the past 20 years 
>and some of the issues we have today were apparently not seen or not 
>considered worthy of addressing (for whatever reasons) in the days 
>of some of the earlier RFCs.

Some of the issues seen today can be traced back to the past.  There 
are two words in draft-kucherawy-weirds-requirements-04 which may be 
of interest.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Jun 2012 23:47:44 -0700

> protocol.  How that mechanism gets used in the future is not our job
Everything Andrew said is true.  But this discussion is likely to reappear
as this work reaches an increasingly wider audience.  I imagine we would be
wise to think about a Privacy Considerations section in some or all of our
specification documents, even if only to reflect Andrew's point above.

-MSK, participatin'

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 15 Jun 2012 10:09:07 +0200

On Thu 14/Jun/2012 21:13:50 +0200 Bob Bruen wrote:
> 
> The difference is between individuals, protected by EU privacy rules
> (and should be protected in other countries), and organizations that
> make money, not privacy protected.

Uh, I thought you were addressing data consumers rather than data
subjects.  My questions were meant for the former case.

> Spammers and other criminals make money, thus should not have their
> whois information protected from public access, any more than a
> business selling grapefruit.

Agreed.  IMHO it would be a good idea to discern domains registered
for generic publishing purposes from specific categories that deserve
special care, such as email and e-commerce.  (Enforcement can use
outgoing connections to port 25, commerce-enabling certificates, and,
of course, the evil bit.)

>> CAs are a business that should qualify for such differentiation,
>> whether they have a VAT number or not.
>>

---

From: Don Blumenthal <[email-masked]>
Date: Fri, 15 Jun 2012 08:03:35 -0400

:)

I hadn't thought of that in a awhile.

Or 1149, although I don't see how it could apply here.

---

From: Andy Newton <[email-masked]>
Date: Fri, 15 Jun 2012 08:30:44 -0400

On Jun 15, 2012, at 2:47 AM, Murray S. Kucherawy wrote:

> Everything Andrew said is true.  But this discussion is likely to reappear as this work reaches an increasingly wider audience.  I imagine we would be wise to think about a Privacy Considerations section in some or all of our specification documents, even if only to reflect Andrew's point above.

That would be one long Privacy Considerations section.

Perhaps a "Use Cases" draft is appropriate and would focus this conversation. Andrew has now give 3 use cases, maybe they should be documented. Also, documenting each use case from the perspective of the data consumer, data subject, and data supplier would likely shed light on what is needed.

-andy

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 15 Jun 2012 08:47:33 -0400

On 6/15/12 12:44 AM, Alan Maitland wrote:
> Taking a list member's statement out of context for effect is arguably
> a cheap shot.  The original poster appeared to think that privacy was
> not relevant to the discussion at hand.  I disagreed as regards design

there are people who (a) think their local definition of {us
contractual privacy|eu treaty of europe data protection|oedc hybrid}
is global, and (b) that {privacy|dataprotection|hybrid} is "policy",
for which no mechanism is properly the subject of specification.

with that given, exactly what is your contribution to the
specification under discussion?

> application for {names,numbers}.  Also logically, it would make sense
> to have a penalty associated with providing a provably invalid or
> inaccurate response.

again, you're the first person to ever think of that. alternatively,
others have and they've been wildly successful at mechanically
discerning registrant intent and purpose and cleaning up bad data in
the cnobi registry set.

> That said, this is the kind of thing is something for the registries
> to determine how they would like to implement or not.  The point is
> that the specification must be flexible enough to address the need.

could you be a bit more specific? are you asking for an evil bit the
query respondent(s) can set to indicate some registration-time evident
or post-registration discovered state of non-grace which the query
originators can put to some use satisfying an existing, or novel, use
case? as levin noted, see 3514.

-e

---

From: "John Levine" <[email-masked]>
Date: 15 Jun 2012 15:04:26 -0000

>Perhaps a "Use Cases" draft is appropriate and would focus this conversation.

Yes, please.  That could be very helpful to people trying to implement this stuff.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Fri, 15 Jun 2012 12:40:03 -0400

> Yes, please.  That could be very helpful to people trying to implement this stuff.

BTW, I was not volunteering to write it. :)

-andy

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 15 Jun 2012 12:42:03 -0400

> BTW, I was not volunteering to write it. :)

I suppose, since I already listed three, I can volunteer.  I don't
expect we'll actually publish it, but we can have a draft to focus
conversation.  How's that?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alan Maitland <[email-masked]>
Date: Fri, 15 Jun 2012 12:00:00 -0600

> specification under discussion?

 From reading messages on the list, some members of the list are 
apparently supportive of a simpler specification, which appears to only 
address a common set of data across all registries (both names and 
numbers).  It may prove challenging to get a consensus on that strategy 
from all the registries, as past efforts attempting to employ that 
approach have apparently not been greatly successful in their adoption.

Others on the list are supportive of a more robust specification which 
addresses a foreseeable need to allow for all of the points of the 
"people who (a).. (b).." etc.  It is precisely because data access and 
privacy needs differ in different parts of the world that it is 
important to consider those items in the specification.

My observations were made in order to underscore agreement with the 
thinking that supports the broader based design for the specification, 
which would better address the varied needs of all the desperate 
registries (and laws under which they operation) through a common 
specification that attempts to address the real world considerations to 
which these registries must adhere.

> discerning registrant intent and purpose and cleaning up bad data in

You asked a question and I proffered an answer.  As you allude, others 
agree with my answer (of course, I was not the first to think of that). 
  However, if you did not want an answer or simply asked to fire off 
another remark of questionable intent, I would submit, that you should 
probably not ask in the first place.

> case? as levin noted, see 3514.

WIERDS is not a specification for a reputation system.  That said, in 
addressing the possible foreseeable needs of the registries as regards 
data private/public data exchange by way of example, it might be 
convenient from a security standpoint (for the purpose of the example) 
to allow for some way to (minimally) track and classify the currently 
observed behavior of any registrant.

By way of analogy, in some arbitrary global location, if you have people 
at your party who are engaged in illegal or questionable activity, then 
you, as the host, have a moral obligation to your other well behaved 
guests to address the behavior of the one engaged in the problem 
activity.  If you have no way to track or identify who the problem party 
goers are, you have failed in your duties as a good host.  In some other 
parts of the world, perhaps that is not the case (i.e., because the 
moral imperative may be different).

So again, having a robust specification addressing certain data 
important to a subset of registries, but not needing to enforce a 
requirement for said data on other registries who may not need or be 
allowed to keep such data, allows each registry adopter the option of 
enabling or not enabling various data for use within a common shared 
framework.  That thinking would appear a useful thing to embed into a 
specification with a population of registrars with disparate data 
gathering/reporting needs.

Finally, John Levine's post to the list referencing RFC 3514 was indeed 
enjoyed and quite a bit of fun.  I suspect this as his intent in making 
that contribution to the discussion thread.

Alan

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 15 Jun 2012 16:00:52 -0400

> I suppose, since I already listed three, I can volunteer. ...

good for you ;-)

some possibilities:

1. fastflux, frequent changes to rrset, so "are there" in query to
zone editor, or a temporal window in which two or more changes took
place, a "yes" condition waives jurisdictionally appropriate bar on
publication.

the condition relates to use "for good" of the technique, for which
examples exist.

2. typosquat, string within damerau-levenshtein metric of registered
mark. again, a yes waives ... and we may have a database of registered
marks in the near future (icann policy playpen).

3. fraud, requires a "payment not repudiated" toggle, a modify bit
that can be tossed over the fence (to ourselves) in the provisioning
policy playpen. for all those credit card "purchases" that last only
hours or days before being scotched. alt, registrars that don't take
cards, e.g., mine, ignore exception for queries made for registrations
within the industry payment repudiation window, e.g., 30 days.

4. algorithmic names, .C variant, if name is within registered
cluster, which requires cluster registration conveniences, then a yes
waives ...

5. display property of names, this is something we tried to make
unnecessary in idna (latest) but it remains an area for exploits and
registry error, infix "1" (as "l") in an alpha sequence, etc, for any
script supported.

none of these attempt to divine the purpose of the registrant, just
some common properties of strings, or rrsets, that come to mind.

-e

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 15 Jun 2012 16:43:49 -0400

On 6/15/12 12:42 PM, Andrew Sullivan wrote:
> ... I don't

upon reflection i think it is inadequate.

the whole point of use cases is to state the problems to be solved, in
a particular narrative or stylistic form.

non-publication means only the archival work products, the mailing
list, and drafts that are ultimately left to expire, present the
problem(s) to be solved purpose of any published specification. the
future modification implementers will have to discover "why did they
do that" for themselves, possibly arriving at the same conclusion as
the specification's earlier authors.

[check: can you figure out why we did what we did for each obscure
edge case in the idna2003 doc set from the doc set? does reading
klensin's lengthy and occasionally tangled prose answer all your
questions for something as recent as idna-latest?]

further, since this, wierds, is supposed to finally settle the
festering hash of names, and without loss of generality or harm, be
useful for numbers, several sacred cows are ... slated for the barbi.
explaining why privacy|dataprotection is and isn't observed via the
several use cases means the affected users of registry systems, and
the operators of components of registry systems, will have a clue as
to what semantic attaches via what syntax to what underlying datum,
and how exceptions to general rules are defined and implemented.

so i suggest the editor aim for publication, and not merely informational.

-e