Re: Question to Chairs on Call-for-objection Process

Hi Chris, a couple of responses below.

On Feb 5, 2014, at 4:00 PM, Chris Mejia <chris.mejia@iab.net> wrote:

> Dear TPWG Chairs,
> 
> With respect to Issue-240 on defining the word "context" as it pertains to the definition of "tracking" in the TPE (but also related more broadly to the entire TPE drafting process, procedurally speaking), I'd like to formally request a procedural ordering of issues:
> We should FIRST vote/poll on the fundamental issue of whether the definition of the word "context" should be included (at all) in the TPE…. THEN;
> Following the issuance of a "decision" by the chairs on the 1st poll proposed above (of whether to include a definition of context in the TPE, or not), IF it is determined through that poll that we should have this definition in the TPE document, we THEN move to a call-for-objections poll on the actual definition of the word "context".
> My rationale for this request being, folks may give a different response to #2 depending on the outcome of #1. My request here, logically asks that the horse come before the cart, metaphorically speaking.  I hope this makes sense, procedurally?  I also believe this is how we should approach any potential porting of definitions (aka policy) into the TPE.

Under the current Call for Objections procedure, you are permitted to argue that while you prefer that a term remain undefined, certain of the proposed definitions are less objectionable than others.  As long as you substantiate each argument with reasoning, the Chairs can fairly evaluate the relative strength of the arguments against including any particular definition as well as against having any definition at all.

Requiring separate Call for Objection processes over (1) whether to define a term and/or change existing language and then (2) what that change should be would add needless bureaucratic red tape to this process and delay each decision at least a month, without any corresponding benefit.  In general, I'd prefer to resolve issues without using the Call for Objection process AT ALL, let alone twice per issue.

> 
> Finally, I'd like to point out that we have two conflicting "final"/closed decisions:  a) the decision to bifurcate the compliance document from the technology document and put their development on separate paths, and b) the defining of do-not-track (which is a ultimately compliance/policy element) now in the TPE working draft.  I believe this conflict needs to be discussed at an architectural level with the working group (not discussed issue by issue, as we are doing today in what feels like a 'Frankensteining' process) and reconciled accordingly.

We do not have conflicting closed decisions.  The TPE defines the meaning of the DNT signal as well as how to technically express that meaning.  On the other hand, the Compliance spec (or alternately, some other compliance policy) defines how a server must behave in order to honor that DNT request.  Defining terms within the TPE does not impose compliance requirements on anyone; you are free to honor, ignore, or otherwise disregard that signal in your own judgment or pursuant to the terms of whatever compliance rules you adopt (however, TPE does standardize a format for you to communicate back to the user whether and how you honor the signal).

Despite the bifurcation of the TPE and TCS, the group decided to define "tracking" as an expression of what the signal is intended to convey.  Otherwise, the signal becomes a tautology, effectively asking "don't do whatever it is you say you won't do to me."  The group decided to define tracking as the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. That definition and related ISSUE are now closed for discussion absent some new information for the group to consider.  However, it is an open question whether the term "context" within that definition should be defined more precisely.  (And, either way, any definition of context will not prescribe compliance obligations.)  In the Call for Objections that we'll announce later this week, working group members will be able to argue against the proposed definitions, as well as why we shouldn't include any definition at all.

> 
> Respectfully Submitted for Your Consideration,
> 
> Chris
> 
> Chris Mejia | Digital Supply Chain Solutions | Ad Technology Group | Interactive Advertising Bureau - IAB