Re: ACTION-372 service providers and debugging

By their very nature, most service providers collect data for
multiple parties via a centralized service.  The data is
only separated after the protocol stream is parsed, which is
fairly immediate.  Debugging will occur on both sides of that
separation process and is permitted by each controller as part
of the typical service contract.

....Roy

On Mar 18, 2013, at 10:32 PM, Jonathan Mayer wrote:

> I would be willing to consider a debugging exception (for both third parties and service providers), but only if:
> 
> 1) Data collection is not prospective.  In other words, the exception only applies if there's currently a bug getting worked out.  Industry participants have not provided technical evidence that historical linkable data would be essential for debugging unlinkable practices, and at any rate, I'm not comfortable with any provision that allows continuous linkable data collection.
> 
> 2) Data collection is necessary.  There are many ways of squishing a bug.  Collecting intrusive data must be a last resort.
> 
> I think Tom Lowenthal's language in ACTION-278 mostly does #1, not quite #2.  At any rate, we should probably have an ISSUE for tracking a debugging exception.
> 
> On Monday, March 18, 2013 at 3:04 PM, David Wainberg wrote:
> 
>> The issue is that service providers should not jeopardize service provider status by virtue of looking across siloed data to perform system debugging. I believe the current language for the debug permitted use already implicitly includes this, but that we can make it explicit in non-normative language.
>> 
>> Current permitted use:
>> 
>> 6.1.1.2.7 Debugging
>> 
>> Information may be collected, retained and used for identifying and repairing errors that impair existing intended functionality.
>> 
>> Non-normative addition:
>> 
>> This provision includes use of data by service providers from across multiple clients simultaneously for the limited purpose of system debugging. 
>