Subject: [decade] DECADE Charter

From: "Paul Jessop" <[email-masked]>
Date: Wed, 14 Apr 2010 11:19:18 +0100

DECADE Charter
==============

I am the Chief Technology Adviser to the Recording Industry Association of America and have been asked to convey some thoughts to IETF on the DECADE charter. I am sorry we could not do this before the recent IETF meeting.

We are very willing to discuss these comments and their implications with IETF participants, either individually or collectively.

We are dismayed to find that the Charter explicitly makes all issues of rights protection out of scope:

==============================================================================
- Implementation of policies regarding copyright-protected or illegal content.
  For example, one possibility is that that an in-network storage system may
  have system-wide ingress and egress filters to implement policies related to
  copyrighted and illegal content.  This is outside the scope of this working
  group.
==============================================================================

We are very keen to see legal applications of P2P technologies flourish but we are quite sure that all IETF participants are well aware of the consequences of their widespread abuse. We suggest that IETF needs to factor the societal consequences of its actions into its choice of subject areas for standardization and the way in which this is done. Though we note that there are some non-infringing uses of P2P technology, the vast majority of content carried over P2P networks is infringing. IETF participants will doubtless be familiar with the recent study of files available over a particular tracker-less BitTorrent system which showed that less than 1% of the files investigated could plausibly be regarded as non-infringing.

We suggest the DECADE work needs particular scrutiny in this respect because caching systems can have the effect of frustrating legal steps taken to removing infringing content from availability. Content which is taken down at its source by proper legal steps can remain available indefinitely in caches.

We have no desire to tell IETF how to specify technology: its participants have far greater skills that we do in this area. We do however have one high level proposal and one specific suggestion.

1. Implementation of Policy
===========================

We believe that the above scope restriction is problematic as drafted, because it implies that IETF specification are above the law. While we wholeheartedly agree that IETF should not set policy, it is clear that it needs to respond to policy. We are recognize that policy varies from jurisdiction to jurisdiction but believe that the general frameworks of copyright law set out in international treaties make it straightforward to enable this response.

We suggest that this paragraph is replaced by:

- Specification of policies regarding copyright-protected or illegal content.
  For example, a decision to impose content filtering is outside the scope of
  this working group.

2. Content removal interface
============================

We note the proposed focus on the protocol between the in-network storage and P2P applications. We suggest that a further interface in necessary: that between the in-network storage and content owners (and their representatives). While the primary interface may allow a certain amount of discovery, it does not allow the removal of infringing content and this needs to be enabled, along with certain safeguards against abuse.

We look forward to discussing these important issues.

Best regards,

Paul Jessop
Chief Technology Adviser,
Recording Industry Association of America

Paul Jessop                  county analytics
---------------------------------------------
rights - technology - markets - music - media
---------------------------------------------
[email-masked]      +44 7850 685378

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 14 Apr 2010 09:45:52 -0400

(Not speaking as a co-chair, and not speaking on behalf of my employer)
 
>1. Implementation of Policy
 
I am sympathetic with the suggestion to change 'Implementation of policies regarding copyright-protected or illegal content' to 'Specification of policies regarding copyright-protected or illegal content'. That is because the work product of the IETF is specifications, not implementations.
 
Also consider the following existing requirement in the current draft: http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2 <http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2> .
 
>2. Content removal interface
 
I don't believe the IETF community has the right skill set to specify a content removal interface between the in-network storage providers and content owners (and their representatives), keeping in mind various regulations regarding notifications, counter-notices, etc.
 
However, other groups do have that expertise, and there is an existing specification of note: <http://www.movielabs.com/ACNS/ <http://www.movielabs.com/ACNS/> >. This specification appears to support notification of content available via "HTTP" and "FTP", and should cover the protocols (FTP, WebDAV and/or HTTP) under consideration by DECADE. Also note that DECADE is very similar to a "Cyberlocker", which appears to be in scope for ACNS 2.0.
 
-- Rich

________________________________

From: Paul Jessop [mailto:[email-masked]]
Sent: Wed 4/14/2010 6:19 AM
To: [email-masked]
Cc: [email-masked]; IESG Secretary; Song Haibin; Woundy, Richard
Subject: DECADE Charter

DECADE Charter
==============

Best regards,

Paul Jessop

---

From: Richard Alimi <[email-masked]>
Date: Wed, 14 Apr 2010 09:54:49 -0400

Hi Paul,

Thank you very much for your comments on the charter.  Please allow me
to clarify one point to add to Rich Woundy's comments.  We certainly
realize that a storage provider must have the ability to handle cases
when certain content is identified as illegal or copyright-protected.
In particular, please see the current draft of the requirements
document:
  http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2

This requirement allows a storage provider to handle the situation
where certain content is deemed (by some means outside of our scope)
to not meet certain filtering criteria (the specification of which is
outside of our scope).  From the protocol perspective, we simply want
to make sure that an application has the information it needs to
handle this case appropriately (e.g., deal with the fact that some
data may not currently be available).

Thanks,
--
Richard Alimi
Department of Computer Science
Yale University

On Wed, Apr 14, 2010 at 6:19 AM, Paul Jessop <[email-masked]> wrote:
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade
>

---

From: "Paul Jessop" <[email-masked]>
Date: Wed, 14 Apr 2010 15:13:06 +0100

Rich,

Thanks on the first point.

On the second, I had seen the requirement you mention but this deals with the consequences of blocking, not the process that delivers it.

I wonder if your reference to the "various regulations regarding notifications, counter-notices, etc" risks confusing policy and engineering. Assuming that the operator of a DECADE service trusts a particular rights owner or their agent, then they might receive a certification allowing them to block problematic content in a cache. I'm not saying what policy, political or commercial considerations lead to that point but it happens in certain contexts today and standardizing it should reduce everyone's costs in implementing it.

A similar interface could be used by (say) child protection agencies - who would presumably have some form of MOU saying they would only block child-porn related material. If the operator trusted them to do so, then the interface would be useful to both parties.

I'd note (at the risk of bumping up against the policy boundary) that blocking something in a cache has none of the sensitivities of taking it down at the source, because the source (provided it has not itself been subject to takedown) is still available. If it goes beyond that we're talking about an archive rather than a cache.

I'm somewhat familiar with the ACNS specification but had considered it to be working at a rather higher level than I was proposing here. If it provides a basis to work from, it might save a lot of effort and time.

Paul

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]] 
Sent: 14 April 2010 14:46
To: Paul Jessop; [email-masked]
Cc: [email-masked]; IESG Secretary; Song Haibin; Woundy, Richard
Subject: RE: DECADE Charter

 

 

-- Rich

DECADE Charter
==============

Best regards,

Paul Jessop

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 14 Apr 2010 11:02:51 -0400

>I wonder if your reference to the "various regulations regarding notifications, counter-notices, etc" risks confusing policy and engineering. Assuming that the operator of a DECADE service trusts a…

Two reactions. First, I think the ACNS specification already covers the case of a "rights owner / agent" notifying a service provider about copyright infringement, and it performs this task for multiple technologies, e.g. P2P, cyberlockers, linking services, etc.
 
Second, there are numerous legal and policy considerations with respect to how the service provider ought to react to such a notification. Maybe content is immediately deleted (as in the case you suggest), or is immediately quarantined with user notification, or is quarantined after 24 hours if the user doesn't respond, etc. Maybe the ISP needs human validation of the notification, or must wait for a legal supoena. That's why I think the notification would be sent to a 'notification handling service' rather than a 'DECADE service'. The 'notification handling service' would send updates to the 'DECADE service' according to policy.
 
>I'd note (at the risk of bumping up against the policy boundary) that blocking something in a cache has none of the sensitivities of taking it down at the source, because the source (provided it has…
 
In a P2P context, the content in DECADE storage could be the original copy, or could be a duplicate copy. The DECADE service provider might not know.
 
>I'm somewhat familiar with the ACNS specification but had considered it to be working at a rather higher level than I was proposing here. If it provides a basis to work from, it might save a lot of…

I would suggest taking a look. Clearly *some* folks have implemented it, e.g. http://forums.afterdawn.com/t.cfm/f-18/nasty_email_fox_copyright-844134/ <http://forums.afterdawn.com/t.cfm/f-18/nasty_email_fox_copyright-844134/>  (scroll to bottom of posting).
 
-- Rich

From: Paul Jessop [mailto:[email-masked]]
Sent: Wed 4/14/2010 10:13 AM
To: Woundy, Richard; [email-masked]
Cc: [email-masked]; IESG Secretary; Song Haibin
Subject: RE: DECADE Charter

Rich,

Paul

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: 14 April 2010 14:46
To: Paul Jessop; [email-masked]
Cc: [email-masked]; IESG Secretary; Song Haibin; Woundy, Richard
Subject: RE: DECADE Charter

However, other groups do have that expertise, and there is an existing specification of note: <http://www.movielabs.com/ACNS/ <http://www.movielabs.com/ACNS/%20%3Chttp://www.movielabs.com/ACNS/> > >. This specification appears to support notification of content available via "HTTP" and "FTP", and should cover the protocols (FTP, WebDAV and/or HTTP) under consideration by DECADE. Also note that DECADE is very similar to a "Cyberlocker", which appears to be in scope for ACNS 2.0.

-- Rich

DECADE Charter
==============

Best regards,

Paul Jessop

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 14 Apr 2010 11:14:38 -0400

FYI -- let's drop the IESG Secretary from this thread. Each email to
them generates trouble tickets, which must be driving them crazy. :(

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Woundy, Richard
Sent: Wednesday, April 14, 2010 11:03 AM
To: Paul Jessop; [email-masked]
Cc: [email-masked]; IESG Secretary
Subject: Re: [decade] DECADE Charter

>I wonder if your reference to the "various regulations regarding
notifications, counter-notices, etc" risks confusing policy and
engineering. Assuming that the operator of a DECADE service trusts a
particular rights owner or their agent, then they might receive a
certification allowing them to block problematic content in a cache. I'm
not saying what policy, political or commercial considerations lead to
that point but it happens in certain contexts today and standardizing it
should reduce everyone's costs in implementing it.

Two reactions. First, I think the ACNS specification already covers the
case of a "rights owner / agent" notifying a service provider about
copyright infringement, and it performs this task for multiple
technologies, e.g. P2P, cyberlockers, linking services, etc.
 
Second, there are numerous legal and policy considerations with respect
to how the service provider ought to react to such a notification. Maybe
content is immediately deleted (as in the case you suggest), or is
immediately quarantined with user notification, or is quarantined after
24 hours if the user doesn't respond, etc. Maybe the ISP needs human
validation of the notification, or must wait for a legal supoena. That's
why I think the notification would be sent to a 'notification handling
service' rather than a 'DECADE service'. The 'notification handling
service' would send updates to the 'DECADE service' according to policy.
 
>I'd note (at the risk of bumping up against the policy boundary) that
blocking something in a cache has none of the sensitivities of taking it
down at the source, because the source (provided it has not itself been
subject to takedown) is still available. If it goes beyond that we're
talking about an archive rather than a cache.
 
In a P2P context, the content in DECADE storage could be the original
copy, or could be a duplicate copy. The DECADE service provider might
not know.
 
>I'm somewhat familiar with the ACNS specification but had considered it
to be working at a rather higher level than I was proposing here. If it
provides a basis to work from, it might save a lot of effort and time.

I would suggest taking a look. Clearly *some* folks have implemented it,
e.g.
http://forums.afterdawn.com/t.cfm/f-18/nasty_email_fox_copyright-844134/
<http://forums.afterdawn.com/t.cfm/f-18/nasty_email_fox_copyright-844134
/>  (scroll to bottom of posting).
 
-- Rich

Rich,

On the second, I had seen the requirement you mention but this deals
with the consequences of blocking, not the process that delivers it.

I wonder if your reference to the "various regulations regarding
notifications, counter-notices, etc" risks confusing policy and
engineering. Assuming that the operator of a DECADE service trusts a
particular rights owner or their agent, then they might receive a
certification allowing them to block problematic content in a cache. I'm
not saying what policy, political or commercial considerations lead to
that point but it happens in certain contexts today and standardizing it
should reduce everyone's costs in implementing it.

A similar interface could be used by (say) child protection agencies -
who would presumably have some form of MOU saying they would only block
child-porn related material. If the operator trusted them to do so, then
the interface would be useful to both parties.

I'd note (at the risk of bumping up against the policy boundary) that
blocking something in a cache has none of the sensitivities of taking it
down at the source, because the source (provided it has not itself been
subject to takedown) is still available. If it goes beyond that we're
talking about an archive rather than a cache.

I'm somewhat familiar with the ACNS specification but had considered it
to be working at a rather higher level than I was proposing here. If it
provides a basis to work from, it might save a lot of effort and time.

Paul

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: 14 April 2010 14:46
To: Paul Jessop; [email-masked]
Cc: [email-masked]; IESG Secretary; Song Haibin; Woundy, Richard
Subject: RE: DECADE Charter

>1. Implementation of Policy

I am sympathetic with the suggestion to change 'Implementation of
policies regarding copyright-protected or illegal content' to
'Specification of policies regarding copyright-protected or illegal
content'. That is because the work product of the IETF is
specifications, not implementations.

Also consider the following existing requirement in the current draft:
http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2
<http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2> .

>2. Content removal interface

I don't believe the IETF community has the right skill set to specify a
content removal interface between the in-network storage providers and
content owners (and their representatives), keeping in mind various
regulations regarding notifications, counter-notices, etc.

However, other groups do have that expertise, and there is an existing
specification of note: <http://www.movielabs.com/ACNS/
<http://www.movielabs.com/ACNS/%20%3Chttp://www.movielabs.com/ACNS/> >
>. This specification appears to support notification of content
available via "HTTP" and "FTP", and should cover the protocols (FTP,
WebDAV and/or HTTP) under consideration by DECADE. Also note that DECADE
is very similar to a "Cyberlocker", which appears to be in scope for
ACNS 2.0.

-- Rich

DECADE Charter
==============

I am the Chief Technology Adviser to the Recording Industry Association
of America and have been asked to convey some thoughts to IETF on the
DECADE charter. I am sorry we could not do this before the recent IETF
meeting.

We are very willing to discuss these comments and their implications
with IETF participants, either individually or collectively.

We are dismayed to find that the Charter explicitly makes all issues of
rights protection out of scope:

========================================================================
======
- Implementation of policies regarding copyright-protected or illegal
content.
  For example, one possibility is that that an in-network storage system
may
  have system-wide ingress and egress filters to implement policies
related to
  copyrighted and illegal content.  This is outside the scope of this
working
  group.
========================================================================
======

We are very keen to see legal applications of P2P technologies flourish
but we are quite sure that all IETF participants are well aware of the
consequences of their widespread abuse. We suggest that IETF needs to
factor the societal consequences of its actions into its choice of
subject areas for standardization and the way in which this is done.
Though we note that there are some non-infringing uses of P2P
technology, the vast majority of content carried over P2P networks is
infringing. IETF participants will doubtless be familiar with the recent
study of files available over a particular tracker-less BitTorrent
system which showed that less than 1% of the files investigated could
plausibly be regarded as non-infringing.

We suggest the DECADE work needs particular scrutiny in this respect
because caching systems can have the effect of frustrating legal steps
taken to removing infringing content from availability. Content which is
taken down at its source by proper legal steps can remain available
indefinitely in caches.

We have no desire to tell IETF how to specify technology: its
participants have far greater skills that we do in this area. We do
however have one high level proposal and one specific suggestion.

We believe that the above scope restriction is problematic as drafted,
because it implies that IETF specification are above the law. While we
wholeheartedly agree that IETF should not set policy, it is clear that
it needs to respond to policy. We are recognize that policy varies from
jurisdiction to jurisdiction but believe that the general frameworks of
copyright law set out in international treaties make it straightforward
to enable this response.

- Specification of policies regarding copyright-protected or illegal
content.
  For example, a decision to impose content filtering is outside the
scope of
  this working group.

We note the proposed focus on the protocol between the in-network
storage and P2P applications. We suggest that a further interface in
necessary: that between the in-network storage and content owners (and
their representatives). While the primary interface may allow a certain
amount of discovery, it does not allow the removal of infringing content
and this needs to be enabled, along with certain safeguards against
abuse.

Best regards,

Paul Jessop

---

From: Song Haibin <[email-masked]>
Date: Thu, 15 Apr 2010 10:17:39 +0800

I fully agree with what Rich said.

> >> scope of  this working group.
> >>

I agree with changing "implementation" to "specification". And further, I
would like to change the example a bit to "... For example, a decision to
impose or how to process content filtering is outside the scope of this
working group." That is because we do not have expertise in doing content
filtering and it will broaden the scope a lot.

BR,
Haibin

> Sent: Wednesday, April 14, 2010 11:03 PM
> >I wonder if your reference to the "various regulations 
> regarding notifications, counter-notices, etc" risks 
> confusing policy and engineering. Assuming that the operator 
> of a DECADE service trusts a particular rights owner or their 
> agent, then they might receive a certification allowing them 
> to block problematic content in a cache. I'm not saying what 
> policy, political or commercial considerations lead to that 
> point but it happens in certain contexts today and 
> standardizing it should reduce everyone's costs in implementing it.
> 
> Two reactions. First, I think the ACNS specification already 
> covers the case of a "rights owner / agent" notifying a 
> service provider about copyright infringement, and it 
> performs this task for multiple technologies, e.g. P2P, 
> cyberlockers, linking services, etc.
>  
> Second, there are numerous legal and policy considerations 
> with respect to how the service provider ought to react to 
> such a notification. Maybe content is immediately deleted (as 
> in the case you suggest), or is immediately quarantined with 
> user notification, or is quarantined after 24 hours if the 
> user doesn't respond, etc. Maybe the ISP needs human 
> validation of the notification, or must wait for a legal 
> supoena. That's why I think the notification would be sent to 
> a 'notification handling service' rather than a 'DECADE 
> service'. The 'notification handling service' would send 
> updates to the 'DECADE service' according to policy.
>  
> >I'd note (at the risk of bumping up against the policy 
> boundary) that blocking something in a cache has none of the 
> sensitivities of taking it down at the source, because the 
> source (provided it has not itself been subject to takedown) 
> is still available. If it goes beyond that we're talking 
> about an archive rather than a cache.
>  
> In a P2P context, the content in DECADE storage could be the 
> original copy, or could be a duplicate copy. The DECADE 
> service provider might not know.
>  
> >I'm somewhat familiar with the ACNS specification but had 
> considered it to be working at a rather higher level than I 
> was proposing here. If it provides a basis to work from, it 
> might save a lot of effort and time.
> 
> I would suggest taking a look. Clearly *some* folks have 
> implemented it, e.g. 
> <http://forums.afterdawn.com/t.cfm/f-18/nasty_email_fox_copyri
> ght-844134/>  (scroll to bottom of posting).
>  
> -- Rich
> 
> On the second, I had seen the requirement you mention but 
> this deals with the consequences of blocking, not the process 
> that delivers it.
> 
> I wonder if your reference to the "various regulations 
> regarding notifications, counter-notices, etc" risks 
> confusing policy and engineering. Assuming that the operator 
> of a DECADE service trusts a particular rights owner or their 
> agent, then they might receive a certification allowing them 
> to block problematic content in a cache. I'm not saying what 
> policy, political or commercial considerations lead to that 
> point but it happens in certain contexts today and 
> standardizing it should reduce everyone's costs in implementing it.
> 
> A similar interface could be used by (say) child protection 
> agencies - who would presumably have some form of MOU saying 
> they would only block child-porn related material. If the 
> operator trusted them to do so, then the interface would be 
> useful to both parties.
> 
> I'd note (at the risk of bumping up against the policy 
> boundary) that blocking something in a cache has none of the 
> sensitivities of taking it down at the source, because the 
> source (provided it has not itself been subject to takedown) 
> is still available. If it goes beyond that we're talking 
> about an archive rather than a cache.
> 
> I'm somewhat familiar with the ACNS specification but had 
> considered it to be working at a rather higher level than I 
> was proposing here. If it provides a basis to work from, it 
> might save a lot of effort and time.
> 
> Paul
> 
> 
> 
> I am sympathetic with the suggestion to change 
> 'Implementation of policies regarding copyright-protected or 
> illegal content' to 'Specification of policies regarding 
> copyright-protected or illegal content'. That is because the 
> work product of the IETF is specifications, not implementations.
> 
> I don't believe the IETF community has the right skill set to 
> specify a content removal interface between the in-network 
> storage providers and content owners (and their 
> representatives), keeping in mind various regulations 
> regarding notifications, counter-notices, etc.
> 
> However, other groups do have that expertise, and there is an 
> existing specification of note: 
> <http://www.movielabs.com/ACNS/ 
> <http://www.movielabs.com/ACNS/%20%3Chttp://www.movielabs.com/
> ACNS/> > >. This specification appears to support 
> notification of content available via "HTTP" and "FTP", and 
> should cover the protocols (FTP, WebDAV and/or HTTP) under 
> consideration by DECADE. Also note that DECADE is very 
> similar to a "Cyberlocker", which appears to be in scope for ACNS 2.0.
> 
> -- Rich
> 
> I am the Chief Technology Adviser to the Recording Industry 
> Association of America and have been asked to convey some 
> thoughts to IETF on the DECADE charter. I am sorry we could 
> not do this before the recent IETF meeting.
> 
> We are very willing to discuss these comments and their 
> implications with IETF participants, either individually or 
> collectively.
> 
> We are dismayed to find that the Charter explicitly makes all 
> issues of rights protection out of scope:
> 
> We are very keen to see legal applications of P2P 
> technologies flourish but we are quite sure that all IETF 
> participants are well aware of the consequences of their 
> widespread abuse. We suggest that IETF needs to factor the 
> societal consequences of its actions into its choice of 
> subject areas for standardization and the way in which this 
> is done. Though we note that there are some non-infringing 
> uses of P2P technology, the vast majority of content carried 
> over P2P networks is infringing. IETF participants will 
> doubtless be familiar with the recent study of files 
> available over a particular tracker-less BitTorrent system 
> which showed that less than 1% of the files investigated 
> could plausibly be regarded as non-infringing.
> 
> We suggest the DECADE work needs particular scrutiny in this 
> respect because caching systems can have the effect of 
> frustrating legal steps taken to removing infringing content 
> from availability. Content which is taken down at its source 
> by proper legal steps can remain available indefinitely in caches.
> 
> participants have far greater skills that we do in this area. 
> We do however have one high level proposal and one specific 
> suggestion.
> 
> We believe that the above scope restriction is problematic as 
> drafted, because it implies that IETF specification are above 
> the law. While we wholeheartedly agree that IETF should not 
> set policy, it is clear that it needs to respond to policy. 
> We are recognize that policy varies from jurisdiction to 
> jurisdiction but believe that the general frameworks of 
> copyright law set out in international treaties make it 
> straightforward to enable this response.
> 
> We note the proposed focus on the protocol between the 
> in-network storage and P2P applications. We suggest that a 
> further interface in necessary: that between the in-network 
> storage and content owners (and their representatives). While 
> the primary interface may allow a certain amount of 
> discovery, it does not allow the removal of infringing 
> content and this needs to be enabled, along with certain 
> safeguards against abuse.
> 
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 15 Apr 2010 07:47:55 +0200

Hi

Suppose that some provider of illegal content decides to use DECADE servers for their content. As a provider of this content I would encrypt the content and distribute the keys in a "members only" club. 

The chance for outsiders to penetrate this depends on content and whether money or (possibly perverse) ideology is the main driver for the providers. 

If money is the main driver then I would believe that it is fairly easy for law enforcement to punch a hole in the balloon (just buy membership). I would believe that illegal distribution of movies and music fall into this cathegory.

If (perverse) idelogy is the main driver then I believe things get more tricky, and I believe that e.g child pornography falls into this cathegory. On the other hand , if/when these groups are penetrated I would say that logs from DECADE servers are very helpful for the further criminal investigations.

I believe that these are serious issues and deserves full attention

Nevertheless I find it a bit hard at this stage to see in what way protocols devised in the IETF can be helpful, to me it seems more like agreements between DECADE server hosts and law enforcement is the best cure. Also I would say that the problem is already here, DECADE does not make the problem worse IMHO.

/Ingemar

> Sent: den 14 april 2010 17:15
> Cc: [email-masked]
> FYI -- let's drop the IESG Secretary from this thread. Each 
> email to them generates trouble tickets, which must be 
> driving them crazy. :(
> 
> -- Rich
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Woundy, Richard
> notifications, counter-notices, etc" risks confusing policy 
> and engineering. Assuming that the operator of a DECADE 
> service trusts a particular rights owner or their agent, then 
> they might receive a certification allowing them to block 
> problematic content in a cache. I'm not saying what policy, 
> political or commercial considerations lead to that point but 
> it happens in certain contexts today and standardizing it 
> user notification, or is quarantined after
> 24 hours if the user doesn't respond, etc. Maybe the ISP 
> needs human validation of the notification, or must wait for 
> a legal supoena. That's why I think the notification would be 
> sent to a 'notification handling service' rather than a 
> 'DECADE service'. The 'notification handling service' would 
> send updates to the 'DECADE service' according to policy.
>  
> blocking something in a cache has none of the sensitivities 
> of taking it down at the source, because the source (provided 
> it has not itself been subject to takedown) is still 
> available. If it goes beyond that we're talking about an 
> archive rather than a cache.
>  
> considered it
> to be working at a rather higher level than I was proposing 
> here. If it provides a basis to work from, it might save a 
> lot of effort and time.
> 
> available via "HTTP" and "FTP", and should cover the 
> protocols (FTP, WebDAV and/or HTTP) under consideration by 
> DECADE. Also note that DECADE is very similar to a 
> "Cyberlocker", which appears to be in scope for ACNS 2.0.
> 
> -- Rich
> 
> technology, the vast majority of content carried over P2P 
> networks is infringing. IETF participants will doubtless be 
> familiar with the recent study of files available over a 
> particular tracker-less BitTorrent system which showed that 
> less than 1% of the files investigated could plausibly be 
> regarded as non-infringing.
> 
> further interface in
> necessary: that between the in-network storage and content 
> owners (and their representatives). While the primary 
> interface may allow a certain amount of discovery, it does 
> not allow the removal of infringing content and this needs to 
> be enabled, along with certain safeguards against abuse.
> 
>