Subject: [decade] Updated DECADE Charter

From: Richard Alimi <[email-masked]>
Date: Fri, 22 Jan 2010 16:58:24 -0500

Hi All,

We have been working on a new charter with a refined scope and incorporating 
past discussion on the mailing list.  It would be wonderful to hear comments 
on the new proposed charter.

========================================================================

                   DECoupled Application Data Enroute

Description of Working Group:

Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file-
sharing applications, make up a large fraction of traffic in the Internet 
today. One way to reduce access network and/or cross-domain bandwidth usage by 
P2P applications is to introduce storage capabilities in the networks.  
Allowing P2P applications to store and retrieve data from inside networks can 
reduce traffic on the last-mile uplink, as well as backbone and transit links.

Existing P2P caches often implement the specific P2P application protocols to 
operate transparently or act as super peers to provide in-network storage. 
However, this approach poses challenges to both P2P cache vendors and P2P 
application developers. For P2P cache vendors, the challenge is to support a 
variety of exisiting and evolving protocols. For P2P applications, closed P2P 
caching systems limit effective utilization of in-network storage. Some P2P 
protocols may be entirely unsupported, and applications may be better-equipped 
to decide how in-network storage is used to meet their specific requirements 
(e.g., data placement, access control and resource control).

Both of these challenges can be effectively addressed by using an open, 
standard protocol to access in-network storage. P2P applications can store and 
retrieve content in the in-network storage, as well as control resources 
(e.g., bandwidth, connections) consumed by peers in a P2P application.  As a 
simple example, a peer can choose to store content in the in-network storage, 
and direct other peers to retrieve from that location, reducing last-mile link 
usage.  Though there are existing data access protocols (e.g., HTTP, NFS, 
WebDAV), they lack capabilities needed when applied in this context.

The Working Group (WG) will design and specify a standard protocol for P2P 
applications to utilize in-network storage.  The protocol will include 
operations for a P2P application to (1) store, retrieve, and manage data, (2) 
specify access control for storing and retrieving data suitable for a P2P 
environment with peers across multiple administrative and security domains, 
and (3) indicate resource control policies for storing and retrieving data.  
The WG will leverage existing IETF protocols where possible, in particular for 
storing, retrieving, and managing data.

This WG will focus mainly on the protocol between the in-network storage and 
P2P applications.  The protocol will be focused on P2P applications, though it 
may also be used in other types of applications.

The WG will focus on the following work items:

- A "problem statement" document. This document provides a description of the
  problem and common terminology.

- A requirements document. This document lists the requirements for the
  in-network storage service (e.g., supported operations) and the protocol to
  support it. 

- A survey document. This document will survey existing related mechanisms
  and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their 
  applicability and effectiveness.

- A signaling protocol for storing, retrieving, and managing data as well as
  specifying both access control and resource control policies in the
  in-network storage pertaining to that data.  Data storage, retrieval, and
  management may be provided by an existing IETF protocol. If the underlying
  protocol does not support certain data management operations, DECADE may
  seek to define such extensions and present them to the respective working
  groups or create an Individual Submission if no active working group exists. 
  This group may also create a profile of necessary operations from an
  existing IETF protocol to reduce the complexity and software footprint of a
  compliant implementation.

  The WG will not limit itself to a single underlying protocol since different
  underlying protocols may have varying implementation costs and performance
  tradeoffs. To keep interoperability manageable, a small number of specific,
  targeted, underlying protocols will be used. NFS and WebDAV are initial
  targets and others may be incorporated with WG consensus.

- An informational document describing the integration of DECADE with existing
  P2P applications (e.g., integration with BitTorrent).

The following issues are not considered in the current scope of the WG:

- 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.

- Locating the "best" in-network storage location from which to retrieve
  content if there are more than one location can provide the same content.

- Developing a new protocol to deliver content between P2P application and
  in-network storage.

Goals and Milestones:

May 2010  Working Group Last Call for problem statement 
Aug 2010  Submit problem statement to IESG as Informational 
Aug 2010  Working Group Last Call for requirements document 
Feb 2011  Submit requirements document to IESG as Informational 
May 2011  Working Group Last Call for survey document 
Aug 2011  Working Group Last Call for in-network storage access protocol
Aug 2011  Submit survey document to IESG as Informational
Nov 2011  Submit in-network storage access protocol to IESG as Proposed
          Standard

========================================================================

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

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 26 Jan 2010 14:38:58 -0500

First of all, thanks to the folks working to get the charter put
together. I think this starting to get quite a bit closer to what we
need.

A few thoughts, as well as some nits/editorial comments:

Overall, while much better, there is still a bit of lack of clarity
about what is being developed and what is definitely out of scope from
a protocol perspective. I think the text is good that says we will try
to re-use something (NFS, WebDav, etc.), for example, in para 4 it
says that the WG will design a protocol that "leverage existing IETF
protocols where possible, in particular for storing retrieving and
managing data". However, I think folks could be confused when they
then go on to read the third point for out of scope items is
developing a new protocol to deliver content.

My understanding is that there may be new work on a protocol to
specify policies, and provide control messages and signaling around
the transfers (possibly again reusing/extending or incoprorating some
existing protocols), but that we would definitely reuse something for
the actual transport, hence the third bullet in the out of scope
items. Similarly, the last sentence in para 3 could be read to imply
we can't reuse HTTP, NFS, etc., when I *believe* the intent is to note
that if they are reused, they may need to be extended or used as a
part of a solution. I think we need a bit more clarity to distinguish
between where we may reuse or may develop new (access control,
resource control, etc.), and where we are definitely using existing
(actual transport, from my recollection) and make that a bit more
crisp for a newcomer to this group.

The last two sentences in para 2, when read together, read very oddly:

"For P2P applications, closed P2P caching systems limit effective
utilization of in-network storage. P2P protocols may be entirely
unsupported, and applications may be better-equipped to decide how
in-network storage is used to meet their specific requirements (e.g.,
data placement, access control and resource control)."

maybe this?

"For P2P applications, closed P2P caching systems limit effective
utilization of in-network storage. Some P2P protocols may be entirely
unsupported by a particular caching system. Additionally, applications
may be better-equipped to decide how in-network storage is used to
meet their specific requirements (e.g., data placement, access control
and resource control)."

In paragraph 4, I think maybe we are missing a word in this sentence:

"...(2) specify access control for storing and retrieving data
suitable for a P2P environment ..."

access control settings? values?

The last sentence in the fourth WG item is a bit unclear as well:

"This group may also create a profile of necessary operations from an
existing IETF protocol to reduce the complexity and software footprint
of a compliant implementation."

I think we should be clear about what we mean by compliant
implementation here (i.e., compliant with the existing protocol or
with DECADE). I think we mean a compliant DECADE implementation.

As always, goals and milestones are always wild guesses. Spoken as
someone who chairs another group that currently appears to have
significantly expired milestones (now that I noticed, guess I better
go fix that...oops), these seem really, really aggressive...

Overall, I think this is getting much closer to ready. Great job, and
looking forward to hearing comments from others.

David

On Fri, Jan 22, 2010 at 4:58 PM, Richard Alimi <[email-masked]> wrote:
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade
>

---

From: Richard Alimi <[email-masked]>
Date: Tue, 26 Jan 2010 15:27:24 -0500

Hi David,

First of all, thank you very much for taking the time to read the new proposed 
charter and provide feedback.  Responses inline below:

> items.

Your understanding of the intent is correct.

The intended meaning of the last "out of scope" item was to underline the fact 
that we don't want to design another NFS or WebDAV for transferring data, but 
instead re-use them.  Perhaps it could be clarified as:

  "Developing a new protocol for data transport between P2P applications and
  in-network storage."

Do you think this clarifies it enough?

> Similarly, the last sentence in para 3 could be read to imply
> part of a solution. 

I see the ambiguity here. Perhaps that sentence can be made more explicit by 
saying:
  Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV),
  they currently lack capabilities needed when applied in this context.
As part of DECADE, we aim to fill in the gaps and make certain protocols 
usable in this context.

> I think we need a bit more clarity to distinguish

In regards to identifying where we may need to extend the underlying protocol, 
we currently we have this text:

    If the underlying protocol does not support certain data management
    operations, DECADE may seek to define such extensions and present them to
    the respective working groups or create an Individual Submission if no
    active working group exists.

We are operating under the assumption that the underlying protocol will 
already support read/write (i.e., data transport), and may also have some 
operations for managing whatever data is currently stored. However, there may 
be certain resource management operations that are not currently present. This 
is why we felt it necessary to call out that we may need to extend the set of 
operations in the underlying protocol, and provide an avenue for doing that.

[As a side note, re-reading the existing text, I believe that "data 
management" should be changed to "resource management" since there may exist a 
need to manage resources other than data (e.g., bandwidth, connections).]

To make this distinction more clear, perhaps we can say something like:

    ... The underlying protocol will be used wherever possible to support
    DECADE's required operations. It is assumed that the underlying protocol
    already supports data transport for reading from and writing to in-network
    storage. If the existing underlying protocol does not support certain
    resource management operations, DECADE may seek to define such extensions
    and present them to the respective working groups or create an Individual
    Submission if no active working group exists. ...

> meet their specific requirements (e.g., data placement, access control

This makes sense. This can be incorporated in the next revision.

> access control settings? values?

"policies" may characterize this better.  This can be added.

> with DECADE). I think we mean a compliant DECADE implementation.

Yes, we do mean a compliant DECADE implementation. This can be clarified.

> looking forward to hearing comments from others.

We are also looking forward to hearing comments from others as well :)

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 26 Jan 2010 15:48:23 -0500

Thanks for getting back so quickly. I think the alternate text
sections you suggest below clarify things nicely. Comments (mostly
just me agreeing with you ;) ) inline below:

> Do you think this clarifies it enough?

I think that is much better. The clarification that the data transport
itself won't be reinvented is really the key point (and something I
mentioned in the BoF a couple times, so glad to see it here.)

Interestingly, I noticed another very minor nit as I re-read that
section in the original. The first bullet in the out of scope items is
missing something. It says "Copyright protected or illegal content For
example...". Maybe that should be "Copyright protected or illegal
content management. For example..."?

> As part of DECADE, we aim to fill in the gaps and make certain protocols

Sounds pretty good. I would imagine we might extend, or might have a
new protocol that makes use of (as part of it, either embedded or in
concert with) an existing protocol to meet that goal.

> need to manage resources other than data (e.g., bandwidth, connections).]

Definitely agree here and support that change.

>    Submission if no active working group exists. ...

I think this makes sense.

Thanks!

David

> "policies" may characterize this better.  This can be added.

Yep. I couldn't think of the right word, but policies seems like the
right choice to me.

---

From: Richard Alimi <[email-masked]>
Date: Tue, 26 Jan 2010 15:54:27 -0500

On Tuesday 26 January 2010 3:48:23 pm David A. Bryan wrote:
> just me agreeing with you ;) )

Great - thanks again, David.  I've made a note of these changes and they'll be 
incorporated in the next pass of the document. It would be great to also get 
some comments from others, which would also be included.

---

From: Börje Ohlman <[email-masked]>
Date: Wed, 27 Jan 2010 10:01:19 +0100

Hi All,

I think this charter starts to look quite good.
Though here are two issues I would like to see added to it.

1) How DECADE deals with copies in the in-network storage
I think it would be good to make clear if the network part of DECADE can benefit when multiple users/application stores the same information object (e.g. file). Is it then possible for DECADE to store only one copy of the information object or is it required to store multiple copies of the same object?

2) Should DECADE support mobility of terminals/users/applications?
A lot of today's terminals are mobile, e.g. laptops and smartphones. When they move should their in-network storage move with them or should access to their storage be made by tunneling back to some type of "home storage"?

I think these two issues are important as depending on what is required it will have a strong influence on what protocols and mechanism will be deemed appropriate. As I also think people have quite varying assumptions, depending on background, on these things I think it is important to spell it out in the charter.

Finally a formulation I find confusing.
In §5 it states:
"The Working Group (WG) will design and specify a standard protocol for P2P 
applications to utilize in-network storage."
Then in the last bullet of out-of-scope issues it states:
"Developing a new protocol to deliver content between P2P application and
  in-network storage."
A new proposal for this statement is:
"Developing a new protocol for data transport between P2P applications and
  in-network storage."
I think both these alternatives can easily be seen as contradicting the initial statement.
As I understand it, what is out of scope are protocols between two p2p applications, e.g. BitTorrent like protocols, as well as protocols between two instances of in-network storage, e.g. for cache migration. But protocols for data transport between a p2p application and an in-network storage is very much *in* scope. I think it would be good to state this explicitly, so there is no risk for misunderstanding.

Best regards,
     Börje Ohlman
     Ericsson Research

PS.
For those of you that don't know me, I'm a colleague to Martin Johnsson who presented the Networking of Information work from the 4WARD project at the last IETF meeting.

-----Ursprungligt meddelande-----
Från: [email-masked] genom Richard Alimi
Skickat: fr 2010-01-22 22:58
Till: [email-masked]
Ämne: [decade] Updated DECADE Charter
 
Hi All,

Goals and Milestones:

Thanks!

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 27 Jan 2010 10:20:28 +0100

Hi Bryan,

>content management. For example..."?

What do you mean with illegal content management? Transcoding? Content manipulation?
Perhaps, this could be added as additional point, but this was not meant here.
With illegal content we mean e.g. certain kinds of pornography.

So my proposal would be:
"Copyright protected or illegal content and illicit content manipulation."
What do you think about?

BR
Christian 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext David A. Bryan
Sent: Tuesday, January 26, 2010 9:48 PM
To: Richard Alimi
Cc: [email-masked]
Subject: Re: [decade] Updated DECADE Charter

Thanks!

David

---

From: Richard Alimi <[email-masked]>
Date: Wed, 27 Jan 2010 04:44:47 -0500

Hi Börje,

Thanks for taking the time to provide feedback. See below:

On Wednesday 27 January 2010 4:01:19 am Börje Ohlman wrote:
> I think it would be good to make clear if the network part of DECADE can
>  benefit when multiple users/application stores the same information object
>  (e.g. file). Is it then possible for DECADE to store only one copy of the
>  information object or is it required to store multiple copies of the same
>  object?

While this is an optimization that could be worthwhile, my feeling is that it 
does not matter with respect to the protocol between the application and the 
storage.  If the storage system were to have such a feature, it may be an 
implementation detail.  Are you envisioning a case where this would surface in 
the protocol?

In our Bar BoF at IETF75, I remember Rich Woundy had mentioned a case 
(pertaining to remote DVR, if I recall correctly) where a provider was legally 
required to *not* merge multiple copies of the same data.  Rich - do I recall 
this correctly?

> A lot of today's terminals are mobile, e.g. laptops and smartphones. When
>  they move should their in-network storage move with them or should access
>  to their storage be made by tunneling back to some type of "home storage"?
> 
> I think these two issues are important as depending on what is required it
>  will have a strong influence on what protocols and mechanism will be
>  deemed appropriate. As I also think people have quite varying assumptions,
>  depending on background, on these things I think it is important to spell
>  it out in the charter.

I think this is a good discussion to have and it would be great to get 
opinions from others. My personal feeling is to leave automatic data migration 
out of scope, since it may make the system quite complicated. In particular, 
one of the things we explicitly mentioned as out-of-scope was finding the 
"best" in-network storage element. I think that what you mention here for 
mobility is somewhat related to this.

However, this does mean we would need to be careful to not all of a sudden 
redirect a mobile user to a storage element without their data.

One simple possibility for mobile applications to use DECADE is to rely on 
end-user applications to direct when, where, and what data is migrated. This 
could be done with some very simple interfaces (see the "remote-get" interface 
we mentioned in the strawman proposal at IETF76).  This can be simpler for the 
storage provider, and the end-user may be the person best-qualified to make 
these decisions.

>  As I understand it, what is out of scope are protocols
>  between two p2p applications, e.g. BitTorrent like protocols,

Yes - this is out-of-scope.

>  as well as
>  protocols between two instances of in-network storage, e.g. for cache
>  migration.

The protocol between two in-network storage instances is not currently out-of-
scope.  One case where such a protocol can be useful in P2P is when both the 
uploading and downloading user have in-network storage. See section 5.3.1 of 
the current draft of the problem statement for an example:
  http://tools.ietf.org/html/draft-song-decade-problem-statement-00

In the eventual specification, the actual data transport between two in-
network storages may be done by the underlying protocol, but we may also need 
to pass access control / resource control between them as well (which would be 
in scope for DECADE).

>  But protocols for data transport between a p2p application and
>  an in-network storage is very much *in* scope.

The idea is that we'd like to be able to use existing storage access protocols 
where possible.  The candidates that we mention in the charter currently are 
NFS and WebDAV.  However, in DECADE, we need to pass some additional 
information between the user and in-network storage (e.g., resource control 
and access control).  Do you have suggestions for an alternate wording here?

Thanks!

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 27 Jan 2010 11:01:58 +0100

Thanks for putting this together!

In general I like text, but one thing I think we should do very
carefully is to precisely list what we are sure is missing from existing
protocols -- fine grained access and resource control, right? -- as, at
the end of the day, that will be the reason why the IESG may decide to
charter a new WG. To this extent, I'd prefer to be more explicit, at the
risk of being redundant, e.g. in the last sentence of paragraph 3:

  Though there are existing data access protocols (e.g., HTTP, NFS,
  WebDAV), they lack capabilities needed when applied in this context.

What about replacing it with something along this line?

  Though there are existing data access protocols (e.g., HTTP, NFS,
  WebDAV), they lack capabilities for fine-grained access and resource
  control that are essential for today's advanced P2P algorithms.

Enrico

---

From: "Strandberg, Ove (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 27 Jan 2010 12:13:26 +0200

Hi all,

At the pre-BOF in Stockholm also other applications than P2P was
discussed. I probably missed some of the discussion in Hiroshima, but I
would appriciate shifting focus from P2P intpo more generic use of
network storage, eg. We should not get into too P2P specific solution.
The statement:

"The protocol will be focused on P2P applications, though it may also be
used in other types of applications."

Could be reworked:

"The protocol will be focused on P2P applications, though it should be
generic to allow usage in other types of applications also."

Br,

+Ove

Ps. I also have background in Network of Information in 4WARD project.
Ds. 

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Enrico Marocco
>Sent: 27 January, 2010 12:02
>To: Richard Alimi
>Cc: [email-masked]
>In general I like text, but one thing I think we should do 
>very carefully is to precisely list what we are sure is 
>missing from existing protocols -- fine grained access and 
>resource control, right? -- as, at the end of the day, that 
>will be the reason why the IESG may decide to charter a new 
>WG. To this extent, I'd prefer to be more explicit, at the 
>> We have been working on a new charter with a refined scope and 
>> incorporating past discussion on the mailing list.  It would be 
>> wonderful to hear comments on the new proposed charter.
>> 
>> 
>> Peer-to-Peer (P2P) applications, including both P2P 
>streaming and P2P 
>> file- sharing applications, make up a large fraction of 
>traffic in the 
>> Internet today. One way to reduce access network and/or cross-domain 
>> bandwidth usage by P2P applications is to introduce storage 
>capabilities in the networks.
>> Allowing P2P applications to store and retrieve data from inside 
>> networks can reduce traffic on the last-mile uplink, as well 
>as backbone and transit links.
>> 
>> Existing P2P caches often implement the specific P2P application 
>> protocols to operate transparently or act as super peers to 
>provide in-network storage.
>> However, this approach poses challenges to both P2P cache 
>vendors and 
>> P2P application developers. For P2P cache vendors, the 
>challenge is to 
>> support a variety of exisiting and evolving protocols. For P2P 
>> applications, closed P2P caching systems limit effective utilization 
>> of in-network storage. Some P2P protocols may be entirely 
>unsupported, 
>> and applications may be better-equipped to decide how in-network 
>> storage is used to meet their specific requirements (e.g., 
>data placement, access control and resource control).
>> 
>> Both of these challenges can be effectively addressed by using an 
>> open, standard protocol to access in-network storage. P2P 
>applications 
>> can store and retrieve content in the in-network storage, as well as 
>> control resources (e.g., bandwidth, connections) consumed by 
>peers in 
>> a P2P application.  As a simple example, a peer can choose to store 
>> content in the in-network storage, and direct other peers to 
>retrieve 
>> from that location, reducing last-mile link usage.  Though there are 
>> existing data access protocols (e.g., HTTP, NFS, WebDAV), 
>they lack capabilities needed when applied in this context.
>> 
>> The Working Group (WG) will design and specify a standard 
>protocol for 
>> P2P applications to utilize in-network storage.  The protocol will 
>> include operations for a P2P application to (1) store, retrieve, and 
>> manage data, (2) specify access control for storing and retrieving 
>> data suitable for a P2P environment with peers across multiple 
>> administrative and security domains, and (3) indicate 
>resource control policies for storing and retrieving data.
>> The WG will leverage existing IETF protocols where possible, in 
>> particular for storing, retrieving, and managing data.
>> 
>> This WG will focus mainly on the protocol between the in-network 
>> storage and P2P applications.  The protocol will be focused on P2P 
>> applications, though it may also be used in other types of 
>applications.
>> 
>> May 2010  Working Group Last Call for problem statement Aug 2010  
>> Submit problem statement to IESG as Informational Aug 2010  Working 
>> Group Last Call for requirements document Feb 2011  Submit 
>> requirements document to IESG as Informational May 2011  
>Working Group 
>> Last Call for survey document Aug 2011  Working Group Last Call for 
>> in-network storage access protocol Aug 2011  Submit survey 
>document to 
>> IESG as Informational Nov 2011  Submit in-network storage access 
>> protocol to IESG as Proposed
>>           Standard
>> 
>>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 27 Jan 2010 13:41:39 +0200

Hi,

>  control that are essential for today's advanced P2P algorithms.

NFSv4 supports ACLs, so if you want to make the case that it lacks fine-grained access control I'd personally need some further convincing.

As for resource control, I think you have identified one of NFSv4's current shortcomings for this use case. To charter some new protocol development here, I would personally need to see an argument that that was somehow less development effort than adding resource control mechanisms to NFSv4 (e.g., through the hints mechanism.)

Lars

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 27 Jan 2010 13:15:23 +0100

Lars Eggert wrote:
>> WebDAV), they lack capabilities for fine-grained access and
>> resource control that are essential for today's advanced P2P
>> algorithms.
> 
> NFSv4 supports ACLs, so if you want to make the case that it lacks
> fine-grained access control I'd personally need some further
> convincing.

I was actually thinking of access control at a chunk level, assuming
such a fine granularity would be actually useful to P2P applications.
However, I agree that what's certainly missing is the ability to
allocate and control resources like bandwidth and number of connections.

> As for resource control, I think you have identified one of NFSv4's
> current shortcomings for this use case. To charter some new protocol
> development here, I would personally need to see an argument that
> that was somehow less development effort than adding resource control
> mechanisms to NFSv4 (e.g., through the hints mechanism.)

Makes sense to me, even if I suspect we disagree on the timing of such a
discussion -- I'd be perfectly comfortable with letting the WG-to-be
evaluate and decide whether to do resource control in a new protocol, or
to define it as an extension for an existing one (as stated in #4 of the
work items list), but I guess the same doesn't hold for you.

-- 
Ciao,
Enrico

---

From: Richard Alimi <[email-masked]>
Date: Wed, 27 Jan 2010 09:19:18 -0500

Hi Lars,

On Wednesday 27 January 2010 6:41:39 am Lars Eggert wrote:
>  fine-grained access control I'd personally need some further convincing.

It was my understanding that NFS requires the server to have an account for 
each user that can be granted permissions.  Or, are there other models that 
are supported that you could point me to?

One of the things that we included in the charter was the following:

  ... specify access control for storing and retrieving data suitable for a
  P2P environment with peers across multiple administrative and security
  domains ...

In the P2P context, a client can have a particular policy (e.g., to implement 
incentives) indicating which data (and how fast) to send to particular peers. 
Others should be prevented from fetching those same blocks from the client's 
in-network storage.  Both the set of blocks being distributed and the peers to 
which they are being sent can change at a small timescale.

Would NFS's ACLs be suited for this? My concern was that the client would have 
to do the following:
(1) Register a new user with the NFS server for each new peer to which data is
    being sent.
(2) For each block (or set of blocks) sent to the peer, add the peer to the
    ACLs for those blocks.
(3) Remove the peer from the ACLs and delete the user when the peer is
    disconnected.
This sounds like a lot of overhead for both the client and the server.

One possibility for avoiding the overhead is to have a scheme using access 
tokens.  Clients can hand out tokens (possibly with an expiration time) 
without involvement from the server. The server just needs to verify the token 
when data is requested.

---

From: Haibin Song <[email-masked]>
Date: Thu, 28 Jan 2010 00:34:18 +0800

I agree. And another reason is that when we consider various implementations, we feel should not limit the underlying protocol to NFS, but we must consider it as one of the main underlying protocol for data transport and content structure.

2010-01-28 

Haibin Song 

On 2010-01-27  22:19:42   Richard Alimi  wrote:  

Hi Lars,

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 27 Jan 2010 13:20:04 -0500

I'm actually not too picky on what we say, as long as the intent is
there. "Management" certainly may be the wrong word, and your
suggestion is fine by me as well. Mostly I just noticed that the
original version appeared missing a word and/or some punctuation from
a grammatical perspective.

David

On Wed, Jan 27, 2010 at 4:20 AM, Schmidt, Christian 1. (NSN -

---

From: Song Haibin <[email-masked]>
Date: Fri, 29 Jan 2010 10:55:48 +0800

Hi Ove,

Thanks for the good comment. It is very useful if the protocol can be used
by other types of applications. But If you consider other applications for
the first step, you have to incorporate  other features. For example, you
may need replicas in the in-network storage to guarantee QoS. I prefer to
focus on P2P applications initially, but keep other applications in mind, so
that later extensions can be made to let better integration with other
applications.

Xie Xie,
Haibin

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Strandberg, Ove 
> (NSN - FI/Espoo)
> Sent: Wednesday, January 27, 2010 6:13 PM
> To: ext Enrico Marocco; Richard Alimi
> Cc: [email-masked]
> At the pre-BOF in Stockholm also other applications than P2P 
> was discussed. I probably missed some of the discussion in 
> Hiroshima, but I would appriciate shifting focus from P2P 
> intpo more generic use of network storage, eg. We should not 
> get into too P2P specific solution.
> The statement:
> 
> "The protocol will be focused on P2P applications, though it 
> may also be used in other types of applications."
> 
> Could be reworked:
> 
> "The protocol will be focused on P2P applications, though it 
> should be generic to allow usage in other types of applications also."
> 
> Br,
> 
> +Ove
> 
> >From: [email-masked] [mailto:[email-masked]] On 
> >Behalf Of ext Enrico Marocco
> >carefully is to precisely list what we are sure is missing from 
> >existing protocols -- fine grained access and resource 
> control, right? 
> >-- as, at the end of the day, that will be the reason why 
> the IESG may 
> >decide to charter a new WG. To this extent, I'd prefer to be more 
> >explicit, at the risk of being redundant, e.g. in the last 
> sentence of 
> >paragraph 3:
> >
> resource  
> >=============================================================
> =========
> >> ==
> >> 
> >=============================================================
> =========
> >> ==
> >> 
> >> Thanks!
> >

---

From: "Strandberg, Ove (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 29 Jan 2010 12:41:25 +0200

Hi Haibin,

Thanks for your comments.

My main concern with P2P as use case is that other interaction towards a
network storage other than originating from a P2P client will not be
considered. I could easily imagine the benefit of network storage for
examples for applications like Spotify, Youtube, IPTV etc.. They can
potentially be interedsted in memory utilization too. Thus there are
other potential use of a network storage protocol. The relationship of
these towards a network storage looks different from a P2P client
perspective and designing from only P2P in first step potentially
limiting. 

This use case concern is of principal matter (me thinks) and the charter
should reflect this already now. This change does not change the fact
that most interest might be on solving the P2P use case, but there are
more use cases that should be included in the charter description.

Br,

+Ove

>From: ext Song Haibin [mailto:[email-masked]] 
>Sent: 29 January, 2010 04:56
>To: Strandberg, Ove (NSN - FI/Espoo); 'ext Enrico Marocco'; 
>'Richard Alimi'
>Cc: [email-masked]
>Subject: RE: [decade] Updated DECADE Charter
>
>
>Hi Ove,
>
>Thanks for the good comment. It is very useful if the protocol 
>can be used by other types of applications. But If you 
>consider other applications for the first step, you have to 
>incorporate  other features. For example, you may need 
>replicas in the in-network storage to guarantee QoS. I prefer 
>to focus on P2P applications initially, but keep other 
>applications in mind, so that later extensions can be made to 
>let better integration with other applications.
>
>Xie Xie,
>Haibin
> 
>
>> [mailto:[email-masked]] On Behalf Of Strandberg, Ove (NSN - 
>> FI/Espoo)
>> discussed. I probably missed some of the discussion in 
>Hiroshima, but 
>> I would appriciate shifting focus from P2P intpo more generic use of 
>should be

---

From: "Y.J. Gu" <[email-masked]>
Date: Fri, 29 Jan 2010 20:09:16 +0800

Hi, 
I agree with taking other applications into consideration at the first
beginning. At least we should analyze whether compatible with other
applications will make significant difference, comparing with the
protocol/mechanism designed exclusively for P2P. 
If we donot want to make this effort, then how about just removing words
like "can be used by other applications".

My 2 cents.

Regards
Yingjie Gu

> Sent: Friday, January 29, 2010 6:41 PM
> To: ext Song Haibin; ext Enrico Marocco; Richard Alimi
> Cc: [email-masked]
> My main concern with P2P as use case is that other 
> interaction towards a network storage other than originating 
> from a P2P client will not be considered. I could easily 
> imagine the benefit of network storage for examples for 
> applications like Spotify, Youtube, IPTV etc.. They can 
> potentially be interedsted in memory utilization too. Thus 
> there are other potential use of a network storage protocol. 
> The relationship of these towards a network storage looks 
> different from a P2P client perspective and designing from 
> only P2P in first step potentially limiting. 
> 
> This use case concern is of principal matter (me thinks) and 
> the charter should reflect this already now. This change does 
> not change the fact that most interest might be on solving 
> the P2P use case, but there are more use cases that should be 
> included in the charter description.
> 
> Br,
> 
> +Ove
> 
> >To: Strandberg, Ove (NSN - FI/Espoo); 'ext Enrico Marocco'; 'Richard 
> >Alimi'
> >Cc: [email-masked]
> >Thanks for the good comment. It is very useful if the 
> protocol can be 
> >used by other types of applications. But If you consider other 
> >applications for the first step, you have to incorporate  other 
> >features. For example, you may need replicas in the 
> in-network storage 
> >to guarantee QoS. I prefer to focus on P2P applications 
> initially, but 
> >keep other applications in mind, so that later extensions 
> can be made 
> >to let better integration with other applications.
> >
> >Xie Xie,
> >Haibin
> > 
> >
> Aug 2010

---

From: Lars Eggert <[email-masked]>
Date: Fri, 29 Jan 2010 14:21:46 +0200

Hi,

> are supported that you could point me to?

I'm not the greatest NFS expert in the world either, but IMO the onus is on the proponents of DECADE to convincingly demonstrate that it would be better/easier/otherwise useful to create a new protocol here rather than extending an existing one. Yes, that probably means that someone will have to familiarize themselves with the existing protocols.

Lars

---

From: Börje Ohlman <[email-masked]>
Date: Fri, 29 Jan 2010 15:43:38 +0100

Hi Richard,

I don't think support for mobility necessarily needs to make things 
complex, not if it is designed in from the beginning (e.g. see Internet 
Indirection Infrastructure (i3)), it is when it is added as an 
afterthought things get complex. That is why I think that support for 
basic node mobility should at least be considered.

I also think the two issues 'copies' and  'mobility' are related to a 
certain extent. Being able to use locally available copies rather than 
to have to access 'your own' remote or migrated copy can simplify 
mobility significantly.

Please see further comments in line below.

    Börje

> implementation detail.  Are you envisioning a case where this would surface in 
How you refer to an object, e.g. by relative or absolute references, has 
an influence on how easy it is to identify a copy of an object. If you 
use relative path names to refer to objects see that two objects are the 
same.
> mobility is somewhat related to this.
If we don't want to get into data migration and trying to find 'the 
best' copy I would settle to for agreeing that it is ok to use locally 
available copies if they happens to be around. As I indicated above this 
could simplify giving some basic support for nodes that are not 
permanently stationary in the network.
> and access control).  Do you have suggestions for an alternate wording here?
If the current thinking is that we want to try to find a suitable 
protocol to be reused I think it is a bit premature to state that 
developing a new protocol is out of scope before we have even defined 
the requirements for the functionality of the new protocol.

    Börje

---

From: Song Haibin <[email-masked]>
Date: Sat, 30 Jan 2010 09:35:15 +0800

I would like to hear other people's opinions. My personal feeling is that it
will get things a little complicated. You have to do a survey of
resource/access control behaviors for other types of applications which will
possibly use in-network storage, that will broaden the scope a lot. 

Xie Xie,
Haibin

> From: Strandberg, Ove (NSN - FI/Espoo) 
> [mailto:[email-masked]]

---

From: Wesley Leggette <[email-masked]>
Date: Fri, 29 Jan 2010 19:35:52 -0600

As I've said before, I'm also interested in a more general purpose
distributed network storage protocol. Specifically, it would be nice to have
a standards-based protocol with at least the primitives necessary to support
a distributed file system. These would include at the very least proper
revision/commit safeties and support for some form of distributed write
locking.

As for analyzing whether compatibility with other applications makes sense
for DECADE, I know off hand of quite a few differences which could make it
difficult to merge DECADE's original goal with a more general storage
network protocol.

The main difference is in the way the presence of data is communicated. P2P
is generally geared towards out-of-band advertising and in-band pull (the
download from the peer) and replicate (when the data is cached locally on
the requesting client). With a storage system, clients expect to be able to
push data, and this presents timing problems when it comes time to advertise
what data was just written. How do other users know if data has been
written? Is it advertised out-of-band after the entire data set is written?
This is an approach similar to BitTorrent where you have to obtain torrent
files somehow after the first seed is complete. Is there an in-band
mechanism to list or query what is out there in a generic way? If so, when
is data visible in the in-band mechanism; during a write or after all writes
are complete?

Also, if the goal is for "other applications", are these
write-once-read-many systems, or can data be overwritten? If the system is
designed to allow data to be overwritten then there has to be a mechanism to
safely update multi-part data (so that a large file can be stored in smaller
segments and the correct matching segment versions are always available).

If DECADE ends up being just a way to cache data requests made through a
particular P2P system, it's also worth noting that different P2P systems use
different data formats. If DECADE just provides format unaware storage this
could mean that data will have to be stored twice if its made available over
different P2P applications.

While I'm not sure that DECADE wants to deal with any of these issues, it
could very well be worth creating a second working group to deal with
general purpose distributed storage system.

Wesley Leggette

---

From: Richard Alimi <[email-masked]>
Date: Sun, 31 Jan 2010 23:25:24 -0500

Hi Lars,

> I'm not the greatest NFS expert in the world either, but IMO the onus is on
>  the proponents of DECADE to convincingly demonstrate that it would be
>  better/easier/otherwise useful to create a new protocol here rather than
>  extending an existing one. Yes, that probably means that someone will have
>  to familiarize themselves with the existing protocols.

Thanks for the response.  First, I'd like to clarify that we're on the same 
page in regards to the intended WG scope.  We will indeed re-use existing 
underlying protocols wherever possible. According to the currently-proposed 
charter, the new WG would be responsible for:

- Defining the access-control requirements, needed resource-control
  information, and the necessary management interfaces that would be necessary
  for scenarios where DECADE would be applied (primarily usage by P2P
  applications).  These core pieces would be common to any DECADE
  implementation.

- Define DECADE to operate over existing underlying protocols. In the charter,
  we have explicitly mentioned NFS and WebDAV as targets, since both are
  well-established protocols and each may be applicable in different
  deployment scenarios.

  For example, when applying to NFS, we will certainly re-use existing
  mechanisms (e.g., access control if possible, and the hints mechanism) to do
  so.  If the NFS protocol itself would need to be modified or extended, then
  such modifications or extensions would be presented to the NFSv4 WG.

Does the clarify the intended scope?

I'm also trying to understand your viewpoint a bit better here.  Are you of 
the opinion that NFS is the only protocol that should be extended?

Thanks!

---

From: Richard Alimi <[email-masked]>
Date: Sun, 31 Jan 2010 23:56:08 -0500

Hi Börje,

> to have to access 'your own' remote or migrated copy can simplify

Comments below...

> >>  benefit when multiple users/application stores the same information
> >> object (e.g. file). Is it then possible for DECADE to store only one
> >> copy of the information object or is it required to store multiple
> >> copies of the same object?
> >
> > While this is an optimization that could be worthwhile, my feeling is
> > that it does not matter with respect to the protocol between the
> > application and the storage.  If the storage system were to have such a
> > feature, it may be an implementation detail.  Are you envisioning a case
> > where this would surface in the protocol?
> 

I think I am beginning to see where you are coming from here.  My response 
above was in the more general case, where the storage system automatically 
detected objects that contained exactly the same data, and then, as an 
optimization in the implementation, deleted one and replaced it with a link 
(e.g, a hardlink) to the other.  This would have the effect of reducing 
redundancy across multiple users using storage at the same server.  Note that 
it would *not* be safe to only do this based on the naming of the object.

However, it sounds like you are referring to a user explicitly creating links 
to objects within his or her own storage - is this an accurate 
characterization?  If not, can you provide an example?

When it comes to defining exactly which management operations would be 
supported by DECADE, this is already in the charter.   I believe links between 
objects would be considered a management operation and this would be fair 
game.

You've also touched on the naming here.  This is something that would have to 
be decided as well within the WG, but is probably not important for the 
charter.

I'd be good to get opinions from others here as well.

> >> A lot of today's terminals are mobile, e.g. laptops and smartphones.
> >> When they move should their in-network storage move with them or should
> >> access to their storage be made by tunneling back to some type of "home
> >> storage"?
> >
> > opinions from others. My personal feeling is to leave automatic data
> > migration out of scope, since it may make the system quite complicated.
> > In particular, one of the things we explicitly mentioned as out-of-scope
> > was finding the "best" in-network storage element. I think that what you
> > mention here for mobility is somewhat related to this.
> 

Yes, I certainly agree that it should be possible for clients to use a closer 
copy if it is available.  One way I can see for providing such functionality 
without needing automatic data migration is for a client to locally have a 
list of DECADE servers (e.g., DNS names) available to it, and the client 
locally picks the most-desired one with the data it needs.

Are there other possibilities (not using data migration) that you were 
thinking about?

> > The idea is that we'd like to be able to use existing storage access
> > protocols where possible.  The candidates that we mention in the charter
> > currently are NFS and WebDAV.  However, in DECADE, we need to pass some
> > additional information between the user and in-network storage (e.g.,
> > resource control and access control).  Do you have suggestions for an
> > alternate wording here?
> 

We have an initial copy of the requirements draft and have done some initial 
thinking about how it might be applied to NFS or WebDAV.  We have also left 
the charter open to providing extensions where necessary.

Is there certain functionality that you believe would just fundamentally not 
align with such protocols (meaning extensions would not be a good approach)?

---

From: Richard Alimi <[email-masked]>
Date: Mon, 1 Feb 2010 00:52:45 -0500

Hi Wesley,

Thank you very much for your interest and it is great to get your input, even 
though it is quite clear that we have different goals :) Please see inline:

On Friday 29 January 2010 8:35:52 pm Wesley Leggette wrote:
> distributed network storage protocol. Specifically, it would be nice to
>  have a standards-based protocol with at least the primitives necessary to
>  support a distributed file system. These would include at the very least
>  proper revision/commit safeties and support for some form of distributed
>  write locking.

While I do agree that such a protocol interesting, I also believe that would 
be far beyond what we are targeting in DECADE.  With some very basic 
capabilities (e.g., without distributed locking, without commitment, etc), we 
can already support the class of applications we are targeting.

> difficult to merge DECADE's original goal with a more general storage

Yes, I fully agree that there would be (quite large) differences between the 
original goal and a more general storage network protocol.  This is primarily 
the reason that I think we would like to keep our scope more narrow.

> push data, and this presents timing problems when it comes time to
>  advertise what data was just written. How do other users know if data has
>  been written? 

In our thinking for DECADE, other users are notified via the native P2P 
protocols. Something similar could be done with integration in other 
applications (e.g., inside Flash for YouTube).

>  Is it advertised out-of-band after the entire data set is
>  written?

In our thinking for DECADE, but the DECADE protocol doesn't have to deal with 
this since, as you mentioned, it is out-of-band.

>  This is an approach similar to BitTorrent where you have to
>  obtain torrent files somehow after the first seed is complete. Is there an
>  in-band mechanism to list or query what is out there in a generic way?

I presume DECADE would have an operation to list which objects are currently 
stored at a particular server.  My feeling is that it would be more 
complicated than we need to support search for stored objects across the 
network.  In our context, that could be done in the P2P protocols themselves 
(e.g., objects may be advertised via a DHT or the normal buffer map 
exchanges).  Other applications could also have something like this.

>  If
>  so, when is data visible in the in-band mechanism; during a write or after
>  all writes are complete?

For DECADE, in the P2P case anyways, each object may just be a piece of the 
file anyways.  An object can be visible directly after it is written (and 
maybe even optimized to be visible as it is being written).

I do realize that you are asking these questions in the context of a more 
general distributed storage protocol, and that my answers are focused on the 
use cases for DECADE.  I'm basically trying to illustrate how much simpler the 
protocol design can be with our original goal.

> designed to allow data to be overwritten then there has to be a mechanism
>  to safely update multi-part data (so that a large file can be stored in
>  smaller segments and the correct matching segment versions are always
>  available).

In our case, I envision we are going for write-once-read-many. This would be 
sufficient for P2P applications that chop their data into smaller pieces 
anyways.  The clients can upload and download data in pieces - but the storage 
system doesn't even have to know that they form a larger file.

> particular P2P system, it's also worth noting that different P2P systems
>  use different data formats. If DECADE just provides format unaware storage
>  this could mean that data will have to be stored twice if its made
>  available over different P2P applications.

Two comments here.  First, keep in mind that each user can have his or her own 
storage (DECADE is not envisioned just a standard "caching" protocol). Thus, 
two users can have the same object (even in the same format) -- if the storage 
system wishes to actually have the objects point the same block of storage, 
then that is fine - it is out-of-scope for the protocol.

Second, we are not trying to standardize a data format in which objects need 
to be stored - each application can store in whatever format it chooses.  
You're right that this may produce data that would need to be stored twice.

> general purpose distributed storage system.

Personally, I would actually be very interested to follow such a working group 
:)

Thanks again for your interest and feedback!
-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: Richard Alimi <[email-masked]>
Date: Mon, 1 Feb 2010 01:02:00 -0500

I agree that doing a survey of every application that might use in-network 
storage would be quite a daunting task, and that it makes sense to keep our 
problem narrower.

That said, I was trying to think of a good way to characterize a broader set 
of applications than "P2P" that we can target, as I do agree that applications 
such as YouTube and IPTV might have some good use cases.  Might it be fair to 
say that we can target applications that distribute large data files that 
might be subdivided in to smaller pieces?

As for wording in the charter, how about something like:

    ... The protocol will be focused on P2P applications and similar
    applications that can subdivide data into smaller pieces for distribution.

Thoughts?

On Friday 29 January 2010 8:35:15 pm Song Haibin wrote:
> I would like to hear other people's opinions. My personal feeling is that
>  it will get things a little complicated. You have to do a survey of
> resource/access control behaviors for other types of applications which
>  will possibly use in-network storage, that will broaden the scope a lot.
> 
> 
> Xie Xie,
> Haibin
> 
> > >> [mailto:[email-masked]] On Behalf Of Strandberg,
> >
> > Ove (NSN -
> >
> > >> FI/Espoo)
> > >> I would appriciate shifting focus from P2P intpo more
> >
> > generic use of
> >
> > >> network storage, eg. We should not get into too P2P specific
> > >
> > >solution.
> > >
> > >> The statement:
> > >>
> > >may also
> > >> be used in other types of applications."
> > >>
> > >> Could be reworked:
> > >>
> > >> Ps. I also have background in Network of Information in
> > >
> > >4WARD project.
> > >
> > >> Ds.
> > >>
> > >> >  Though there are existing data access protocols (e.g.,
> >
> > HTTP, NFS,
> >
> > >> > WebDAV), they lack capabilities needed when applied in
> > >
> > >this context.
> > >
> > >> >  Though there are existing data access protocols (e.g.,
> >
> > HTTP, NFS,
> >
> > >> >> Internet today. One way to reduce access network and/or
> > >>
> > >> cross-domain
> > >>
> > >> >> Allowing P2P applications to store and retrieve data
> >
> > from inside
> >
> > >> >> Existing P2P caches often implement the specific P2P
> >
> > application
> >
> > >> >> applications, closed P2P caching systems limit effective
> > >>
> > >> utilization
> > >>
> > >> >> and applications may be better-equipped to decide how
> >
> > in-network
> >
> > >> >> Both of these challenges can be effectively addressed
> >
> > by using an
> >
> > >> >> can store and retrieve content in the in-network storage,
> > >>
> > >> as well as
> > >>
> > >> >> a P2P application.  As a simple example, a peer can choose
> > >>
> > >> to store
> > >>
> > >> >> from that location, reducing last-mile link usage.  Though
> > >>
> > >> there are
> > >>
> > >> >> P2P applications to utilize in-network storage.  The
> > >
> > >protocol will
> > >
> > >> >> include operations for a P2P application to (1) store,
> > >>
> > >> retrieve, and
> > >>
> > >> >> manage data, (2) specify access control for storing and
> > >
> > >retrieving
> > >
> > >> >> This WG will focus mainly on the protocol between the
> >
> > in-network
> >
> > >> >> storage and P2P applications.  The protocol will be
> > >
> > >focused on P2P
> > >
> > >> >> - A "problem statement" document. This document provides a
> > >> >
> > >> >description of the
> > >> >
> > >> >> - A requirements document. This document lists the
> > >> >
> > >> >requirements for the
> > >> >
> > >> >>   in-network storage service (e.g., supported operations)
> > >> >
> > >> >and the protocol to
> > >> >
> > >> >>   support it.
> > >> >>
> > >> >> - A survey document. This document will survey existing
> > >> >
> > >> >related mechanisms
> > >> >
> > >> >>   and protocols (e.g., HTTP, NFS, and WebDAV), and
> >
> > evaluate their
> >
> > >> >> - A signaling protocol for storing, retrieving, and managing
> > >> >
> > >> >data as well as
> > >> >
> > >> >>   specifying both access control and resource control
> > >>
> > >> policies in the
> > >>
> > >> >>   in-network storage pertaining to that data.  Data storage,
> > >> >
> > >> >retrieval, and
> > >> >
> > >> >>   management may be provided by an existing IETF protocol.
> > >> >
> > >> >If the underlying
> > >> >
> > >> >>   protocol does not support certain data management
> > >> >
> > >> >operations, DECADE may
> > >> >
> > >> >>   seek to define such extensions and present them to the
> > >> >
> > >> >respective working
> > >> >
> > >> >>   groups or create an Individual Submission if no active
> > >> >
> > >> >working group exists.
> > >> >
> > >> >>   This group may also create a profile of necessary
> > >> >
> > >> >operations from an
> > >> >
> > >> >>   existing IETF protocol to reduce the complexity and
> > >> >
> > >> >software footprint of a
> > >> >
> > >> >>   The WG will not limit itself to a single underlying
> > >> >
> > >> >protocol since different
> > >> >
> > >> >>   underlying protocols may have varying implementation costs
> > >> >
> > >> >and performance
> > >> >
> > >> >>   tradeoffs. To keep interoperability manageable, a small
> > >> >
> > >> >number of specific,
> > >> >
> > >> >>   targeted, underlying protocols will be used. NFS and
> > >> >
> > >> >WebDAV are initial
> > >> >
> > >> >> - An informational document describing the integration of
> > >> >
> > >> >DECADE with existing
> > >> >
> > >> >> The following issues are not considered in the current scope
> > >> >
> > >> >of the WG:
> > >> >>   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.
> > >> >>
> > >> >> - Locating the "best" in-network storage location from which
> > >> >
> > >> >to retrieve
> > >> >
> > >> >>   content if there are more than one location can provide
> > >> >
> > >> >the same content.
> > >> >
> > >> >> - Developing a new protocol to deliver content between P2P
> > >> >
> > >> >application and
> > >> >
> > >> >>   in-network storage.
> > >> >>
> > >> >> Goals and Milestones:
> > >> >>
> > >> >> Submit problem statement to IESG as Informational Aug 2010
> > >>
> > >>  Working
> > >>
> > >> >> Last Call for survey document Aug 2011  Working Group Last
> > >>
> > >> Call for
> > >>
> > >> >> IESG as Informational Nov 2011  Submit in-network
> >
> > storage access
> >