Re: Poll text call: final text by 28 September

Hi Aleecia,

I disagree and object to moving forward on this poll without a 
definition. It's a pig in a poke, and putting the cart before the horse 
:) I'd advise the group against moving ahead with decisions that have 
unmet dependencies on such core definitions as unlinkable. There remains 
quite a distance, I believe, between the various views on this topic, so 
it would be wise to resolve that before making other decisions that 
depend on it.

As to reopening issues based on new information, I think we have yet to 
do that for any issue, so I am not clear, actually, what constitutes the 
kind of "new information" that would reopen an issue. Therefore, I fear 
an issue like this may be closed and then not revisited, and 
implementers would then be directed just to adapt.

-David

On 9/30/12 2:00 AM, Aleecia M. McDonald wrote:
> Hi David,
>
> Thanks for your thoughts. I think we are ok here. We do have some discussions yet to get through on details of unidentifiable data, but we have had agreement on the overall direction for quite some time. I do not foresee any outcome on how data is rendered unidentifiable that would have a serious difference in how we treat log files.
>
> There are some sets of issues with serious dependency chains. This is not one of those cases. There is no reason I can see to stall on this one.
>
> If I am wrong and we somehow wind up with an unidentifiable procedure that takes months to implement then that would, of course, be new information to the group that would support re-opening the log file decision.
>
> 	Aleecia
>
> On Sep 28, 2012, at 3:12 PM, David Wainberg <david@networkadvertising.org> wrote:
>
>> Aleecia,
>>
>> In reviewing this to provide feedback, it occurs to me that it relies on the definition of unlinkable, which is still very much up for debate. How can companies weigh in on these options without understanding what the requirements actually are? We should postpone this poll until we define unlinkable so that companies can give realistic feedback regarding the time and effort needed to meet the requirements.
>>
>> Thanks,
>>
>> David
>>
>>
>> On 9/25/12 6:20 PM, Aleecia M. McDonald wrote:
>>>  From the call on 12 September, we discussed topics where we have increasing clarity on options for permitted uses. I want to make sure we have the text right to reflect our options prior to doing a decision process with a poll calling for objections, which is responsive to Ian's feedback. We also want to move quickly, as Roy suggests.
>>>
>>> Please propose specific alternative text if you believe that the two texts given below do not reflect the options before us by Friday, 28 September. We will briefly review these texts on the call tomorrow, just to make sure no one misses anything, and here we are on the mailing list, for those who cannot make the call.
>>>
>>> 	Aleecia
>>>
>>> -----
>>> Log files: issue-134
>>> ----
>>>
>>> This normative text fits into the section on Third Party Compliance, subsection 6.1.1.1, Short Term Collection and Use, <http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#short-term>. We will also want non-normative text, and have some suggested, but that will be clearer once we have the normative text settled. (Options for definitions of unlinkable data are in section 3.6, Unlinkable Data, <http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#def-unlinkable>.)
>>>
>>> Option 1:
>>> 	Operators MAY retain data related to a communication in a third-party context for up to 6 weeks. During this time, operators may render data unlinkable (as described above) or perform processing of the data for any of the other permitted uses.
>>>
>>> Option 2:
>>> 	Operators MAY retain data related to a communication in a third-party context. They MUST provide public transparency of their data retention period, which MUST have a specific time period (e.g. not infinite or indefinite.) During this time, operators may render data unlinkable (as described above) or perform processing of the data for any of the other permitted uses.
>>>
>>>
>>>
>>

Received on Tuesday, 2 October 2012 21:13:33 UTC