Subject: [decade] proposed charter

From: "David B Harrington" <[email-masked]>
Date: Sun, 18 Apr 2010 01:48:16 -0400

Hi,

<as an individual contributor>

Looking at the 3/26 proposed charter posted on 4-12, I have some
comments:

P2P networks are virtual networks overlaid onto physical networks, and
while the P2P storage
might be related to a specific P2P cache, that might be implemented on
a physical storage device owned by somebody other than the owner of
the P2P application. 

1) in the first paragraph, there are references to "the network" and
"inside networks".
The decade work will cross administrative boundaries. The charter
needs to be more specific about which network is being referenced
here.

2) in the 2nd paragraph, the statement "applications may be
better-equipped to decide ..."
Better equipped than whom? again, it is important to differentiate
between the virtual storage being used by a specific application, and
the physical storage that actually stores the data. 
I think the owner of the physical storage may be better-equipped to
make decisions about how the in-network storage is used than any
particular P2P application. The P2P application might have a better
understanding of application-specific issues, but multiple P2P
applications might be contending for the same physical storage. There
may be an application whose job is to coordinate multiple virtual
allocations of storage to different applications, and that coordinator
might be better-equipped to make decisions about the storage. 

3) I disagree with the assertion that both of these problems can be
effectively addressed by using an open, standard protocol to access
in-network storage. I do believe that having an open standard can help
to mitigate the issues, but I do not believe these problems can be
effectively addressed using one open, standard protocol. There are
many problems that are interrelated, and likely cross-domain, that
will require more than just a protocol to solve.
And many of the issues are layer 8 and above - economic, governmental,
regulatory, etc.

4) I recommend the WG consider documenting, and possibly addressing,
some of the cross-domain access control requirements.

5) The sentence starting "if new protocol development (and hence
rechartering)" seems to imply that protocol work can start before
rechartering, or that rechartering can be done before completion of
existing deliverables. That sounds like a slippery slope to me ...

6) "Implementation of policies" - we don't do implementation, we do
specifications. and generally, the ietf does not specify policies; it
specifies technologies. organizations that specify policies are
welcome to utilize our standardized technologies.

I would eliminate the second sentence in that bullet - the example of
what is out of scope.
Simply leave it that "specification of policies regarding
copyright-protected or illegal content" is out of scope. 

I think the justification for this being out of scope is very similar
to the reasons we don't specify policies (or develop
explicit-technology features) for wiretapping (RFC 2804). We focus on
developing the best technologies. Wiretapping or copyright protection
or content legality requirements differ dramatically across
non-technological domains. Trying to build in features to mitigate
this unclear set of (layer 8+) requirements would dramatically
complicate technical 
designs. This should be out of scope for an organization focused on
engineering standards, not policy.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Richard Alimi <[email-masked]>
Date: Sun, 18 Apr 2010 14:14:34 -0400

Hi David,

Thank you very much for your comments. Please see inline:

> a physical storage device owned by somebody other than the owner of

Yes, this is certainly a deployment possibility.

> needs to be more specific about which network is being referenced

The intention here was to refer to "the network" between hosts
running P2P applications.  You're correct that this definition of "the
network" can typically include multiple administrative domains.  There
is discussion later in the charter indicating that it can indeed cross
administrative domains (as related to access control);  This can be
clarified here too if it is unclear to others as well.

> might be better-equipped to make decisions about the storage.

I certainly agree that the owner of the physical storage does have a
say in how resources can be divided amongst users.  As we mentioned
during the BoF, we are certainly _not_ trying to create some
(seemingly) limitless cloud storage or pool of resources that can be
used by P2P applications. We fully recognize that the parties
providing the storage will have their own considerations.

As part of a research project we were working on, we addressed this
issue using a hierarchy for resource allocation.  Please see slide 10
of these slides that were presented at the Bar BoF at IETF75:
 http://trac.tools.ietf.org/area/app/trac/raw-attachment/wiki/BarBofs/IETF75/P2PCaching/decade-ietf75-3-sailor.pdf
In this model, at the top level, the owner of the storage can define
policies for sharing bandwidth/storage across users.  Users may
further allocate those amongst applications, and applications may then
share resources (e.g., bandwidth) amongst peers.

This is of course not a final solution or the only solution, but we
certainly recognize the existence of the issues that you mentioned.

If it makes things clearer, I think it is fine to mention in the
charter that we recognize that storage providers can have their own
policies for how resources are shared and allocated amongst users.

> will require more than just a protocol to solve.

One immediate item that comes to mind here (and you have mentioned it
below) is access control that crosses administrative boundaries, which
we have explicitly called out in the charter and in one of the
requirements:
 http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-4.2

Do you have any other specific issues in mind?

If it makes it clearer, we could change "protocol" to be plural.  Note
that the charter does not restrict us to considering a single
"protocol" to solve all of the necessary problems.  In particular, the
description of the Architecture document indicates: "This document
will identify DECADE's relationship with existing IETF protocols.
Existing protocols will be used wherever possible and appropriate to
support DECADE's requirements."

> And many of the issues are layer 8 and above - economic, governmental,

Yes, there are certainly issues here, but the intent here is to scope
for the technical issues.  Perhaps the other thread regarding
copyrighted/illegal content is more suited for this particular
discussion?

> some of the cross-domain access control requirements.

I think this is addressed in response to (3) above.  Were you thinking
of other aspects of cross-domain access control that should be
documented beyond what is already mentioned?

> existing deliverables. That sounds like a slippery slope to me ...

We certainly did not mean to imply that protocol development can begin
before rechartering.  With regards to the Requirements and
Architecture deliverables, I personally feel that we should have them
stabilized (shown by WG consensus), but not published, before
rechartering.  It is certainly possible that details in the protocol
work will may require some minor updates to the text in the
Requirements or Architecture document.

> welcome to utilize our standardized technologies.

If a storage provider were to enabling some sort of policy, I believe
there are two steps towards achieving it:
(1) Providing the capabilities to specify the policy (e.g., a
filtering language)
(2) Specifying the policies to be applied

Item (2) is clearly out of scope for the WG since it is up to the
storage provider.

The word "implementation" in the charter text was meant to refer to
step (1) in the sense of allowing the storage provider to implement
policies, and not in the sense of writing code.  The intent was that
(1) is also out of scope, since it could be accomplished a separate
entity than the protocol between applications and the storage.

> copyright-protected or illegal content" is out of scope.

Leaving out the example is fine with me.

> engineering standards, not policy.

Agreed.

> [email-masked]

Thanks again for the comments!
--
Richard Alimi
Department of Computer Science
Yale University

---

From: Song Haibin <[email-masked]>
Date: Mon, 19 Apr 2010 16:01:59 +0800

Hi David,

I copied this thread to iesg mailing list, because I guess maybe other iesg
memebers would be interested. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Richard Alimi
> Sent: Monday, April 19, 2010 2:15 AM
> To: David B Harrington
> Cc: [email-masked]
> Subject: Re: [decade] proposed charter
> 
> Hi David,
> 
> > while the P2P storage might be related to a specific P2P 
> cache, that 
> > might be implemented on a physical storage device owned by somebody 
> > other than the owner of the P2P application.
> 
> The intention here was to refer to "the network" between 
> hosts running P2P applications.  You're correct that this 
> definition of "the network" can typically include multiple 
> administrative domains.  There is discussion later in the 
> charter indicating that it can indeed cross administrative 
> domains (as related to access control);  This can be 
> > Better equipped than whom? 

In this paragraph, we compare with existing P2P caches. The existing P2P
cache does not allow this kind of flexibility to integrate application
policies.

>>again, it is important to differentiate 

The in-network storage is considered as the logical entity in the network.
It is either virtual or physical. It can be clarified in the charter if
necessary.

> I certainly agree that the owner of the physical storage does 
> have a say in how resources can be divided amongst users.  As 
> we mentioned during the BoF, we are certainly _not_ trying to 
> create some
> (seemingly) limitless cloud storage or pool of resources that 
> can be used by P2P applications. We fully recognize that the 
> parties providing the storage will have their own considerations.
> 
> As part of a research project we were working on, we 
> addressed this issue using a hierarchy for resource 
> allocation.  Please see slide 10 of these slides that were 
> presented at the Bar BoF at IETF75:
>  
> http://trac.tools.ietf.org/area/app/trac/raw-attachment/wiki/B
> arBofs/IETF75/P2PCaching/decade-ietf75-3-sailor.pdf
> In this model, at the top level, the owner of the storage can 
> define policies for sharing bandwidth/storage across users.  
> Users may further allocate those amongst applications, and 
> applications may then share resources (e.g., bandwidth) amongst peers.
> 
> This is of course not a final solution or the only solution, 
> but we certainly recognize the existence of the issues that 
> you mentioned.
> 
> If it makes things clearer, I think it is fine to mention in 
> the charter that we recognize that storage providers can have 
> their own policies for how resources are shared and allocated 
> amongst users.
> 
> >
> below) is access control that crosses administrative 
> boundaries, which we have explicitly called out in the 
> charter and in one of the
> requirements:
> If it makes it clearer, we could change "protocol" to be 
> plural.  Note that the charter does not restrict us to 
> considering a single "protocol" to solve all of the necessary 
> problems.  In particular, the description of the Architecture 
> document indicates: "This document will identify DECADE's 
> relationship with existing IETF protocols.
> Existing protocols will be used wherever possible and 
> appropriate to support DECADE's requirements."
> 
> Yes, there are certainly issues here, but the intent here is 
> to scope for the technical issues.  Perhaps the other thread 
> regarding copyrighted/illegal content is more suited for this 
> particular discussion?
> 
> I think this is addressed in response to (3) above.  Were you 
> thinking of other aspects of cross-domain access control that 
> should be documented beyond what is already mentioned?
> 
> >
> We certainly did not mean to imply that protocol development 
> can begin before rechartering.  With regards to the 
> Requirements and Architecture deliverables, I personally feel 
> that we should have them stabilized (shown by WG consensus), 
> but not published, before rechartering.  It is certainly 
> possible that details in the protocol work will may require 
> some minor updates to the text in the Requirements or 
> Architecture document.
> 
> If a storage provider were to enabling some sort of policy, I 
> believe there are two steps towards achieving it:
> Item (2) is clearly out of scope for the WG since it is up to 
> the storage provider.
> 
> The word "implementation" in the charter text was meant to 
> refer to step (1) in the sense of allowing the storage 
> provider to implement policies, and not in the sense of 
> writing code.  The intent was that
> (1) is also out of scope, since it could be accomplished a 
> separate entity than the protocol between applications and 
> the storage.
> 
> > complicate technical designs. This should be out of scope for an 
> > organization focused on engineering standards, not policy.
> 
> Agreed.
> 
> >
> > David Harrington
> > [email-masked]
> > [email-masked]
> > [email-masked]
> 
> 

BR,
Haibin