Subject: Re: [weirds] policy & tech

From: Bob Bruen <[email-masked]>
Date: Tue, 12 Jun 2012 14:51:53 -0400 (EDT)

Hi Andrew,

On  Tue, 12 Jun 2012 14:14:00 -0400, Andrew Sullivan wrote:

> No, I want the protocol to make _possible_ a policy.

That is a policy decision. By adding capabilities to anything you create 
its potential use. By deciding not to add, you are denying its use. Either 
way, it's a policy decision at an early stage and it should be considered 
carefully. This particular capability is chosen and another is not. Why 
pick one and not another?

> It could be that nobody will turn this knob on.  If that were to happen, 
> then the protocol would have a needless feature, and that is bad.
> But I predict that someone will turn that knob on, ...

There is no doubt that it will be used, just like thick and thin whois 
records limit what is seen on a whois record. There are also other ways 
used to limit the data seen.

> ...because a significant chunk of WHOIS complaints come from people who 
> claim that the exposure of all that contact information is in violation 
> of certain national implementations of EU data protection directorates.

That, in fact, is an established claim.

> I have no idea whether that is true, and don't care, because if we have 
> a protocol that supports such policy decisions then we have offered the 
> necessary technical supports.

Well, you should care because you are helping to create the technology 
which will determine the use of whois for a long time.

> What you appear to be arguing is that you have a preferred policy
> outcome, and that therefore the protocol should be written to make
> sure an alternative isn't possible.

I do have a preferred outcome, as do you, and we both have expressed 
our opinion. I am not arguing for my choice, but, again, arguing for 
consideration of what appears to have been chosen, because of downstream 
consequences.

> If that's what we want, then there is absolutely no reason whatsoever to 
> continue with this work. Let's leave WHOIS in place.  There is no reason 
> for us to invent a new way to express exactly the same limitations.

Are you saying that only reason to move to rest is to be able to limit 
what people can see in whois data? If that is true, then you are right,
there is no point to continue with the work. I was under the delusion 
that there other reasons to improve whois.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Jun 2012 15:35:05 -0400

On Tue, Jun 12, 2012 at 02:51:53PM -0400, Bob Bruen wrote:
> 
> That is a policy decision. By adding capabilities to anything you
> create its potential use.

You are equivocating on the word "policy" here.  Of course it is true
that technology shapes the world.  But the Working Group has already
been chartered, and it was chartered on the basis of a number of
claims about the things we were aiming to do.  The goal as I
understood it was to support various potential uses -- "policies" --
in a new protocol.

The claims included the following (from the charter):

  The WHOIS protocol does not offer any differential service; it
  cannot differentiate among clients to offer different subsets of
  information or to allow different access rates to it.

[…]

    and may use
  standard features of HTTP to support differential service levels
  to different classes of user.

I will object, very strongly, if this WG produces things that do not
possibly provide such differentiation.  I leave to the chairs the
determination of whether further discussion of this question is
on-topic for the list, but I don't have more to say on the topic.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Don Blumenthal <[email-masked]>
Date: Tue, 12 Jun 2012 15:50:23 -0400

Ok. Time for somebody else to step in here.

First, for reasons that have been explored already, the suggestion that
WEIRDS wouldn't be making a policy decision by excluding differential
services capabilities is nonsense. In fact, the statement that the
capabilities will be used if feasible under a new protocol supports that
statement. You're asking WEIRDS to prevent the community from implementing
a capability that it wants based on your view of the concept, not on
whether a protocol can offer the ability.

To address another topic, EU privacy issues already exist under the
current protocol and are handled on an as applicable basis. Restful or
another other new approach will continue to afford that ability, and it's
not within the WEIRDS purview to structure our work based on laws that may
or may not apply in any given situation.

Don

On 6/12/12 2:51 PM, "Bob Bruen" <[email-masked]> wrote:

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

---

From: "Smith, Bill" <[email-masked]>
Date: Tue, 12 Jun 2012 20:26:58 +0000

*strongly agree*

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 13 Jun 2012 12:01:29 +1000

On 13/06/2012, at 4:51 AM, Bob Bruen wrote:

> That is a policy decision. By adding capabilities to anything you create its potential use. By deciding not to add, you are denying its use. Either way, it's a policy decision at an early stage and it should be considered carefully. This particular capability is chosen and another is not. Why pick one and not another?

To pick up on this question - this particular capability is chosen because it is an expressed need of subjects, consumers, operators, and regulators of Whois services.  See SAC 051, or the now ancient ICANN WHOIS Service Requirements document, or the perhaps less applicable but still informative RFC 3707 CRISP requirements work.

This requirement is in draft-kucherawy-weirds-requirements, section 3.2, if you wanted to address the reasoning given there or propose new text to replace that section with a requirement for no differentiation of service.

  Byron
[speaking for myself]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Jun 2012 23:14:32 -0700

> on-topic for the list, but I don't have more to say on the topic.
Differential service was indeed identified as a desirable thing by both
sides (names and numbers) during the chartering process.  I concur with
Andrew's position that enabling policy is not identical to creating or
enforcing policy.  If we produce something that is capable of both
class-of-service mode and port-43-clone mode, I'd say we've done the right
thing.

Perhaps to allay some of Bob's concerns, you might actually find that you
benefit from some kinds of differential service.  A spam filtering agent
(just ti pick a wild example) might be delighted to give up access to
complete registered objects, accepting only a few key fields, in exchange
for a far higher query limit.  That sort of tradeoff isn't possible without
a protocol that enables some kind of differential service.

Perhaps most importantly, however: Andrew's correct in pointing out that we
chartered to include that in our output, and so debating that point is
indeed off-topic unless someone wants to propose a charter change already.

-MSK, as co-chair