Subject: [weirds] Setting the WEIRDS IETF 84 agenda

From: Olaf Kolkman <[email-masked]>
Date: Wed, 11 Jul 2012 22:11:29 +0200

Dear Colleagues,

We are preparing the agenda for the Vancouver meeting and invite requests for agenda slots. But first a few thoughts about the meeting and the current agenda.

== General agenda/meeting guidelines.

During this meeting and going forward we would like to stick to a few guidelines (I am using the word guidelines instead of principles; we do not intend to be rigid, only strict with a touch of pragmatism.):

* Agenda items should have associated goals that are actionable for the working group and working group participants; the request for an agenda item should state that goal and, if possible an expected outcome.

* Working group participants are expected to have an Internet connection and come prepared.

In other words, if you are asking for agenda time then please try to define what you want to get out of the working group; advice, a decision, etc. Also, try to think about what the working group participants need in order to drive that decision. It is useful to sketch an expected outcome, or describe the alternatives in advance, so participants can prepare.  The agenda should contain sufficient information so that participants can gather context in a few hours preparation time.

== First half of the first meeting.

During the first half of the first meeting we would like to try to get towards asking and answering ourselves a set of questions that will help us organize the work and give us some guidance in the future.

Below is a sketch of the story we want the meeting to tell. In order to start a discussion on list I will post separate mails with their own subject so that we can summarize discussion that occurred at the meeting. The final agenda will provide context through links to the archives.

The story begins with building a general understanding what support will mean in the context of the data model;  we want to make sure that the working group is in sync when we say that the protocol MUST support a certain object. There is a potential of talking past each other when we are not aligned and that would be impractical, to say the least. (See mail with Subject "Supporting Objects")

The second question at hand is service differentiation. Suppose an object contains elements that are sensitive and for which the service provider has different policies based on authentication (e.g. a CONTACT object has a telephone number as element, which according to a local policy Law Enforcement must have access to and the general public must not have access to). What is a good way to deal with this in a RESTful way? The question is an engineering question, answering the general approach early on will help us when we are designing the details. (See mail with Subject "REST-pect-ful")

The third topic is trying to allow us to define a base-spec and define the general approach to version and extend it. Creating a base-specificiation with objects that MUST be supported (see first topic), which allows for extensions might be useful as it allows us to defer the definition of more contentious resources to a version 2 of the protocol. Supposing that we want to create extendibility, how do we go about it. (This hooks into a thread with Subject "extensibility in weirds" and a mail with subject "Category of Objects".)

Fourth, Objects... objects... objects. We need an approach to define supported resources. We have already dome some work on making an inventory of what is 'out there' (see Subject "Divide and Conquer"). We want to show the working group which data has been collected and walk away with a definition of the next step.

Fifth, mapping and mapping metadata. Where do clients know where to start their lookups? Is this a topic for the working group to consider and if so what is a good way. (See mails with Subject "Redirection in the RESTful WHOIS world").

== Agenda so far 

This is the agenda as it currently stands can be found at:
http://www.ietf.org/proceedings/84/agenda/agenda-84-weirds

-------

Please send your request for agenda items, possibly fitting within the above framework, with a short explanation of what is actionable and what is the goal of the agenda item to [email-masked].

--Olaf, co-chair

_______________________________________________________ 
Olaf Kolkman -- NLnet Labs
http://www.nlnetlabs.nl/

---

From: SM <[email-masked]>
Date: Thu, 12 Jul 2012 01:18:31 -0700

At 13:11 11-07-2012, Olaf Kolkman wrote:
>The second question at hand is service differentiation. Suppose an 
>object contains elements that are sensitive and for which the 
>service provider has different policies based on authentication 
>(e.g. a CONTACT object has a telephone number as element, which 
>according to a local policy Law Enforcement must have access to and 
>the general public must not have access to). What is a good way to 
>deal with this in a RESTful way? The

I am not suggesting this subject for IETF 84.  I stumbled across the 
following gem: A mobile phone number on its own is not classed as 
"personally identifying information" ( 
http://www.guardian.co.uk/technology/2012/jan/25/02-mobile-phone-users-privacy-breach-website 
) some time back.

Would an analysis of the information identified in the WEIRDS 
specification (e.g. CONTACT object) be required or can the rodent 
hole be avoided?  Note that the question is from an IETF perspective.

regards,
-sm

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 12 Jul 2012 10:57:50 +0200

On Jul 12, 2012, at 10:18 AM, SM wrote:

>> The second question at hand is service differentiation. Suppose an object contains elements that are sensitive and for which the service provider has different policies based on authentication (e.g. a CONTACT object has a telephone number as element, which according to a local policy Law Enforcement must have access to and the general public must not have access to). What is a good way to deal with this in a RESTful way? The
> 
> I am not suggesting this subject for IETF 84.  I stumbled across the following gem: A mobile phone number on its own is not classed as "personally identifying information" (http://www.guardian.co.uk/technology/2012/jan/25/02-mobile-phone-users-privacy-breach-website ) some time back.
> 
> Would an analysis of the information identified in the WEIRDS specification (e.g. CONTACT object) be required or can the rodent hole be avoided?  Note that the question is from an IETF perspective.

For now the question is how to deal with the situation where some elements of an object might be privacy sensitive. In other words, lets define the general mechanism first.

Later on, I am sure, we may see differences of opinions about what elements in objects might be interpreted as privacy sensitive. That is where we have to find a careful balance between the protocol enforcing policy and allowing policy to be enforced.

<wg-participant co-chair-hat=off opinion=personal>
If the protocol enforces an element in an object to be served in all cases then the protocol might not be deployable under certain policy regimes and we loose. Allowing for the policy tussle to be played out during deployment is probably a better model.
</wg-participant>

Being my optimistic self I think that there will be rough consensus on which elements are privacy sensitive and thus more likely subject to differential service: when it looks, smells and feels like privacy sensitive, it probably is. Trying to answer your question: I would like to postpone the analysis because it might happen more or less implicit during the process, and might be easier once we sort out how to engineer the differentiation.

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

Science Park 400, 1098 XH Amsterdam, The Netherlands