From melodysong@huawei.com  Tue Jun  1 02:16:10 2010
Return-Path: <melodysong@huawei.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9613A695E for <decade@core3.amsl.com>; Tue,  1 Jun 2010 02:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level: 
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFnSOt+ZfXlA for <decade@core3.amsl.com>; Tue,  1 Jun 2010 02:16:10 -0700 (PDT)
Received: from szxga05-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 573B63A6805 for <decade@ietf.org>; Tue,  1 Jun 2010 02:16:05 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3B0090XWB3FY@szxga05-in.huawei.com> for decade@ietf.org; Tue, 01 Jun 2010 17:13:51 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3B00BYKWB3TH@szxga05-in.huawei.com> for decade@ietf.org; Tue, 01 Jun 2010 17:13:51 +0800 (CST)
Received: from s64081a ([10.138.84.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3B0045WWAX7L@szxml06-in.huawei.com> for decade@ietf.org; Tue, 01 Jun 2010 17:13:51 +0800 (CST)
Date: Tue, 01 Jun 2010 17:13:45 +0800
From: Song Haibin <melodysong@huawei.com>
To: decade@ietf.org
Message-id: <000001cb016a$bcebeb10$36c3c130$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-cn
Content-transfer-encoding: 7BIT
Thread-index: AcsBarU6dswbHMjuSGmy+Lor8rmYsQ==
x-cr-hashedpuzzle: Bn/+ Cl5q FGKZ Fu3y HMIX HQjf HfN0 HoW6 JJ+V JV8w Ju1c Ju3G JzH5 J2K6 KTqA K9lo; 1; ZABlAGMAYQBkAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {AE988DF0-B70F-4EFD-BB17-C2EA014BADC4}; bQBlAGwAbwBkAHkAcwBvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 01 Jun 2010 09:13:32 GMT; QQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuACAAdwBpAHQAaAAgAE8AQQB1AHQAaAA/AA==
x-cr-puzzleid: {AE988DF0-B70F-4EFD-BB17-C2EA014BADC4}
Subject: [decade] Authentication with OAuth?
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2010 09:16:10 -0000

One possible authentication method for DECADE might be reusing OAuth. I'm
not sure whether OAuth can fit well here. Can existing OAuth be used to
authorize bandwidth or priority to the requester? I'm not sure whether we
need the unauthorized request token step in DECADE context.

Thanks,
Haibin <as contributor>



From Even.roni@huawei.com  Tue Jun  1 14:43:47 2010
Return-Path: <Even.roni@huawei.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6417B28C159 for <decade@core3.amsl.com>; Tue,  1 Jun 2010 14:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.106
X-Spam-Level: **
X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z48msriDYfh2 for <decade@core3.amsl.com>; Tue,  1 Jun 2010 14:43:46 -0700 (PDT)
Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F0A6428C123 for <decade@ietf.org>; Tue,  1 Jun 2010 14:43:45 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3C00GHJV0BT0@szxga05-in.huawei.com> for decade@ietf.org; Wed, 02 Jun 2010 05:43:23 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3C001PHV0ABO@szxga05-in.huawei.com> for decade@ietf.org; Wed, 02 Jun 2010 05:43:23 +0800 (CST)
Received: from windows8d787f9 (bzq-79-180-6-113.red.bezeqint.net [79.180.6.113]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0L3C00ITLV03LR@szxml01-in.huawei.com> for decade@ietf.org; Wed, 02 Jun 2010 05:43:22 +0800 (CST)
Date: Wed, 02 Jun 2010 00:41:23 +0300
From: Roni Even <Even.roni@huawei.com>
To: decade@ietf.org
Message-id: <026801cb01d3$328511e0$978f35a0$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_9k0k9h0Q6oYB+iDGE8UHVg)"
Content-language: en-us
Thread-index: AcsB0yiqTKlwUn2MQ2OZxoXGL2wFnw==
x-cr-hashedpuzzle: M+U= BC0C DfG2 Djsy Dm/0 Ey+R FMXB Frrx FutE F223 HLEw JORv J5Pe K1yT LGdB LfvT; 1; ZABlAGMAYQBkAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {FC3AA4E4-31BE-4DC9-B8FD-2E1FFCA9968A}; ZQB2AGUAbgAuAHIAbwBuAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Tue, 01 Jun 2010 21:41:14 GMT;VQBzAGkAbgBnACAATgBGAFMAIAA0AC4AMQAgAGkAbgAgAEQARQBDAEEARABFAA==
x-cr-puzzleid: {FC3AA4E4-31BE-4DC9-B8FD-2E1FFCA9968A}
Subject: [decade] Using NFS 4.1 in DECADE
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2010 21:43:47 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_9k0k9h0Q6oYB+iDGE8UHVg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi,

NFS 4.1 section 2.9 discuss the transport layer and has some requirements
from the transport which are not part of NFS 4.1 or RPC.

 

The following statement is part of the section

 

" It is permissible for a connectionless transport to be used under

   NFSv4.1; however, reliable and in-order delivery of data combined

   with congestion control by the connectionless transport is REQUIRED.

   As a consequence, UDP by itself MUST NOT be used as an NFSv4.1

   transport.  NFSv4.1 assumes that a client transport address and

   server transport address used to send data over a transport together

   constitute a connection, even if the underlying transport eschews the

   concept of a connection."

 

The current charter or the requirements are not discussing any requirements
from the transport protocol.

 

So far I thought that the media may be delivered using UDP therefore I think
that we need to address this issue if we want to have NFS 4.1 as a candidate
solution adding the requirement for TCP support.

I can see the value in the reliability and in-order and believe that since
the data will not be stored using RTP we can look at using TCP. 

 

Roni Even


--Boundary_(ID_9k0k9h0Q6oYB+iDGE8UHVg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Hi,<o:p></o:p></p>

<p class=3DMsoNormal>NFS 4.1 section 2.9 discuss the transport layer and =
has some
requirements from the transport which are not part of NFS 4.1 or =
RPC.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The following statement is part of the =
section<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>&quot; It is permissible for a connectionless =
transport to
be used under<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp; NFSv4.1; however, reliable and =
in-order
delivery of data combined<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp; with congestion control by the =
connectionless
transport is REQUIRED.<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp; As a consequence, UDP by itself MUST =
NOT be
used as an NFSv4.1<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp; transport.&nbsp; NFSv4.1 assumes that =
a client
transport address and<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp; server transport address used to send =
data over
a transport together<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp; constitute a connection, even if the =
underlying
transport eschews the<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp; concept of a =
connection.&quot;<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The current charter or the requirements are not =
discussing any
requirements from the transport protocol.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>So far I thought that the media may be delivered =
using UDP
therefore I think that we need to address this issue if we want to have =
NFS 4.1
as a candidate solution adding the requirement for TCP =
support.<o:p></o:p></p>

<p class=3DMsoNormal>I can see the value in the reliability and in-order =
and believe
that since the data will not be stored using RTP we can look at using =
TCP. <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Roni Even<o:p></o:p></p>

</div>

</body>

</html>

--Boundary_(ID_9k0k9h0Q6oYB+iDGE8UHVg)--

From richard_woundy@cable.comcast.com  Thu Jun  3 12:32:43 2010
Return-Path: <richard_woundy@cable.comcast.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D863A68AD for <decade@core3.amsl.com>; Thu,  3 Jun 2010 12:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.863
X-Spam-Level: 
X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pff-LhbhAqzD for <decade@core3.amsl.com>; Thu,  3 Jun 2010 12:32:41 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 91FA03A69C7 for <decade@ietf.org>; Thu,  3 Jun 2010 12:32:40 -0700 (PDT)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.81985991; Thu, 03 Jun 2010 15:31:21 -0400
Received: from PACDCEXCSMTP04.cable.comcast.com (24.40.15.118) by PACDCEXHUB02.cable.comcast.com (24.40.55.41) with Microsoft SMTP Server id 14.0.694.0; Thu, 3 Jun 2010 15:31:20 -0400
Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Jun 2010 15:30:52 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 3 Jun 2010 15:30:08 -0400
Message-ID: <EE00404438E9444D90AEA84210DC4067E6C091@pacdcexcmb05.cable.comcast.com>
In-Reply-To: <000001cb016a$bcebeb10$36c3c130$@com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [decade] Authentication with OAuth?
Thread-Index: AcsBarU6dswbHMjuSGmy+Lor8rmYsQB51/2A
References: <000001cb016a$bcebeb10$36c3c130$@com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: Song Haibin <melodysong@huawei.com>, <decade@ietf.org>
X-OriginalArrivalTime: 03 Jun 2010 19:30:52.0464 (UTC) FILETIME=[475D0B00:01CB0353]
Subject: Re: [decade] Authentication with OAuth?
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2010 19:32:43 -0000

(Taking off my co-chair hat.)

Certainly OAuth has been part of the thinking in DECADE so far.

<http://tools.ietf.org/html/draft-song-decade-survey-03#section-8>
<http://www.ietf.org/proceedings/77/slides/decade-5.pdf>

My perception is that OAuth could be used to authorize resources such as
bandwidth and priority.

I wonder if OAuth is as applicable for a NFS 4.1 solution as it would be
for a WebDAV solution?

-- Rich

-----Original Message-----
From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf
Of Song Haibin
Sent: Tuesday, June 01, 2010 5:14 AM
To: decade@ietf.org
Subject: [decade] Authentication with OAuth?

One possible authentication method for DECADE might be reusing OAuth.
I'm
not sure whether OAuth can fit well here. Can existing OAuth be used to
authorize bandwidth or priority to the requester? I'm not sure whether
we
need the unauthorized request token step in DECADE context.

Thanks,
Haibin <as contributor>


_______________________________________________
decade mailing list
decade@ietf.org
https://www.ietf.org/mailman/listinfo/decade

From alan@peerapp.com  Thu Jun  3 12:51:28 2010
Return-Path: <alan@peerapp.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3553A68E6 for <decade@core3.amsl.com>; Thu,  3 Jun 2010 12:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.866
X-Spam-Level: 
X-Spam-Status: No, score=0.866 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQvn3peotb9B for <decade@core3.amsl.com>; Thu,  3 Jun 2010 12:51:27 -0700 (PDT)
Received: from peerapp.com (ded758-win-170-58.netsonic.net [66.180.170.58]) by core3.amsl.com (Postfix) with ESMTP id 8C50A3A6895 for <decade@ietf.org>; Thu,  3 Jun 2010 12:51:27 -0700 (PDT)
Received: from exchange.PEERAPP.com ([212.150.66.66]) by peerapp.com (8.14.1/8.14.1/SuSE Linux 0.8) with ESMTP id o53KHnmX025217; Thu, 3 Jun 2010 15:17:52 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0354.B9F00396"
Date: Thu, 3 Jun 2010 22:41:14 +0300
Content-Transfer-Encoding: 7bit
Message-ID: <C0F65127F7AB4E499577BD642FAE749102307B9A@exchange.PEERAPP.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [decade] Authentication with OAuth?
Thread-index: AcsBarU6dswbHMjuSGmy+Lor8rmYsQB51/2AAACpI/E=
From: "Alan Arolovitch" <alan@peerapp.com>
Importance: normal
Priority: normal
To: <Richard_Woundy@cable.comcast.com>, <melodysong@huawei.com>, <decade@ietf.org>
Subject: Re: [decade] Authentication with OAuth?
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2010 19:51:28 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB0354.B9F00396
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

K
--------------------------
Sent using BlackBerry



=20
-------------------------------------------------------------------------=
-
This e-mail Contains PeerApp Proprietary and Confidential information.
=20
=20
-------------------------------------------------------------------------=
-
-----Original Message-----
From: decade-bounces@ietf.org <decade-bounces@ietf.org>
To: Song Haibin <melodysong@huawei.com>; decade@ietf.org =
<decade@ietf.org>
Sent: Thu Jun 03 22:30:08 2010
Subject: Re: [decade] Authentication with OAuth?

(Taking off my co-chair hat.)

Certainly OAuth has been part of the thinking in DECADE so far.

<http://tools.ietf.org/html/draft-song-decade-survey-03#section-8>
<http://www.ietf.org/proceedings/77/slides/decade-5.pdf>

My perception is that OAuth could be used to authorize resources such as
bandwidth and priority.

I wonder if OAuth is as applicable for a NFS 4.1 solution as it would be
for a WebDAV solution?

-- Rich

-----Original Message-----
From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf
Of Song Haibin
Sent: Tuesday, June 01, 2010 5:14 AM
To: decade@ietf.org
Subject: [decade] Authentication with OAuth?

One possible authentication method for DECADE might be reusing OAuth.
I'm
not sure whether OAuth can fit well here. Can existing OAuth be used to
authorize bandwidth or priority to the requester? I'm not sure whether
we
need the unauthorized request token step in DECADE context.

Thanks,
Haibin <as contributor>


_______________________________________________
decade mailing list
decade@ietf.org
https://www.ietf.org/mailman/listinfo/decade
_______________________________________________
decade mailing list
decade@ietf.org
https://www.ietf.org/mailman/listinfo/decade

*************************************************************************=
********************



------_=_NextPart_001_01CB0354.B9F00396
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><!DOCTYPE HTML PUBLIC =
"-//W3C//DTD HTML 3.2//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML =
3.2//EN"><HTML><head><META content=3D"text/html; charset=3Dutf-8" =
http-equiv=3D"Content-Type">

<STYLE><!--         /* Style Definitions */         =
p.e5071c99-848e-4d11-be41-c32cd6ccab83, =
li.e5071c99-848e-4d11-be41-c32cd6ccab83, =
div.e5071c99-848e-4d11-be41-c32cd6ccab83, =
table.e5071c99-848e-4d11-be41-c32cd6ccab83Table	        {margin:0cm;	=
margin-bottom:.0001pt;}        div.Section1        {page:Section1;}      =
  --></STYLE>

<META content=3D"text/html; charset=3Dutf-8" =
HTTP-EQUIV=3D"Content-Type">
<META CONTENT=3D"MS Exchange Server version 6.5.7655.10" =
NAME=3D"Generator">
<TITLE>Re: [decade] Authentication with OAuth?</TITLE>
</head><BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>K<BR>
--------------------------<BR>
Sent using BlackBerry<BR>
<BR>
<BR>
</FONT></P>=20
<P CLASS=3D"e5071c99-848e-4d11-be41-c32cd6ccab83">&nbsp;</P>
<P>
<HR>
<SPAN STYLE=3D"FONT-WEIGHT: bold; FONT-SIZE: 11pt; COLOR: #1f497d; =
FONT-FAMILY: Calibri">This e-mail Contains PeerApp Proprietary and =
Confidential information.</SPAN>=20
<P CLASS=3D"e5071c99-848e-4d11-be41-c32cd6ccab83"><SPAN =
STYLE=3D"FONT-WEIGHT: bold; FONT-SIZE: 11pt; COLOR: #1f497d; =
FONT-FAMILY: Calibri"></SPAN>&nbsp;</P>
<P CLASS=3D"e5071c99-848e-4d11-be41-c32cd6ccab83"><SPAN =
STYLE=3D"FONT-WEIGHT: bold; FONT-SIZE: 11pt; COLOR: #1f497d; =
FONT-FAMILY: Calibri"></SPAN>&nbsp;</P>
<HR>
<P><FONT SIZE=3D2>-----Original Message-----</FONT></P><P><FONT =
SIZE=3D2><BR>
From: decade-bounces@ietf.org &lt;decade-bounces@ietf.org&gt;<BR>
To: Song Haibin &lt;melodysong@huawei.com&gt;; decade@ietf.org =
&lt;decade@ietf.org&gt;<BR>
Sent: Thu Jun 03 22:30:08 2010<BR>
Subject: Re: [decade] Authentication with OAuth?<BR>
<BR>
(Taking off my co-chair hat.)<BR>
<BR>
Certainly OAuth has been part of the thinking in DECADE so far.<BR>
<BR>
&lt;<A =
HREF=3D"http://tools.ietf.org/html/draft-song-decade-survey-03#section-8"=
>http://tools.ietf.org/html/draft-song-decade-survey-03#section-8</A>&gt;=
<BR>
&lt;<A =
HREF=3D"http://www.ietf.org/proceedings/77/slides/decade-5.pdf">http://ww=
w.ietf.org/proceedings/77/slides/decade-5.pdf</A>&gt;<BR>
<BR>
My perception is that OAuth could be used to authorize resources such =
as<BR>
bandwidth and priority.<BR>
<BR>
I wonder if OAuth is as applicable for a NFS 4.1 solution as it would =
be<BR>
for a WebDAV solution?<BR>
<BR>
-- Rich<BR>
<BR>
-----Original Message-----<BR>
From: decade-bounces@ietf.org [<A =
HREF=3D"mailto:decade-bounces@ietf.org">mailto:decade-bounces@ietf.org</A=
>] On Behalf<BR>
Of Song Haibin<BR>
Sent: Tuesday, June 01, 2010 5:14 AM<BR>
To: decade@ietf.org<BR>
Subject: [decade] Authentication with OAuth?<BR>
<BR>
One possible authentication method for DECADE might be reusing =
OAuth.<BR>
I'm<BR>
not sure whether OAuth can fit well here. Can existing OAuth be used =
to<BR>
authorize bandwidth or priority to the requester? I'm not sure =
whether<BR>
we<BR>
need the unauthorized request token step in DECADE context.<BR>
<BR>
Thanks,<BR>
Haibin &lt;as contributor&gt;<BR>
<BR>
<BR>
_______________________________________________<BR>
decade mailing list<BR>
decade@ietf.org<BR>
<A =
HREF=3D"https://www.ietf.org/mailman/listinfo/decade">https://www.ietf.or=
g/mailman/listinfo/decade</A><BR>
_______________________________________________<BR>
decade mailing list<BR>
decade@ietf.org<BR>
<A =
HREF=3D"https://www.ietf.org/mailman/listinfo/decade">https://www.ietf.or=
g/mailman/listinfo/decade</A><BR>
<BR>
*************************************************************************=
********************<BR>
<BR>
<BR>
</FONT>
</P>

=20
<P></P></P></BODY></HTML>

------_=_NextPart_001_01CB0354.B9F00396--

From ove.strandberg@nsn.com  Fri Jun  4 00:14:48 2010
Return-Path: <ove.strandberg@nsn.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003133A6A26 for <decade@core3.amsl.com>; Fri,  4 Jun 2010 00:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjYRg8xugMgK for <decade@core3.amsl.com>; Fri,  4 Jun 2010 00:14:46 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 4FB793A6A2A for <decade@ietf.org>; Fri,  4 Jun 2010 00:14:44 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o547EST3027134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <decade@ietf.org>; Fri, 4 Jun 2010 09:14:28 +0200
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o547EOsJ028024 for <decade@ietf.org>; Fri, 4 Jun 2010 09:14:27 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 4 Jun 2010 09:14:11 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB03B5.882926AB"
Date: Fri, 4 Jun 2010 10:14:11 +0300
Message-ID: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Merge requirements documents?
Thread-Index: AcsDtYexSQ0Cv06zSgGdbDwQ0fMWEg==
From: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
To: <decade@ietf.org>
X-OriginalArrivalTime: 04 Jun 2010 07:14:11.0667 (UTC) FILETIME=[880C6A30:01CB03B5]
Subject: [decade] Merge requirements documents?
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2010 07:14:48 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB03B5.882926AB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Decade email list,

There were additional requirements identified for Decade that was
presented and discussed in the Anaheim IETF meeting (see minutes in
http://www.ietf.org/proceedings/10mar/minutes/decade.html). We
basically brought some few additional requirements to complement the
already nice requirement list in draft-gu-decade-reqs-04. The authors of
the draft-ohlman-decade-add-use-cases-reqs-00 draft would like to
suggest that the additional requirements could be incorporated into one=20
requirement document, albeit into the draft-gu-decade-reqs-04 draft. The
two first requirements "application agnostic" and "data reuse" seemed to
be well received, while the "mobility" requirement needs further
discussion. What do the authors of draft-gu-decade-reqs-04 think about
this merge proposal?

We would like to also ask the DECADE email list to make comments on the
suggestion to combine both drafts into one document. Is this an
acceptable way forward?

Br,

+Ove

ove.strandberg@nsn.com


------_=_NextPart_001_01CB03B5.882926AB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7654.12">
<TITLE>Merge requirements documents?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Courier New">Dear Decade email list,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">There were additional =
requirements identified for Decade that was presented and discussed in =
the Anaheim IETF meeting (see minutes in </FONT><A =
HREF=3D"http://www.ietf.org/proceedings/10mar/minutes/decade.html"><U><FO=
NT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.ietf.org/proceedings/10mar/minutes/decade.html</FONT></U>=
</A><FONT SIZE=3D2 FACE=3D"Courier New">). We&nbsp; basically brought =
some few additional requirements to complement the already nice =
requirement list in draft-gu-decade-reqs-04. The authors of the =
draft-ohlman-decade-add-use-cases-reqs-00 draft would like to suggest =
that the additional requirements could be incorporated into one =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">requirement document, albeit into =
the draft-gu-decade-reqs-04 draft. The two first requirements =
&quot;application agnostic&quot; and &quot;data reuse&quot; seemed to be =
well received, while the &quot;mobility&quot; requirement needs further =
discussion. What do the authors of draft-gu-decade-reqs-04 think about =
this merge proposal?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">We would like to also ask the =
DECADE email list to make comments on the suggestion to combine both =
drafts into one document. Is this an acceptable way forward?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Br,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">+Ove</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ove.strandberg@nsn.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01CB03B5.882926AB--

From melodysong@huawei.com  Mon Jun  7 08:46:26 2010
Return-Path: <melodysong@huawei.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA2728C529 for <decade@core3.amsl.com>; Mon,  7 Jun 2010 08:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN9p+XkPrFsY for <decade@core3.amsl.com>; Mon,  7 Jun 2010 08:46:24 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 40E3D28C214 for <decade@ietf.org>; Sun,  6 Jun 2010 20:40:47 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3M00BJHKVLCH@szxga01-in.huawei.com> for decade@ietf.org; Mon, 07 Jun 2010 11:40:33 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3M00I6FKVL9M@szxga01-in.huawei.com> for decade@ietf.org; Mon, 07 Jun 2010 11:40:33 +0800 (CST)
Received: from s64081a ([10.138.84.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3M008CZKVI8H@szxml04-in.huawei.com> for decade@ietf.org; Mon, 07 Jun 2010 11:40:33 +0800 (CST)
Date: Mon, 07 Jun 2010 11:40:29 +0800
From: Song Haibin <melodysong@huawei.com>
To: decade@ietf.org
Message-id: <00d301cb05f3$2d19d2d0$874d7870$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=UTF-8
Content-language: zh-cn
Content-transfer-encoding: 7BIT
Thread-index: AcsDViovXx7aan3DRoWXa4l+YxKapwCnORmg
Subject: [decade] FW: IETF 78 - Meeting and Sponsorship Information
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jun 2010 15:46:26 -0000

Xie Xie,
Haibin
> -----Original Message-----
> From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On
> Behalf Of IETF Secretariat
> Sent: Friday, June 04, 2010 3:52 AM
> To: Working Group Chairs
> Subject: IETF 78 - Meeting and Sponsorship Information
> 
> Working Group Chairs,
> 
> Can you please forward this message to your individual working group
> emails lists.  We want to ensure that as many people as possible are aware
> of the sponsorship opportunities available at IETF meetings.
> 
> Thank you.
> ==========================================
> 78th IETF Meeting
> Maastricht, Netherlands
> July 25-30, 2010
> 
> 1. Sponsorship Opportunities
> 2. Registration Types
> 3. Visas and Letters of Invitation
> 4. Accommodations & Breakfast Information
> 5. IETF 79 (Beijing) Visa Information
> 
> 1) Sponsorship Opportunities
> There are still sponsorship opportunities and benefits for high profile
> company/organizational exposure at the upcoming IETF meeting in
> Maastricht, Netherlands from July 25-30, 2010.  All sponsorship fees go
> directly to fund the operations of the IETF.  See the options at:
> http://www.ietf.org/meeting/78/index.html Sponsorship Opportunities
> under General.  Each of the sponsorship options provide extended and
> repeat exposure at this weeklong meeting.
> 
> Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions
> and/or to reserve your organizations spot.  Thanks in advance for
> supporting the critical work of the IETF!
> 
> 2) Register online at:  http://www.ietf.org/meetings/78/
> 
> 3) Letters of Invitation and Visas
> Letters of Invitation
> After you complete the meeting registration process, you will be given the
> option to request a letter of invitation. You can request the Letter of
> Invitation as soon as you finish registration, or at a later time by
> following the link provided in the confirmation email.
> 
> Visas
> Please check the Netherlands Ministry of Foreign Affairs site
> (http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of
> countries with visa exemptions.
> 
> We recommend you give yourself at least one month to complete the visa
> process.
> 
> 4) Accommodations & Breakfast Information
> http://www.ietf.org/meeting/78/hotel.html
> 
> 5) If you want to start planning for your trip to IETF 79 in Beijing, we
> have visa information online here:
> http://www.ietf.org/meeting/79/visa.html
> 
> Only 52 days until IETF 78!




From davidbryan@gmail.com  Mon Jun  7 12:58:06 2010
Return-Path: <davidbryan@gmail.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E863A67C0 for <decade@core3.amsl.com>; Mon,  7 Jun 2010 12:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Level: 
X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lARr7dTGcsQt for <decade@core3.amsl.com>; Mon,  7 Jun 2010 12:58:05 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 0E9693A683A for <decade@ietf.org>; Mon,  7 Jun 2010 12:58:01 -0700 (PDT)
Received: by yxt33 with SMTP id 33so777007yxt.31 for <decade@ietf.org>; Mon, 07 Jun 2010 12:58:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=EoqDzSaHX8hiNNunkM3gyGj+FRoKw/eWkCi67I0hAwc=; b=jvqOpzK6Xi8kx2w/0ibsgHZz4l+BcuKUvib5VfNeKindOWthGI677AU+YDnYorOPvR zX8c94Tv5VrYq04oXc+e/ZLMwWVMH0mAPnq9qz97Rc06X6p32hHiS4ywhuvQc5pj1xcM WZSVe34fIzTJpmFVcyLP6N7eibOTB9WBGy65g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=axJPEmsi+VWM+Q8J3IAUw6M2TRSmft/2PfaFvbL7T6Ir951R7tE0FbV6rEIN36AUH0 DObifgT5LrCKsoFnUOu9oRVF419X3x2vRBK47fPg0XWocVc6o3h/6F8cVbB9IKrVi639 JOaQEqN6nXMJXba/RuryPrOpnmCjJvOn1MSfI=
MIME-Version: 1.0
Received: by 10.150.183.11 with SMTP id g11mr14369797ybf.66.1275940679527;  Mon, 07 Jun 2010 12:57:59 -0700 (PDT)
Sender: davidbryan@gmail.com
Received: by 10.151.51.7 with HTTP; Mon, 7 Jun 2010 12:57:59 -0700 (PDT)
In-Reply-To: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net>
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net>
Date: Mon, 7 Jun 2010 15:57:59 -0400
X-Google-Sender-Auth: xnORMjugU7ppjP_ldQWgWn1QKxQ
Message-ID: <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com>
From: "David A. Bryan" <dbryan@ethernot.org>
To: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: decade@ietf.org
Subject: Re: [decade] Merge requirements documents?
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jun 2010 19:58:06 -0000

I actually remember things a bit differently at the meeting, with my
general sense being that there wasn't broad support for most of the
new requirements. At least for now (perhaps I don't understand the
rational fully), I personally don't see a need to include any of them,
with the exception of application agnostic (in the modified form
below, which isn't a requirement but a guiding principal).

I think that the mobility requirement needed more discussion -- most
folks seemed to feel that it was a bit too complex for now, and
personally, I didn't really understand the problem this would address.
A very simplistic description of the major chartered use case of
DECADE is to allow a peer to make things available in-network so that
others can obtain it without having to use the link to the peer
itself. In my view, it isn't intended to be generic storage for the
user to place things that they want to be able to access easily
themselves. While having storage near me topologically might reduce
the cost of putting it in the data locker in the first place, I don't
really see how mobility is very critical when the major purpose is to
allow me to place something in the network for someone else to obtain.
I may just not quite understand what you are advocating -- can you
clarify a use case where we need this for the main P2P application?

Data reuse is something that I simply see as an implementation issue.
Obviously, a given implementation might choose to compare copies of
data that it is storing and to consolidate them, but from a
protocol/network perspective, I think we are adding complexity if we
track versions, number of copies stored, who has shared which access
rights, etc. -- so much so that it seems unlikely to justify the cost.
My preference would be that a user has access to their locker, and can
place things in it, provide references to it, etc., but that each
user's data -- at least from the perspective of the protocol -- is
unique and managed by them. Again, as I said, that wouldn't preclude
an implementation from making this optimization, I just don't see
requirement/protocol design as the right place for it.

Finally, my take on the application technique issue at the meeting was
this: In P2PSIP, we tried a "do no harm" approach. The protocol for
P2PSIP (RELOAD) is essentially a DHT protocol. The protocol is
optimized for use in SIP registration/location, and we agreed that we
wouldn't add unnecessary complexity that wasn't needed by that one
application. That said, we have tried very hard (and deliberately) to
make sure that so long as it didn't increase complexity, that we
thought about other applications and tried not to design RELOAD in a
way that would preclude use for other applications. I'd like a similar
approach here -- we deliberately design for the single application of
storing information for P2P applications, but if others can point out
other applications that dictate a design decision and (critically)
which do not add complexity/require new features, we try to make
design decisions that allow that flexibility when possible. I see this
as quite different from adding different application scenarios and
requiring that the protocol support all of them -- that is, in my
opinion, likely to make this problem too broad and increase the
difficulty of designing a protocol.

David


On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN - FI/Espoo)
<ove.strandberg@nsn.com> wrote:
> Dear Decade email list,
>
> There were additional requirements identified for Decade that was present=
ed
> and discussed in the Anaheim IETF meeting (see minutes in
> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We=A0 basical=
ly
> brought some few additional requirements to complement the already nice
> requirement list in draft-gu-decade-reqs-04. The authors of the
> draft-ohlman-decade-add-use-cases-reqs-00 draft would like to suggest tha=
t
> the additional requirements could be incorporated into one
>
> requirement document, albeit into the draft-gu-decade-reqs-04 draft. The =
two
> first requirements "application agnostic" and "data reuse" seemed to be w=
ell
> received, while the "mobility" requirement needs further discussion. What=
 do
> the authors of draft-gu-decade-reqs-04 think about this merge proposal?
>
> We would like to also ask the DECADE email list to make comments on the
> suggestion to combine both drafts into one document. Is this an acceptabl=
e
> way forward?
>
> Br,
>
> +Ove
>
> ove.strandberg@nsn.com
>
> _______________________________________________
> decade mailing list
> decade@ietf.org
> https://www.ietf.org/mailman/listinfo/decade
>
>

From davidbryan@gmail.com  Mon Jun  7 13:10:56 2010
Return-Path: <davidbryan@gmail.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC433A6855 for <decade@core3.amsl.com>; Mon,  7 Jun 2010 13:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Level: 
X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9u3LXrI-qvu for <decade@core3.amsl.com>; Mon,  7 Jun 2010 13:10:55 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DEFAB3A6852 for <decade@ietf.org>; Mon,  7 Jun 2010 13:10:54 -0700 (PDT)
Received: by gyh4 with SMTP id 4so2665549gyh.31 for <decade@ietf.org>; Mon, 07 Jun 2010 13:10:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=25cNa3GUnw2B7W6tdkN5AP1N3AR9FPtveCJTScGlbCQ=; b=XyCwj0ttk8FZQ/JFMRn1VJxOdc1H0A+55lP9H+dc8Sm1hB4tNfo+omAVynSQm0mCFg YlDfjItTmoq7foYRhxzvAOlOphr3YQ3fvEgYi9+2YtVX01YGXnBh/mdAFeVYd5WruYVw GoDvFr4Uy6v52jXCvE5u1ZGkBmycBkmQlg6lI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OQcMVNuUChsHP1cdLrjnYWSb7iiHWSSB0vJE8xjQqxLO21qHBeUL8Omlrh35A5sQmH EQC8C9omKWUqJ/+7d8EIUefu/mSwbHDi7EFgYVvruZ0431hs76pTm1zaGW576A1hDBxr k+Ut+SQ4hnJIcYCNh5hUU+WAdT19p/Y+Ra60I=
MIME-Version: 1.0
Received: by 10.151.28.14 with SMTP id f14mr13769119ybj.398.1275941452305;  Mon, 07 Jun 2010 13:10:52 -0700 (PDT)
Sender: davidbryan@gmail.com
Received: by 10.151.51.7 with HTTP; Mon, 7 Jun 2010 13:10:51 -0700 (PDT)
In-Reply-To: <026801cb01d3$328511e0$978f35a0$%roni@huawei.com>
References: <AcsB0yiqTKlwUn2MQ2OZxoXGL2wFnw==> <026801cb01d3$328511e0$978f35a0$%roni@huawei.com>
Date: Mon, 7 Jun 2010 16:10:51 -0400
X-Google-Sender-Auth: gnF13js0HZRBApTATz-MdPOnB6g
Message-ID: <AANLkTilUZCsWqTjVsltCtl7f0wCD-097lqR398U_TyMS@mail.gmail.com>
From: "David A. Bryan" <dbryan@ethernot.org>
To: Roni Even <Even.roni@huawei.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: decade@ietf.org
Subject: Re: [decade] Using NFS 4.1 in DECADE
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jun 2010 20:10:56 -0000

I think this is a great point. I also had originally thought that
there may be some contexts where UDP might be used (the charter talks
about P2P streaming as well as P2P file sharing in the first
sentence). If we really want to allow a user to stream data from the
data locker, that might mean we need RTP as a possible transport that
DECADE supports, which might mean we need UDP. To be honest, my
thoughts around DECADE had been more about the offline storage use
case, but I'm not sure what others have thought, and the charter seems
to imply there are some folks who want to stream from the in-network
storage.

Love to hear what others think about this...

David

On Tue, Jun 1, 2010 at 5:41 PM, Roni Even <Even.roni@huawei.com> wrote:
> Hi,
>
> NFS 4.1 section 2.9 discuss the transport layer and has some requirements
> from the transport which are not part of NFS 4.1 or RPC.
>
>
>
> The following statement is part of the section
>
>
>
> " It is permissible for a connectionless transport to be used under
>
> =A0=A0 NFSv4.1; however, reliable and in-order delivery of data combined
>
> =A0=A0 with congestion control by the connectionless transport is REQUIRE=
D.
>
> =A0=A0 As a consequence, UDP by itself MUST NOT be used as an NFSv4.1
>
> =A0=A0 transport.=A0 NFSv4.1 assumes that a client transport address and
>
> =A0=A0 server transport address used to send data over a transport togeth=
er
>
> =A0=A0 constitute a connection, even if the underlying transport eschews =
the
>
> =A0=A0 concept of a connection."
>
>
>
> The current charter or the requirements are not discussing any requiremen=
ts
> from the transport protocol.
>
>
>
> So far I thought that the media may be delivered using UDP therefore I th=
ink
> that we need to address this issue if we want to have NFS 4.1 as a candid=
ate
> solution adding the requirement for TCP support.
>
> I can see the value in the reliability and in-order and believe that sinc=
e
> the data will not be stored using RTP we can look at using TCP.
>
>
>
> Roni Even
>
> _______________________________________________
> decade mailing list
> decade@ietf.org
> https://www.ietf.org/mailman/listinfo/decade
>
>

From Even.roni@huawei.com  Tue Jun  8 00:57:36 2010
Return-Path: <Even.roni@huawei.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A6028C102 for <decade@core3.amsl.com>; Tue,  8 Jun 2010 00:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.105
X-Spam-Level: **
X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZLIHslzYGcP for <decade@core3.amsl.com>; Tue,  8 Jun 2010 00:57:35 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 2B88C28C0FA for <decade@ietf.org>; Tue,  8 Jun 2010 00:57:35 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3O00J4URCCVG@szxga01-in.huawei.com> for decade@ietf.org; Tue, 08 Jun 2010 15:55:25 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3O00CBHRCCZI@szxga01-in.huawei.com> for decade@ietf.org; Tue, 08 Jun 2010 15:55:24 +0800 (CST)
Received: from windows8d787f9 (bzq-79-179-9-222.red.bezeqint.net [79.179.9.222]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0L3O00GQ7RBQ4H@szxml02-in.huawei.com>; Tue, 08 Jun 2010 15:55:24 +0800 (CST)
Date: Tue, 08 Jun 2010 10:52:47 +0300
From: Roni Even <Even.roni@huawei.com>
In-reply-to: <AANLkTilUZCsWqTjVsltCtl7f0wCD-097lqR398U_TyMS@mail.gmail.com>
To: "'David A. Bryan'" <dbryan@ethernot.org>
Message-id: <05c301cb06df$a160f230$e422d690$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=windows-1255
Content-language: en-us
Content-transfer-encoding: quoted-printable
Thread-index: AcsGfYkJjtjxPnGsQHWVIeJhWshrlgAYZpXQ
References: <AcsB0yiqTKlwUn2MQ2OZxoXGL2wFnw==@huawei.com> <026801cb01d3$328511e0$978f35a0$%roni@huawei.com> <AANLkTilUZCsWqTjVsltCtl7f0wCD-097lqR398U_TyMS@mail.gmail.com>
Cc: decade@ietf.org
Subject: Re: [decade] Using NFS 4.1 in DECADE
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2010 07:57:36 -0000

Hi,
As another input, RTSP specifies support for RTP on UDP and also on TCP
based on RFC 4571.
Roni Even

> -----Original Message-----
> From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On Behalf Of
> David A. Bryan
> Sent: Monday, June 07, 2010 11:11 PM
> To: Roni Even
> Cc: decade@ietf.org
> Subject: Re: [decade] Using NFS 4.1 in DECADE
>=20
> I think this is a great point. I also had originally thought that
> there may be some contexts where UDP might be used (the charter talks
> about P2P streaming as well as P2P file sharing in the first
> sentence). If we really want to allow a user to stream data from the
> data locker, that might mean we need RTP as a possible transport that
> DECADE supports, which might mean we need UDP. To be honest, my
> thoughts around DECADE had been more about the offline storage use
> case, but I'm not sure what others have thought, and the charter seems
> to imply there are some folks who want to stream from the in-network
> storage.
>=20
> Love to hear what others think about this...
>=20
> David
>=20
> On Tue, Jun 1, 2010 at 5:41 PM, Roni Even <Even.roni@huawei.com> =
wrote:
> > Hi,
> >
> > NFS 4.1 section 2.9 discuss the transport layer and has some
> requirements
> > from the transport which are not part of NFS 4.1 or RPC.
> >
> >
> >
> > The following statement is part of the section
> >
> >
> >
> > " It is permissible for a connectionless transport to be used under
> >
> > =A0=A0 NFSv4.1; however, reliable and in-order delivery of data =
combined
> >
> > =A0=A0 with congestion control by the connectionless transport is
> REQUIRED.
> >
> > =A0=A0 As a consequence, UDP by itself MUST NOT be used as an =
NFSv4.1
> >
> > =A0=A0 transport.=A0 NFSv4.1 assumes that a client transport address =
and
> >
> > =A0=A0 server transport address used to send data over a transport
> together
> >
> > =A0=A0 constitute a connection, even if the underlying transport =
eschews
> the
> >
> > =A0=A0 concept of a connection."
> >
> >
> >
> > The current charter or the requirements are not discussing any
> requirements
> > from the transport protocol.
> >
> >
> >
> > So far I thought that the media may be delivered using UDP therefore
> I think
> > that we need to address this issue if we want to have NFS 4.1 as a
> candidate
> > solution adding the requirement for TCP support.
> >
> > I can see the value in the reliability and in-order and believe that
> since
> > the data will not be stored using RTP we can look at using TCP.
> >
> >
> >
> > Roni Even
> >
> > _______________________________________________
> > decade mailing list
> > decade@ietf.org
> > https://www.ietf.org/mailman/listinfo/decade
> >
> >


From ove.strandberg@nsn.com  Thu Jun 10 01:32:48 2010
Return-Path: <ove.strandberg@nsn.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4FE3A6927 for <decade@core3.amsl.com>; Thu, 10 Jun 2010 01:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZd09Zvl9Jb8 for <decade@core3.amsl.com>; Thu, 10 Jun 2010 01:32:43 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 48FE43A6908 for <decade@ietf.org>; Thu, 10 Jun 2010 01:32:42 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5A8Wb4Y021263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Jun 2010 10:32:37 +0200
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5A8WasS005470; Thu, 10 Jun 2010 10:32:36 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 10 Jun 2010 10:32:36 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Jun 2010 11:32:35 +0300
Message-ID: <AC126D9A37B1EF4DAE0A39C02E94E64702B308BD@FIESEXC015.nsn-intra.net>
In-Reply-To: <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Mobility req
Thread-Index: AcsGe7z0DMzHZGy9QwSe+T5+sGgTHAB+cgXg
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net> <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com>
From: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
To: "ext David A. Bryan" <dbryan@ethernot.org>
X-OriginalArrivalTime: 10 Jun 2010 08:32:36.0175 (UTC) FILETIME=[7AA1DDF0:01CB0877]
Cc: decade@ietf.org
Subject: [decade] Mobility req
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jun 2010 08:32:48 -0000

Hi David,

Thanks for your comments! Let's here look at the most intresting case; =
mobility requirement ;-)

The mobility requirement is not necessary a complex issue, but of course =
it depends on the viewer. If you want a complex solution you clearly can =
get a complex solution.

My personal issue is the sense of clients that move about, they are =
mobile. In case the used network storage / cache through time gets =
somewhat far off, then it would be beneficial for the client to be able =
to access a storage/cache closer. So in essence the main and most basic =
mobility aspect would be the efficient support for a mobile client to be =
able to access local caches instead of being forced to have a big =
backhaul to original cache.=20

This now my personal motivation for mobile requirement, I hope this can =
be seen as an acceptable reasoning and shared with you others too. In =
case you agree on the potential concern, then we might look more at how =
to specify the requirement. Is this a good way forward?

Br,

+Ove

>-----Original Message-----
>From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On=20
>Behalf Of ext David A. Bryan
>Sent: 07 June, 2010 22:58
>To: Strandberg, Ove (NSN - FI/Espoo)
>Cc: decade@ietf.org
>Subject: Re: [decade] Merge requirements documents?
>
>I actually remember things a bit differently at the meeting,=20
>with my general sense being that there wasn't broad support=20
>for most of the new requirements. At least for now (perhaps I=20
>don't understand the rational fully), I personally don't see a=20
>need to include any of them, with the exception of application=20
>agnostic (in the modified form below, which isn't a=20
>requirement but a guiding principal).
>
>I think that the mobility requirement needed more discussion=20
>-- most folks seemed to feel that it was a bit too complex for=20
>now, and personally, I didn't really understand the problem=20
>this would address.
>A very simplistic description of the major chartered use case=20
>of DECADE is to allow a peer to make things available=20
>in-network so that others can obtain it without having to use=20
>the link to the peer itself. In my view, it isn't intended to=20
>be generic storage for the user to place things that they want=20
>to be able to access easily themselves. While having storage=20
>near me topologically might reduce the cost of putting it in=20
>the data locker in the first place, I don't really see how=20
>mobility is very critical when the major purpose is to allow=20
>me to place something in the network for someone else to obtain.
>I may just not quite understand what you are advocating -- can=20
>you clarify a use case where we need this for the main P2P application?
>
>Data reuse is something that I simply see as an implementation issue.
>Obviously, a given implementation might choose to compare=20
>copies of data that it is storing and to consolidate them, but=20
>from a protocol/network perspective, I think we are adding=20
>complexity if we track versions, number of copies stored, who=20
>has shared which access rights, etc. -- so much so that it=20
>seems unlikely to justify the cost.
>My preference would be that a user has access to their locker,=20
>and can place things in it, provide references to it, etc.,=20
>but that each user's data -- at least from the perspective of=20
>the protocol -- is unique and managed by them. Again, as I=20
>said, that wouldn't preclude an implementation from making=20
>this optimization, I just don't see requirement/protocol=20
>design as the right place for it.
>
>Finally, my take on the application technique issue at the meeting was
>this: In P2PSIP, we tried a "do no harm" approach. The=20
>protocol for P2PSIP (RELOAD) is essentially a DHT protocol.=20
>The protocol is optimized for use in SIP=20
>registration/location, and we agreed that we wouldn't add=20
>unnecessary complexity that wasn't needed by that one=20
>application. That said, we have tried very hard (and=20
>deliberately) to make sure that so long as it didn't increase=20
>complexity, that we thought about other applications and tried=20
>not to design RELOAD in a way that would preclude use for=20
>other applications. I'd like a similar approach here -- we=20
>deliberately design for the single application of storing=20
>information for P2P applications, but if others can point out=20
>other applications that dictate a design decision and=20
>(critically) which do not add complexity/require new features,=20
>we try to make design decisions that allow that flexibility=20
>when possible. I see this as quite different from adding=20
>different application scenarios and requiring that the=20
>protocol support all of them -- that is, in my opinion, likely=20
>to make this problem too broad and increase the difficulty of=20
>designing a protocol.
>
>David
>
>
>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN -=20
>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>> Dear Decade email list,
>>
>> There were additional requirements identified for Decade that was=20
>> presented and discussed in the Anaheim IETF meeting (see minutes in=20
>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We=A0=20
>> basically brought some few additional requirements to complement the=20
>> already nice requirement list in draft-gu-decade-reqs-04.=20
>The authors=20
>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft would like to=20
>> suggest that the additional requirements could be incorporated into=20
>> one
>>
>> requirement document, albeit into the draft-gu-decade-reqs-04 draft.=20
>> The two first requirements "application agnostic" and "data reuse"=20
>> seemed to be well received, while the "mobility" requirement needs=20
>> further discussion. What do the authors of=20
>draft-gu-decade-reqs-04 think about this merge proposal?
>>
>> We would like to also ask the DECADE email list to make comments on=20
>> the suggestion to combine both drafts into one document. Is this an=20
>> acceptable way forward?
>>
>> Br,
>>
>> +Ove
>>
>> ove.strandberg@nsn.com
>>
>> _______________________________________________
>> decade mailing list
>> decade@ietf.org
>> https://www.ietf.org/mailman/listinfo/decade
>>
>>
>

From richard.alimi@gmail.com  Thu Jun 10 06:53:52 2010
Return-Path: <richard.alimi@gmail.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF4828C0F5 for <decade@core3.amsl.com>; Thu, 10 Jun 2010 06:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.437
X-Spam-Level: 
X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGH4TIsHABkS for <decade@core3.amsl.com>; Thu, 10 Jun 2010 06:53:51 -0700 (PDT)
Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 03A8028C0F4 for <decade@ietf.org>; Thu, 10 Jun 2010 06:53:50 -0700 (PDT)
Received: by ewy24 with SMTP id 24so1976187ewy.14 for <decade@ietf.org>; Thu, 10 Jun 2010 06:53:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=PUckIzRg+thknTozudnaXVmxxNVCzKVsTIiuLZHkQmM=; b=aowYbOBj492rW6ju7T30HNxNRtMAGJykFgKIbTiSqcSBVSrmDC3HurxnScg+dJVupV ezdf8tKb4AF/e4IpTem7s4Tjyp/b0LISPgRXgVQ5CwoFG3spJWswtOPZzC4H/sMSFEvi 3Xux9ERGo77iHukJcQcm9Lb2J8ZNScXbTmm7k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ilnWnaEHsJ7xmKsNO+KuSXng5jCVEVb/q+nL0BNY7ZZ5gG8wkCDhCJJBTMfq3cMXwA bhyr1R/GMNhoomnWq5i8wUTSyY59nGpFp+PeOoSwR0eYRgFatYiDS6oMk/C+hSpATNwb uQ232J1DLX5xL+fG94wBNTolPKt48KgDida4g=
MIME-Version: 1.0
Received: by 10.216.184.136 with SMTP id s8mr352274wem.4.1276178028678; Thu,  10 Jun 2010 06:53:48 -0700 (PDT)
Sender: richard.alimi@gmail.com
Received: by 10.216.166.21 with HTTP; Thu, 10 Jun 2010 06:53:48 -0700 (PDT)
In-Reply-To: <AC126D9A37B1EF4DAE0A39C02E94E64702B308BD@FIESEXC015.nsn-intra.net>
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net> <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B308BD@FIESEXC015.nsn-intra.net>
Date: Thu, 10 Jun 2010 09:53:48 -0400
X-Google-Sender-Auth: D3XkGTUhY8az0PLkB4oT1xMTMDw
Message-ID: <AANLkTilo__sCzqv5f3k7z-SZDFkRVfPAhoXcbvoSxiEo@mail.gmail.com>
From: Richard Alimi <richard.alimi@yale.edu>
To: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: decade@ietf.org
Subject: Re: [decade] Mobility req
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jun 2010 13:53:52 -0000

Hi Ove,

On Thu, Jun 10, 2010 at 4:32 AM, Strandberg, Ove (NSN - FI/Espoo)
<ove.strandberg@nsn.com> wrote:
> Hi David,
>
> Thanks for your comments! Let's here look at the most intresting case; mo=
bility requirement ;-)
>
> The mobility requirement is not necessary a complex issue, but of course =
it depends on the viewer. If you want a complex solution you clearly can ge=
t a complex solution.
>
> My personal issue is the sense of clients that move about, they are mobil=
e. In case the used network storage / cache through time gets somewhat far =
off, then it would be beneficial for the client to be able to access a stor=
age/cache closer. So in essence the main and most basic mobility aspect wou=
ld be the efficient support for a mobile client to be able to access local =
caches instead of being forced to have a big backhaul to original cache.

If there are multiple storage locations available to a client, I think
it is reasonable to let the client choose which to use.  See my reply
to B=F6rje Ohlman from the previous charter discussion:
  http://www.ietf.org/mail-archive/web/decade/current/msg00149.html

However, note that we must not overlap with ALTO.  Note the explicit
out-of-scope item in the DECADE charter:
  Locating the "best" in-network storage location from which to retrieve
  content if there are more than one location can provide the same
  content.

>
> This now my personal motivation for mobile requirement, I hope this can b=
e seen as an acceptable reasoning and shared with you others too. In case y=
ou agree on the potential concern, then we might look more at how to specif=
y the requirement. Is this a good way forward?

I think this is fine.

Rich

>
> Br,
>
> +Ove
>
>>-----Original Message-----
>>From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On
>>Behalf Of ext David A. Bryan
>>Sent: 07 June, 2010 22:58
>>To: Strandberg, Ove (NSN - FI/Espoo)
>>Cc: decade@ietf.org
>>Subject: Re: [decade] Merge requirements documents?
>>
>>I actually remember things a bit differently at the meeting,
>>with my general sense being that there wasn't broad support
>>for most of the new requirements. At least for now (perhaps I
>>don't understand the rational fully), I personally don't see a
>>need to include any of them, with the exception of application
>>agnostic (in the modified form below, which isn't a
>>requirement but a guiding principal).
>>
>>I think that the mobility requirement needed more discussion
>>-- most folks seemed to feel that it was a bit too complex for
>>now, and personally, I didn't really understand the problem
>>this would address.
>>A very simplistic description of the major chartered use case
>>of DECADE is to allow a peer to make things available
>>in-network so that others can obtain it without having to use
>>the link to the peer itself. In my view, it isn't intended to
>>be generic storage for the user to place things that they want
>>to be able to access easily themselves. While having storage
>>near me topologically might reduce the cost of putting it in
>>the data locker in the first place, I don't really see how
>>mobility is very critical when the major purpose is to allow
>>me to place something in the network for someone else to obtain.
>>I may just not quite understand what you are advocating -- can
>>you clarify a use case where we need this for the main P2P application?
>>
>>Data reuse is something that I simply see as an implementation issue.
>>Obviously, a given implementation might choose to compare
>>copies of data that it is storing and to consolidate them, but
>>from a protocol/network perspective, I think we are adding
>>complexity if we track versions, number of copies stored, who
>>has shared which access rights, etc. -- so much so that it
>>seems unlikely to justify the cost.
>>My preference would be that a user has access to their locker,
>>and can place things in it, provide references to it, etc.,
>>but that each user's data -- at least from the perspective of
>>the protocol -- is unique and managed by them. Again, as I
>>said, that wouldn't preclude an implementation from making
>>this optimization, I just don't see requirement/protocol
>>design as the right place for it.
>>
>>Finally, my take on the application technique issue at the meeting was
>>this: In P2PSIP, we tried a "do no harm" approach. The
>>protocol for P2PSIP (RELOAD) is essentially a DHT protocol.
>>The protocol is optimized for use in SIP
>>registration/location, and we agreed that we wouldn't add
>>unnecessary complexity that wasn't needed by that one
>>application. That said, we have tried very hard (and
>>deliberately) to make sure that so long as it didn't increase
>>complexity, that we thought about other applications and tried
>>not to design RELOAD in a way that would preclude use for
>>other applications. I'd like a similar approach here -- we
>>deliberately design for the single application of storing
>>information for P2P applications, but if others can point out
>>other applications that dictate a design decision and
>>(critically) which do not add complexity/require new features,
>>we try to make design decisions that allow that flexibility
>>when possible. I see this as quite different from adding
>>different application scenarios and requiring that the
>>protocol support all of them -- that is, in my opinion, likely
>>to make this problem too broad and increase the difficulty of
>>designing a protocol.
>>
>>David
>>
>>
>>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN -
>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>> Dear Decade email list,
>>>
>>> There were additional requirements identified for Decade that was
>>> presented and discussed in the Anaheim IETF meeting (see minutes in
>>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We
>>> basically brought some few additional requirements to complement the
>>> already nice requirement list in draft-gu-decade-reqs-04.
>>The authors
>>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft would like to
>>> suggest that the additional requirements could be incorporated into
>>> one
>>>
>>> requirement document, albeit into the draft-gu-decade-reqs-04 draft.
>>> The two first requirements "application agnostic" and "data reuse"
>>> seemed to be well received, while the "mobility" requirement needs
>>> further discussion. What do the authors of
>>draft-gu-decade-reqs-04 think about this merge proposal?
>>>
>>> We would like to also ask the DECADE email list to make comments on
>>> the suggestion to combine both drafts into one document. Is this an
>>> acceptable way forward?
>>>
>>> Br,
>>>
>>> +Ove
>>>
>>> ove.strandberg@nsn.com
>>>
>>> _______________________________________________
>>> decade mailing list
>>> decade@ietf.org
>>> https://www.ietf.org/mailman/listinfo/decade
>>>
>>>
>>
> _______________________________________________
> decade mailing list
> decade@ietf.org
> https://www.ietf.org/mailman/listinfo/decade
>

From ove.strandberg@nsn.com  Thu Jun 10 22:23:01 2010
Return-Path: <ove.strandberg@nsn.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4C328C128 for <decade@core3.amsl.com>; Thu, 10 Jun 2010 22:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyJTmVmCVrJk for <decade@core3.amsl.com>; Thu, 10 Jun 2010 22:22:58 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 38A8428C127 for <decade@ietf.org>; Thu, 10 Jun 2010 22:22:58 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5B5MqaW026774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Jun 2010 07:22:52 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5B5Mpk2011713; Fri, 11 Jun 2010 07:22:52 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 11 Jun 2010 07:22:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 11 Jun 2010 08:22:50 +0300
Message-ID: <AC126D9A37B1EF4DAE0A39C02E94E64702B657FE@FIESEXC015.nsn-intra.net>
In-Reply-To: <AANLkTilo__sCzqv5f3k7z-SZDFkRVfPAhoXcbvoSxiEo@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [decade] Mobility req
Thread-Index: AcsIpFxpkOu7BR//Q2ui1HUOEh497wAgJk8g
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net><AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com><AC126D9A37B1EF4DAE0A39C02E94E64702B308BD@FIESEXC015.nsn-intra.net> <AANLkTilo__sCzqv5f3k7z-SZDFkRVfPAhoXcbvoSxiEo@mail.gmail.com>
From: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
To: "ext Richard Alimi" <richard.alimi@yale.edu>
X-OriginalArrivalTime: 11 Jun 2010 05:22:51.0817 (UTC) FILETIME=[23707190:01CB0926]
Cc: decade@ietf.org
Subject: Re: [decade] Mobility req
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 05:23:01 -0000

Hi Rich,

Looking at the message you refer to, I can see that we agree on the =
basis for the mob req. We probably will be able to cope with the use of =
some of the basic requirements for mob req too.=20

There are however one additional characteristic that comes with =
mobility; the switch over to use a local storage/cache needs to work =
fast enough for a mobile client. I am not going to specify numbers, but =
let's say the client is working against a far away storage/cache. For =
the client to think that a local storage/access is better, then the =
switchover should not produce delay of several seconds (guessimate, not =
hard number, just illustrate the point). If the switchover has too long =
delay, then it would probably be better to continue working against the =
far away storage/cache.

Br,

+Ove  =20

>-----Original Message-----
>From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com]=20
>On Behalf Of ext Richard Alimi
>Sent: 10 June, 2010 16:54
>To: Strandberg, Ove (NSN - FI/Espoo)
>Cc: ext David A. Bryan; decade@ietf.org
>Subject: Re: [decade] Mobility req
>
>Hi Ove,
>
>On Thu, Jun 10, 2010 at 4:32 AM, Strandberg, Ove (NSN -=20
>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>> Hi David,
>>
>> Thanks for your comments! Let's here look at the most=20
>intresting case;=20
>> mobility requirement ;-)
>>
>> The mobility requirement is not necessary a complex issue,=20
>but of course it depends on the viewer. If you want a complex=20
>solution you clearly can get a complex solution.
>>
>> My personal issue is the sense of clients that move about,=20
>they are mobile. In case the used network storage / cache=20
>through time gets somewhat far off, then it would be=20
>beneficial for the client to be able to access a storage/cache=20
>closer. So in essence the main and most basic mobility aspect=20
>would be the efficient support for a mobile client to be able=20
>to access local caches instead of being forced to have a big=20
>backhaul to original cache.
>
>If there are multiple storage locations available to a client,=20
>I think it is reasonable to let the client choose which to=20
>use.  See my reply to B=F6rje Ohlman from the previous charter=20
>discussion:
>  http://www.ietf.org/mail-archive/web/decade/current/msg00149.html
>
>However, note that we must not overlap with ALTO.  Note the=20
>explicit out-of-scope item in the DECADE charter:
>  Locating the "best" in-network storage location from which=20
>to retrieve
>  content if there are more than one location can provide the same
>  content.
>
>>
>> This now my personal motivation for mobile requirement, I=20
>hope this can be seen as an acceptable reasoning and shared=20
>with you others too. In case you agree on the potential=20
>concern, then we might look more at how to specify the=20
>requirement. Is this a good way forward?
>
>I think this is fine.
>
>Rich
>
>>
>> Br,
>>
>> +Ove
>>
>>>-----Original Message-----
>>>From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On=20
>Behalf Of=20
>>>ext David A. Bryan
>>>Sent: 07 June, 2010 22:58
>>>To: Strandberg, Ove (NSN - FI/Espoo)
>>>Cc: decade@ietf.org
>>>Subject: Re: [decade] Merge requirements documents?
>>>
>>>I actually remember things a bit differently at the meeting, with my=20
>>>general sense being that there wasn't broad support for most of the=20
>>>new requirements. At least for now (perhaps I don't understand the=20
>>>rational fully), I personally don't see a need to include=20
>any of them,=20
>>>with the exception of application agnostic (in the modified form=20
>>>below, which isn't a requirement but a guiding principal).
>>>
>>>I think that the mobility requirement needed more discussion
>>>-- most folks seemed to feel that it was a bit too complex for now,=20
>>>and personally, I didn't really understand the problem this would=20
>>>address.
>>>A very simplistic description of the major chartered use case of=20
>>>DECADE is to allow a peer to make things available=20
>in-network so that=20
>>>others can obtain it without having to use the link to the peer=20
>>>itself. In my view, it isn't intended to be generic storage for the=20
>>>user to place things that they want to be able to access easily=20
>>>themselves. While having storage near me topologically might reduce=20
>>>the cost of putting it in the data locker in the first=20
>place, I don't=20
>>>really see how mobility is very critical when the major=20
>purpose is to=20
>>>allow me to place something in the network for someone else=20
>to obtain.
>>>I may just not quite understand what you are advocating -- can you=20
>>>clarify a use case where we need this for the main P2P application?
>>>
>>>Data reuse is something that I simply see as an implementation issue.
>>>Obviously, a given implementation might choose to compare copies of=20
>>>data that it is storing and to consolidate them, but from a=20
>>>protocol/network perspective, I think we are adding complexity if we=20
>>>track versions, number of copies stored, who has shared which access=20
>>>rights, etc. -- so much so that it seems unlikely to justify=20
>the cost.
>>>My preference would be that a user has access to their=20
>locker, and can=20
>>>place things in it, provide references to it, etc., but that each=20
>>>user's data -- at least from the perspective of the protocol -- is=20
>>>unique and managed by them. Again, as I said, that wouldn't preclude=20
>>>an implementation from making this optimization, I just don't see=20
>>>requirement/protocol design as the right place for it.
>>>
>>>Finally, my take on the application technique issue at the=20
>meeting was
>>>this: In P2PSIP, we tried a "do no harm" approach. The protocol for=20
>>>P2PSIP (RELOAD) is essentially a DHT protocol.
>>>The protocol is optimized for use in SIP=20
>registration/location, and we=20
>>>agreed that we wouldn't add unnecessary complexity that=20
>wasn't needed=20
>>>by that one application. That said, we have tried very hard (and
>>>deliberately) to make sure that so long as it didn't increase=20
>>>complexity, that we thought about other applications and=20
>tried not to=20
>>>design RELOAD in a way that would preclude use for other=20
>applications.=20
>>>I'd like a similar approach here -- we deliberately design for the=20
>>>single application of storing information for P2P=20
>applications, but if=20
>>>others can point out other applications that dictate a=20
>design decision=20
>>>and
>>>(critically) which do not add complexity/require new=20
>features, we try=20
>>>to make design decisions that allow that flexibility when=20
>possible. I=20
>>>see this as quite different from adding different application=20
>>>scenarios and requiring that the protocol support all of=20
>them -- that=20
>>>is, in my opinion, likely to make this problem too broad and=20
>increase=20
>>>the difficulty of designing a protocol.
>>>
>>>David
>>>
>>>
>>>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN -
>>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>>> Dear Decade email list,
>>>>
>>>> There were additional requirements identified for Decade that was=20
>>>> presented and discussed in the Anaheim IETF meeting (see=20
>minutes in=20
>>>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We=20
>>>> basically brought some few additional requirements to=20
>complement the=20
>>>> already nice requirement list in draft-gu-decade-reqs-04.
>>>The authors
>>>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft=20
>would like to=20
>>>> suggest that the additional requirements could be=20
>incorporated into=20
>>>> one
>>>>
>>>> requirement document, albeit into the=20
>draft-gu-decade-reqs-04 draft.
>>>> The two first requirements "application agnostic" and "data reuse"
>>>> seemed to be well received, while the "mobility" requirement needs=20
>>>> further discussion. What do the authors of
>>>draft-gu-decade-reqs-04 think about this merge proposal?
>>>>
>>>> We would like to also ask the DECADE email list to make=20
>comments on=20
>>>> the suggestion to combine both drafts into one document.=20
>Is this an=20
>>>> acceptable way forward?
>>>>
>>>> Br,
>>>>
>>>> +Ove
>>>>
>>>> ove.strandberg@nsn.com
>>>>
>>>> _______________________________________________
>>>> decade mailing list
>>>> decade@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/decade
>>>>
>>>>
>>>
>> _______________________________________________
>> decade mailing list
>> decade@ietf.org
>> https://www.ietf.org/mailman/listinfo/decade
>>
>

From richard.alimi@gmail.com  Thu Jun 10 22:34:54 2010
Return-Path: <richard.alimi@gmail.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948A83A67B2 for <decade@core3.amsl.com>; Thu, 10 Jun 2010 22:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.91
X-Spam-Level: *
X-Spam-Status: No, score=1.91 tagged_above=-999 required=5 tests=[AWL=3.887, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-xLSI8rAoGL for <decade@core3.amsl.com>; Thu, 10 Jun 2010 22:34:53 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id D77B83A68B0 for <decade@ietf.org>; Thu, 10 Jun 2010 22:34:52 -0700 (PDT)
Received: by wwc33 with SMTP id 33so445821wwc.31 for <decade@ietf.org>; Thu, 10 Jun 2010 22:34:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=NiD+1sVk8E/DkDZ/zVtP23U18HpmLOWW6hV9txuwAmA=; b=DFse5cfgLJjWXt7kyXeWz2k2XCZjSIyKgIkESKK3ikSO6LZUGOHoI2WRWwkdjKCkoV 4RbDcpr83xGINrOvh1MoFG9PxhLQMN2L3ODmJiOyRL1l9xbZ1jWIxCVv7r3+aYNUDJeO flKNq0AypCLTS5WsVvL8TRzYmJkl9dPgeJiGo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=o9uR8sYPZVNfn+q0xbkRZWUe9cEu39Llazzqid2JZhEXJk3ewRrmU6LLoYWInwkPSn wpzVoHsiExHhtSQVcjxRj2hfkUuOgDKDps8oA9D2Uo3JEllbV6L1rG0JHm9Wyz0L1cJ5 boHgM3ksGTtBuoyaufjigbgUB/vtkxiFFHCOs=
MIME-Version: 1.0
Received: by 10.216.180.198 with SMTP id j48mr608551wem.108.1276234491306;  Thu, 10 Jun 2010 22:34:51 -0700 (PDT)
Sender: richard.alimi@gmail.com
Received: by 10.216.166.21 with HTTP; Thu, 10 Jun 2010 22:34:50 -0700 (PDT)
In-Reply-To: <AC126D9A37B1EF4DAE0A39C02E94E64702B657FE@FIESEXC015.nsn-intra.net>
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net> <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B308BD@FIESEXC015.nsn-intra.net> <AANLkTilo__sCzqv5f3k7z-SZDFkRVfPAhoXcbvoSxiEo@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B657FE@FIESEXC015.nsn-intra.net>
Date: Fri, 11 Jun 2010 01:34:50 -0400
X-Google-Sender-Auth: KtcuoSWDE3bRbaXMXVxivbpXO9g
Message-ID: <AANLkTilk_YKrzu46-b3a6Vtsa0q6LBqsrmvezLRrcSGY@mail.gmail.com>
From: Richard Alimi <richard.alimi@yale.edu>
To: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: decade@ietf.org
Subject: Re: [decade] Mobility req
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 05:34:54 -0000

Hi Ove,

On Fri, Jun 11, 2010 at 1:22 AM, Strandberg, Ove (NSN - FI/Espoo)
<ove.strandberg@nsn.com> wrote:
> Hi Rich,
>
> Looking at the message you refer to, I can see that we agree on the basis=
 for the mob req.

If it is as simple as being able to discover multiple servers, then I
think that can be useful and will not add complexity to the protocol.
Of course, this does *not* mean that a DECADE client must have access
to multiple servers.  I would envision that to depend on the
particular deployment.

> We probably will be able to cope with the use of some of the basic requir=
ements for mob req too.
>
> There are however one additional characteristic that comes with mobility;=
 the switch over to use a local storage/cache needs to work fast enough for=
 a mobile client. I am not going to specify numbers, but let's say the clie=
nt is working against a far away storage/cache. For the client to think tha=
t a local storage/access is better, then the switchover should not produce =
delay of several seconds (guessimate, not hard number, just illustrate the =
point). If the switchover has too long delay, then it would probably be bet=
ter to continue working against the far away storage/cache.

I'm unclear as to what you mean by "switchover" - can you provide some
more specifics?  What type of application are you envisioning, and
what specific operations do you intend to include in the "switchover"
process?

Rich

>
> Br,
>
> +Ove
>
>>-----Original Message-----
>>From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com]
>>On Behalf Of ext Richard Alimi
>>Sent: 10 June, 2010 16:54
>>To: Strandberg, Ove (NSN - FI/Espoo)
>>Cc: ext David A. Bryan; decade@ietf.org
>>Subject: Re: [decade] Mobility req
>>
>>Hi Ove,
>>
>>On Thu, Jun 10, 2010 at 4:32 AM, Strandberg, Ove (NSN -
>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>> Hi David,
>>>
>>> Thanks for your comments! Let's here look at the most
>>intresting case;
>>> mobility requirement ;-)
>>>
>>> The mobility requirement is not necessary a complex issue,
>>but of course it depends on the viewer. If you want a complex
>>solution you clearly can get a complex solution.
>>>
>>> My personal issue is the sense of clients that move about,
>>they are mobile. In case the used network storage / cache
>>through time gets somewhat far off, then it would be
>>beneficial for the client to be able to access a storage/cache
>>closer. So in essence the main and most basic mobility aspect
>>would be the efficient support for a mobile client to be able
>>to access local caches instead of being forced to have a big
>>backhaul to original cache.
>>
>>If there are multiple storage locations available to a client,
>>I think it is reasonable to let the client choose which to
>>use. =A0See my reply to B=F6rje Ohlman from the previous charter
>>discussion:
>> =A0http://www.ietf.org/mail-archive/web/decade/current/msg00149.html
>>
>>However, note that we must not overlap with ALTO. =A0Note the
>>explicit out-of-scope item in the DECADE charter:
>> =A0Locating the "best" in-network storage location from which
>>to retrieve
>> =A0content if there are more than one location can provide the same
>> =A0content.
>>
>>>
>>> This now my personal motivation for mobile requirement, I
>>hope this can be seen as an acceptable reasoning and shared
>>with you others too. In case you agree on the potential
>>concern, then we might look more at how to specify the
>>requirement. Is this a good way forward?
>>
>>I think this is fine.
>>
>>Rich
>>
>>>
>>> Br,
>>>
>>> +Ove
>>>
>>>>-----Original Message-----
>>>>From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On
>>Behalf Of
>>>>ext David A. Bryan
>>>>Sent: 07 June, 2010 22:58
>>>>To: Strandberg, Ove (NSN - FI/Espoo)
>>>>Cc: decade@ietf.org
>>>>Subject: Re: [decade] Merge requirements documents?
>>>>
>>>>I actually remember things a bit differently at the meeting, with my
>>>>general sense being that there wasn't broad support for most of the
>>>>new requirements. At least for now (perhaps I don't understand the
>>>>rational fully), I personally don't see a need to include
>>any of them,
>>>>with the exception of application agnostic (in the modified form
>>>>below, which isn't a requirement but a guiding principal).
>>>>
>>>>I think that the mobility requirement needed more discussion
>>>>-- most folks seemed to feel that it was a bit too complex for now,
>>>>and personally, I didn't really understand the problem this would
>>>>address.
>>>>A very simplistic description of the major chartered use case of
>>>>DECADE is to allow a peer to make things available
>>in-network so that
>>>>others can obtain it without having to use the link to the peer
>>>>itself. In my view, it isn't intended to be generic storage for the
>>>>user to place things that they want to be able to access easily
>>>>themselves. While having storage near me topologically might reduce
>>>>the cost of putting it in the data locker in the first
>>place, I don't
>>>>really see how mobility is very critical when the major
>>purpose is to
>>>>allow me to place something in the network for someone else
>>to obtain.
>>>>I may just not quite understand what you are advocating -- can you
>>>>clarify a use case where we need this for the main P2P application?
>>>>
>>>>Data reuse is something that I simply see as an implementation issue.
>>>>Obviously, a given implementation might choose to compare copies of
>>>>data that it is storing and to consolidate them, but from a
>>>>protocol/network perspective, I think we are adding complexity if we
>>>>track versions, number of copies stored, who has shared which access
>>>>rights, etc. -- so much so that it seems unlikely to justify
>>the cost.
>>>>My preference would be that a user has access to their
>>locker, and can
>>>>place things in it, provide references to it, etc., but that each
>>>>user's data -- at least from the perspective of the protocol -- is
>>>>unique and managed by them. Again, as I said, that wouldn't preclude
>>>>an implementation from making this optimization, I just don't see
>>>>requirement/protocol design as the right place for it.
>>>>
>>>>Finally, my take on the application technique issue at the
>>meeting was
>>>>this: In P2PSIP, we tried a "do no harm" approach. The protocol for
>>>>P2PSIP (RELOAD) is essentially a DHT protocol.
>>>>The protocol is optimized for use in SIP
>>registration/location, and we
>>>>agreed that we wouldn't add unnecessary complexity that
>>wasn't needed
>>>>by that one application. That said, we have tried very hard (and
>>>>deliberately) to make sure that so long as it didn't increase
>>>>complexity, that we thought about other applications and
>>tried not to
>>>>design RELOAD in a way that would preclude use for other
>>applications.
>>>>I'd like a similar approach here -- we deliberately design for the
>>>>single application of storing information for P2P
>>applications, but if
>>>>others can point out other applications that dictate a
>>design decision
>>>>and
>>>>(critically) which do not add complexity/require new
>>features, we try
>>>>to make design decisions that allow that flexibility when
>>possible. I
>>>>see this as quite different from adding different application
>>>>scenarios and requiring that the protocol support all of
>>them -- that
>>>>is, in my opinion, likely to make this problem too broad and
>>increase
>>>>the difficulty of designing a protocol.
>>>>
>>>>David
>>>>
>>>>
>>>>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN -
>>>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>>>> Dear Decade email list,
>>>>>
>>>>> There were additional requirements identified for Decade that was
>>>>> presented and discussed in the Anaheim IETF meeting (see
>>minutes in
>>>>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We
>>>>> basically brought some few additional requirements to
>>complement the
>>>>> already nice requirement list in draft-gu-decade-reqs-04.
>>>>The authors
>>>>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft
>>would like to
>>>>> suggest that the additional requirements could be
>>incorporated into
>>>>> one
>>>>>
>>>>> requirement document, albeit into the
>>draft-gu-decade-reqs-04 draft.
>>>>> The two first requirements "application agnostic" and "data reuse"
>>>>> seemed to be well received, while the "mobility" requirement needs
>>>>> further discussion. What do the authors of
>>>>draft-gu-decade-reqs-04 think about this merge proposal?
>>>>>
>>>>> We would like to also ask the DECADE email list to make
>>comments on
>>>>> the suggestion to combine both drafts into one document.
>>Is this an
>>>>> acceptable way forward?
>>>>>
>>>>> Br,
>>>>>
>>>>> +Ove
>>>>>
>>>>> ove.strandberg@nsn.com
>>>>>
>>>>> _______________________________________________
>>>>> decade mailing list
>>>>> decade@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/decade
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> decade mailing list
>>> decade@ietf.org
>>> https://www.ietf.org/mailman/listinfo/decade
>>>
>>
>

From ove.strandberg@nsn.com  Thu Jun 10 23:55:46 2010
Return-Path: <ove.strandberg@nsn.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BFB3A68BD for <decade@core3.amsl.com>; Thu, 10 Jun 2010 23:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg5Sld3EQwSa for <decade@core3.amsl.com>; Thu, 10 Jun 2010 23:55:45 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 15ED83A6885 for <decade@ietf.org>; Thu, 10 Jun 2010 23:55:43 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5B6tah9024153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Jun 2010 08:55:36 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5B6tXjf006879; Fri, 11 Jun 2010 08:55:36 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 11 Jun 2010 08:55:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 11 Jun 2010 09:55:08 +0300
Message-ID: <AC126D9A37B1EF4DAE0A39C02E94E64702B658B6@FIESEXC015.nsn-intra.net>
In-Reply-To: <AANLkTilk_YKrzu46-b3a6Vtsa0q6LBqsrmvezLRrcSGY@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [decade] Mobility req
Thread-Index: AcsJJ9G79bDWTtHrTtGnf0oRm/yGkwAClEkg
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net><AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com><AC126D9A37B1EF4DAE0A39C02E94E64702B308BD@FIESEXC015.nsn-intra.net><AANLkTilo__sCzqv5f3k7z-SZDFkRVfPAhoXcbvoSxiEo@mail.gmail.com><AC126D9A37B1EF4DAE0A39C02E94E64702B657FE@FIESEXC015.nsn-intra.net> <AANLkTilk_YKrzu46-b3a6Vtsa0q6LBqsrmvezLRrcSGY@mail.gmail.com>
From: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
To: "ext Richard Alimi" <richard.alimi@yale.edu>
X-OriginalArrivalTime: 11 Jun 2010 06:55:09.0530 (UTC) FILETIME=[082C63A0:01CB0933]
Cc: decade@ietf.org
Subject: Re: [decade] Mobility req
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 06:55:46 -0000

Hmm Rich,

I am uncertain of specifics here, just talkiung about requirements makes =
it hard to be too specific. But with switchover I simply mean the =
situation that at one point you are engaged as client in accessing data =
on the far away storage/cache, the next moment it would be possible to =
access a local storage/cache instead. For me as client it should not =
take too long to for me to start using the local storage/cache, thus =
there should not be too long delay between working on far away =
storage/cache to start working on local storage/cache.

This is quite straitforward explanaition and the most elementary version =
of mobility. In case someone has more stricter wiew on mobility, you =
need to speak up.

Br,

+Ove

>-----Original Message-----
>From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com]=20
>On Behalf Of ext Richard Alimi
>Sent: 11 June, 2010 08:35
>To: Strandberg, Ove (NSN - FI/Espoo)
>Cc: ext David A. Bryan; decade@ietf.org
>Subject: Re: [decade] Mobility req
>
>Hi Ove,
>
>On Fri, Jun 11, 2010 at 1:22 AM, Strandberg, Ove (NSN -=20
>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>> Hi Rich,
>>
>> Looking at the message you refer to, I can see that we agree=20
>on the basis for the mob req.
>
>If it is as simple as being able to discover multiple servers,=20
>then I think that can be useful and will not add complexity to=20
>the protocol.
>Of course, this does *not* mean that a DECADE client must have=20
>access to multiple servers.  I would envision that to depend=20
>on the particular deployment.
>
>> We probably will be able to cope with the use of some of the=20
>basic requirements for mob req too.
>>
>> There are however one additional characteristic that comes=20
>with mobility; the switch over to use a local storage/cache=20
>needs to work fast enough for a mobile client. I am not going=20
>to specify numbers, but let's say the client is working=20
>against a far away storage/cache. For the client to think that=20
>a local storage/access is better, then the switchover should=20
>not produce delay of several seconds (guessimate, not hard=20
>number, just illustrate the point). If the switchover has too=20
>long delay, then it would probably be better to continue=20
>working against the far away storage/cache.
>
>I'm unclear as to what you mean by "switchover" - can you=20
>provide some more specifics?  What type of application are you=20
>envisioning, and what specific operations do you intend to=20
>include in the "switchover"
>process?
>
>Rich
>
>>
>> Br,
>>
>> +Ove
>>
>>>-----Original Message-----
>>>From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On=20
>>>Behalf Of ext Richard Alimi
>>>Sent: 10 June, 2010 16:54
>>>To: Strandberg, Ove (NSN - FI/Espoo)
>>>Cc: ext David A. Bryan; decade@ietf.org
>>>Subject: Re: [decade] Mobility req
>>>
>>>Hi Ove,
>>>
>>>On Thu, Jun 10, 2010 at 4:32 AM, Strandberg, Ove (NSN -
>>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>>> Hi David,
>>>>
>>>> Thanks for your comments! Let's here look at the most
>>>intresting case;
>>>> mobility requirement ;-)
>>>>
>>>> The mobility requirement is not necessary a complex issue,
>>>but of course it depends on the viewer. If you want a=20
>complex solution=20
>>>you clearly can get a complex solution.
>>>>
>>>> My personal issue is the sense of clients that move about,
>>>they are mobile. In case the used network storage / cache=20
>through time=20
>>>gets somewhat far off, then it would be beneficial for the client to=20
>>>be able to access a storage/cache closer. So in essence the main and=20
>>>most basic mobility aspect would be the efficient support=20
>for a mobile=20
>>>client to be able to access local caches instead of being forced to=20
>>>have a big backhaul to original cache.
>>>
>>>If there are multiple storage locations available to a=20
>client, I think=20
>>>it is reasonable to let the client choose which to use. =A0See=20
>my reply=20
>>>to B=F6rje Ohlman from the previous charter
>>>discussion:
>>> =A0http://www.ietf.org/mail-archive/web/decade/current/msg00149.html
>>>
>>>However, note that we must not overlap with ALTO. =A0Note the =
explicit=20
>>>out-of-scope item in the DECADE charter:
>>> =A0Locating the "best" in-network storage location from which to=20
>>>retrieve
>>> =A0content if there are more than one location can provide the same
>>> =A0content.
>>>
>>>>
>>>> This now my personal motivation for mobile requirement, I
>>>hope this can be seen as an acceptable reasoning and shared with you=20
>>>others too. In case you agree on the potential concern, then=20
>we might=20
>>>look more at how to specify the requirement. Is this a good way=20
>>>forward?
>>>
>>>I think this is fine.
>>>
>>>Rich
>>>
>>>>
>>>> Br,
>>>>
>>>> +Ove
>>>>
>>>>>-----Original Message-----
>>>>>From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On
>>>Behalf Of
>>>>>ext David A. Bryan
>>>>>Sent: 07 June, 2010 22:58
>>>>>To: Strandberg, Ove (NSN - FI/Espoo)
>>>>>Cc: decade@ietf.org
>>>>>Subject: Re: [decade] Merge requirements documents?
>>>>>
>>>>>I actually remember things a bit differently at the=20
>meeting, with my=20
>>>>>general sense being that there wasn't broad support for=20
>most of the=20
>>>>>new requirements. At least for now (perhaps I don't understand the=20
>>>>>rational fully), I personally don't see a need to include
>>>any of them,
>>>>>with the exception of application agnostic (in the modified form=20
>>>>>below, which isn't a requirement but a guiding principal).
>>>>>
>>>>>I think that the mobility requirement needed more discussion
>>>>>-- most folks seemed to feel that it was a bit too complex=20
>for now,=20
>>>>>and personally, I didn't really understand the problem this would=20
>>>>>address.
>>>>>A very simplistic description of the major chartered use case of=20
>>>>>DECADE is to allow a peer to make things available
>>>in-network so that
>>>>>others can obtain it without having to use the link to the peer=20
>>>>>itself. In my view, it isn't intended to be generic=20
>storage for the=20
>>>>>user to place things that they want to be able to access easily=20
>>>>>themselves. While having storage near me topologically=20
>might reduce=20
>>>>>the cost of putting it in the data locker in the first
>>>place, I don't
>>>>>really see how mobility is very critical when the major
>>>purpose is to
>>>>>allow me to place something in the network for someone else
>>>to obtain.
>>>>>I may just not quite understand what you are advocating -- can you=20
>>>>>clarify a use case where we need this for the main P2P application?
>>>>>
>>>>>Data reuse is something that I simply see as an=20
>implementation issue.
>>>>>Obviously, a given implementation might choose to compare=20
>copies of=20
>>>>>data that it is storing and to consolidate them, but from a=20
>>>>>protocol/network perspective, I think we are adding=20
>complexity if we=20
>>>>>track versions, number of copies stored, who has shared=20
>which access=20
>>>>>rights, etc. -- so much so that it seems unlikely to justify
>>>the cost.
>>>>>My preference would be that a user has access to their
>>>locker, and can
>>>>>place things in it, provide references to it, etc., but that each=20
>>>>>user's data -- at least from the perspective of the protocol -- is=20
>>>>>unique and managed by them. Again, as I said, that=20
>wouldn't preclude=20
>>>>>an implementation from making this optimization, I just don't see=20
>>>>>requirement/protocol design as the right place for it.
>>>>>
>>>>>Finally, my take on the application technique issue at the
>>>meeting was
>>>>>this: In P2PSIP, we tried a "do no harm" approach. The=20
>protocol for=20
>>>>>P2PSIP (RELOAD) is essentially a DHT protocol.
>>>>>The protocol is optimized for use in SIP
>>>registration/location, and we
>>>>>agreed that we wouldn't add unnecessary complexity that
>>>wasn't needed
>>>>>by that one application. That said, we have tried very hard (and
>>>>>deliberately) to make sure that so long as it didn't increase=20
>>>>>complexity, that we thought about other applications and
>>>tried not to
>>>>>design RELOAD in a way that would preclude use for other
>>>applications.
>>>>>I'd like a similar approach here -- we deliberately design for the=20
>>>>>single application of storing information for P2P
>>>applications, but if
>>>>>others can point out other applications that dictate a
>>>design decision
>>>>>and
>>>>>(critically) which do not add complexity/require new
>>>features, we try
>>>>>to make design decisions that allow that flexibility when
>>>possible. I
>>>>>see this as quite different from adding different application=20
>>>>>scenarios and requiring that the protocol support all of
>>>them -- that
>>>>>is, in my opinion, likely to make this problem too broad and
>>>increase
>>>>>the difficulty of designing a protocol.
>>>>>
>>>>>David
>>>>>
>>>>>
>>>>>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN -
>>>>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>>>>> Dear Decade email list,
>>>>>>
>>>>>> There were additional requirements identified for Decade=20
>that was=20
>>>>>> presented and discussed in the Anaheim IETF meeting (see
>>>minutes in
>>>>>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We=20
>>>>>> basically brought some few additional requirements to
>>>complement the
>>>>>> already nice requirement list in draft-gu-decade-reqs-04.
>>>>>The authors
>>>>>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft
>>>would like to
>>>>>> suggest that the additional requirements could be
>>>incorporated into
>>>>>> one
>>>>>>
>>>>>> requirement document, albeit into the
>>>draft-gu-decade-reqs-04 draft.
>>>>>> The two first requirements "application agnostic" and=20
>"data reuse"
>>>>>> seemed to be well received, while the "mobility"=20
>requirement needs=20
>>>>>> further discussion. What do the authors of
>>>>>draft-gu-decade-reqs-04 think about this merge proposal?
>>>>>>
>>>>>> We would like to also ask the DECADE email list to make
>>>comments on
>>>>>> the suggestion to combine both drafts into one document.
>>>Is this an
>>>>>> acceptable way forward?
>>>>>>
>>>>>> Br,
>>>>>>
>>>>>> +Ove
>>>>>>
>>>>>> ove.strandberg@nsn.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> decade mailing list
>>>>>> decade@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/decade
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> decade mailing list
>>>> decade@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/decade
>>>>
>>>
>>
>

From ove.strandberg@nsn.com  Fri Jun 11 00:47:27 2010
Return-Path: <ove.strandberg@nsn.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B61673A69D6 for <decade@core3.amsl.com>; Fri, 11 Jun 2010 00:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.988
X-Spam-Level: 
X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=0.122,  BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2e07Yv8OzKO for <decade@core3.amsl.com>; Fri, 11 Jun 2010 00:47:25 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id ECCB13A68B5 for <decade@ietf.org>; Fri, 11 Jun 2010 00:47:24 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5B7lEfi000752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Jun 2010 09:47:14 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5B7lCn5006220; Fri, 11 Jun 2010 09:47:13 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 11 Jun 2010 09:47:12 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 11 Jun 2010 10:47:11 +0300
Message-ID: <AC126D9A37B1EF4DAE0A39C02E94E64702B6594F@FIESEXC015.nsn-intra.net>
In-Reply-To: <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [decade] Merge requirements documents?
Thread-Index: AcsGe7z0DMzHZGy9QwSe+T5+sGgTHACvOXFg
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net> <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com>
From: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
To: "ext David A. Bryan" <dbryan@ethernot.org>
X-OriginalArrivalTime: 11 Jun 2010 07:47:12.0364 (UTC) FILETIME=[4D870AC0:01CB093A]
Cc: decade@ietf.org
Subject: Re: [decade] Merge requirements documents?
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 07:47:28 -0000

Hi David,

I think that one main reason for difference in opinion between us David =
is the basic approach and view of DECADE. You clearly think mostly about =
P2P application scenario. I on the other hand think that when we specify =
a protocol for network storage / cache (usually from an client =
perspective) we should make sure the same network storage / cache =
protocol can be used for other application scenarios too. I fully =
support the P2P scenario, but the effort to make the broader =
applicability possible, should be well worth spending. Basically it =
would IMHO be good for us to make the protocol more succeful. Agreed =
that the scope needs to be narrow enough, however if you like to look at =
P2P, I would be happy look after complementary scenarios ;-) However to =
be able to achieve this I hope that these additional requirements should =
be included. I am sure we will together make sure that we do not make =
complex recommendations in the end ;-)

Br,

+Ove

>-----Original Message-----
>From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On=20
>Behalf Of ext David A. Bryan
>Sent: 07 June, 2010 22:58
>To: Strandberg, Ove (NSN - FI/Espoo)
>Cc: decade@ietf.org
>Subject: Re: [decade] Merge requirements documents?
>
>I actually remember things a bit differently at the meeting,=20
>with my general sense being that there wasn't broad support=20
>for most of the new requirements. At least for now (perhaps I=20
>don't understand the rational fully), I personally don't see a=20
>need to include any of them, with the exception of application=20
>agnostic (in the modified form below, which isn't a=20
>requirement but a guiding principal).
>
>I think that the mobility requirement needed more discussion=20
>-- most folks seemed to feel that it was a bit too complex for=20
>now, and personally, I didn't really understand the problem=20
>this would address.
>A very simplistic description of the major chartered use case=20
>of DECADE is to allow a peer to make things available=20
>in-network so that others can obtain it without having to use=20
>the link to the peer itself. In my view, it isn't intended to=20
>be generic storage for the user to place things that they want=20
>to be able to access easily themselves. While having storage=20
>near me topologically might reduce the cost of putting it in=20
>the data locker in the first place, I don't really see how=20
>mobility is very critical when the major purpose is to allow=20
>me to place something in the network for someone else to obtain.
>I may just not quite understand what you are advocating -- can=20
>you clarify a use case where we need this for the main P2P application?
>
>Data reuse is something that I simply see as an implementation issue.
>Obviously, a given implementation might choose to compare=20
>copies of data that it is storing and to consolidate them, but=20
>from a protocol/network perspective, I think we are adding=20
>complexity if we track versions, number of copies stored, who=20
>has shared which access rights, etc. -- so much so that it=20
>seems unlikely to justify the cost.
>My preference would be that a user has access to their locker,=20
>and can place things in it, provide references to it, etc.,=20
>but that each user's data -- at least from the perspective of=20
>the protocol -- is unique and managed by them. Again, as I=20
>said, that wouldn't preclude an implementation from making=20
>this optimization, I just don't see requirement/protocol=20
>design as the right place for it.
>
>Finally, my take on the application technique issue at the meeting was
>this: In P2PSIP, we tried a "do no harm" approach. The=20
>protocol for P2PSIP (RELOAD) is essentially a DHT protocol.=20
>The protocol is optimized for use in SIP=20
>registration/location, and we agreed that we wouldn't add=20
>unnecessary complexity that wasn't needed by that one=20
>application. That said, we have tried very hard (and=20
>deliberately) to make sure that so long as it didn't increase=20
>complexity, that we thought about other applications and tried=20
>not to design RELOAD in a way that would preclude use for=20
>other applications. I'd like a similar approach here -- we=20
>deliberately design for the single application of storing=20
>information for P2P applications, but if others can point out=20
>other applications that dictate a design decision and=20
>(critically) which do not add complexity/require new features,=20
>we try to make design decisions that allow that flexibility=20
>when possible. I see this as quite different from adding=20
>different application scenarios and requiring that the=20
>protocol support all of them -- that is, in my opinion, likely=20
>to make this problem too broad and increase the difficulty of=20
>designing a protocol.
>
>David
>
>
>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN -=20
>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>> Dear Decade email list,
>>
>> There were additional requirements identified for Decade that was=20
>> presented and discussed in the Anaheim IETF meeting (see minutes in=20
>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We=A0=20
>> basically brought some few additional requirements to complement the=20
>> already nice requirement list in draft-gu-decade-reqs-04.=20
>The authors=20
>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft would like to=20
>> suggest that the additional requirements could be incorporated into=20
>> one
>>
>> requirement document, albeit into the draft-gu-decade-reqs-04 draft.=20
>> The two first requirements "application agnostic" and "data reuse"=20
>> seemed to be well received, while the "mobility" requirement needs=20
>> further discussion. What do the authors of=20
>draft-gu-decade-reqs-04 think about this merge proposal?
>>
>> We would like to also ask the DECADE email list to make comments on=20
>> the suggestion to combine both drafts into one document. Is this an=20
>> acceptable way forward?
>>
>> Br,
>>
>> +Ove
>>
>> ove.strandberg@nsn.com
>>
>> _______________________________________________
>> decade mailing list
>> decade@ietf.org
>> https://www.ietf.org/mailman/listinfo/decade
>>
>>
>

From richard.alimi@gmail.com  Fri Jun 11 05:47:14 2010
Return-Path: <richard.alimi@gmail.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0233F3A688D for <decade@core3.amsl.com>; Fri, 11 Jun 2010 05:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.614
X-Spam-Level: 
X-Spam-Status: No, score=0.614 tagged_above=-999 required=5 tests=[AWL=2.591,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIKeE-o-f3oS for <decade@core3.amsl.com>; Fri, 11 Jun 2010 05:47:12 -0700 (PDT)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id F2A803A657C for <decade@ietf.org>; Fri, 11 Jun 2010 05:47:11 -0700 (PDT)
Received: by ey-out-2122.google.com with SMTP id 22so152645eye.51 for <decade@ietf.org>; Fri, 11 Jun 2010 05:47:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=BYr+rAkahC0pyB6swbQTfnWUv6UTrzPy2VR2OVh0b88=; b=L+sDKw81m1nK1J/TbjG6FcgwiZZMgQcOWm1t+0vMb8WUvmEwwzYgS033137FEX+sxU Qn+wbxa2he+/SG7oaqrGv7SSKfBMv2XmiTcNNuc7N9EeYo72NS0oJKEo6oH1NdM8Nxrz ECeTYnH7rJVnAU0/jEJxf89ovFEmyNHPIW9n0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xnHpI5H0w7ZF9gqdC8nq09uhEB5ypYDY3UprpVHLkaDQGXVBN8tzGUX0MzR9R1Pus0 OvHgwYTKwYZiEoe7iZxnx+UaEg4/crZ9S3eb5Te04ivL5ZlqRFiRN1z+MQVYqHwxlHuQ pydc416ObeYxjQt0d9IKH+HqgvcgT37QhR0H0=
MIME-Version: 1.0
Received: by 10.216.169.211 with SMTP id n61mr911737wel.41.1276260430593; Fri,  11 Jun 2010 05:47:10 -0700 (PDT)
Sender: richard.alimi@gmail.com
Received: by 10.216.166.21 with HTTP; Fri, 11 Jun 2010 05:47:10 -0700 (PDT)
In-Reply-To: <AC126D9A37B1EF4DAE0A39C02E94E64702B658B6@FIESEXC015.nsn-intra.net>
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net> <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B308BD@FIESEXC015.nsn-intra.net> <AANLkTilo__sCzqv5f3k7z-SZDFkRVfPAhoXcbvoSxiEo@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B657FE@FIESEXC015.nsn-intra.net> <AANLkTilk_YKrzu46-b3a6Vtsa0q6LBqsrmvezLRrcSGY@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B658B6@FIESEXC015.nsn-intra.net>
Date: Fri, 11 Jun 2010 08:47:10 -0400
X-Google-Sender-Auth: 8DZOYKx8sUxPnnYDEe7oRCe65v8
Message-ID: <AANLkTilCcOrxDNTj4Xy47DH_MuEJNuzqv0CPf-3-A-EN@mail.gmail.com>
From: Richard Alimi <richard.alimi@yale.edu>
To: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: decade@ietf.org
Subject: Re: [decade] Mobility req
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 12:47:14 -0000

Hi Ove,

On Fri, Jun 11, 2010 at 2:55 AM, Strandberg, Ove (NSN - FI/Espoo)
<ove.strandberg@nsn.com> wrote:
> Hmm Rich,
>
> I am uncertain of specifics here, just talkiung about requirements makes =
it hard to be too specific. But with switchover I simply mean the situation=
 that at one point you are engaged as client in accessing data on the far a=
way storage/cache, the next moment it would be possible to access a local s=
torage/cache instead. For me as client it should not take too long to for m=
e to start using the local storage/cache, thus there should not be too long=
 delay between working on far away storage/cache to start working on local =
storage/cache.

If it is beginning to use a new server, that should simply be a
problem of making sure the handshake process is quick (less than a
second or two should be pretty simple to achieve).  If you also mean
that data needs to be migrated to the new storage location before it
is considered "usable", then I don't know what you can guarantee.  Of
course, a client could be smarter about migrating data on-demand.

As David was mentioning, I think this is a perfect example of where
certain requirements could quickly become complex to handle.  So, in
short, allowing a client to explicitly store/retrieve to/from multiple
servers (and possibly explicitly copying/moving data between servers)
is something that I think is reasonable to consider.  However, before
going beyond that for "mobility", we need to be specific about what is
being done.  Using David's model of "do no harm" I think is a good
approach here.

Rich

>
> This is quite straitforward explanaition and the most elementary version =
of mobility. In case someone has more stricter wiew on mobility, you need t=
o speak up.
>
> Br,
>
> +Ove
>
>>-----Original Message-----
>>From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com]
>>On Behalf Of ext Richard Alimi
>>Sent: 11 June, 2010 08:35
>>To: Strandberg, Ove (NSN - FI/Espoo)
>>Cc: ext David A. Bryan; decade@ietf.org
>>Subject: Re: [decade] Mobility req
>>
>>Hi Ove,
>>
>>On Fri, Jun 11, 2010 at 1:22 AM, Strandberg, Ove (NSN -
>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>> Hi Rich,
>>>
>>> Looking at the message you refer to, I can see that we agree
>>on the basis for the mob req.
>>
>>If it is as simple as being able to discover multiple servers,
>>then I think that can be useful and will not add complexity to
>>the protocol.
>>Of course, this does *not* mean that a DECADE client must have
>>access to multiple servers. =A0I would envision that to depend
>>on the particular deployment.
>>
>>> We probably will be able to cope with the use of some of the
>>basic requirements for mob req too.
>>>
>>> There are however one additional characteristic that comes
>>with mobility; the switch over to use a local storage/cache
>>needs to work fast enough for a mobile client. I am not going
>>to specify numbers, but let's say the client is working
>>against a far away storage/cache. For the client to think that
>>a local storage/access is better, then the switchover should
>>not produce delay of several seconds (guessimate, not hard
>>number, just illustrate the point). If the switchover has too
>>long delay, then it would probably be better to continue
>>working against the far away storage/cache.
>>
>>I'm unclear as to what you mean by "switchover" - can you
>>provide some more specifics? =A0What type of application are you
>>envisioning, and what specific operations do you intend to
>>include in the "switchover"
>>process?
>>
>>Rich
>>
>>>
>>> Br,
>>>
>>> +Ove
>>>
>>>>-----Original Message-----
>>>>From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On
>>>>Behalf Of ext Richard Alimi
>>>>Sent: 10 June, 2010 16:54
>>>>To: Strandberg, Ove (NSN - FI/Espoo)
>>>>Cc: ext David A. Bryan; decade@ietf.org
>>>>Subject: Re: [decade] Mobility req
>>>>
>>>>Hi Ove,
>>>>
>>>>On Thu, Jun 10, 2010 at 4:32 AM, Strandberg, Ove (NSN -
>>>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>>>> Hi David,
>>>>>
>>>>> Thanks for your comments! Let's here look at the most
>>>>intresting case;
>>>>> mobility requirement ;-)
>>>>>
>>>>> The mobility requirement is not necessary a complex issue,
>>>>but of course it depends on the viewer. If you want a
>>complex solution
>>>>you clearly can get a complex solution.
>>>>>
>>>>> My personal issue is the sense of clients that move about,
>>>>they are mobile. In case the used network storage / cache
>>through time
>>>>gets somewhat far off, then it would be beneficial for the client to
>>>>be able to access a storage/cache closer. So in essence the main and
>>>>most basic mobility aspect would be the efficient support
>>for a mobile
>>>>client to be able to access local caches instead of being forced to
>>>>have a big backhaul to original cache.
>>>>
>>>>If there are multiple storage locations available to a
>>client, I think
>>>>it is reasonable to let the client choose which to use. =A0See
>>my reply
>>>>to B=F6rje Ohlman from the previous charter
>>>>discussion:
>>>> =A0http://www.ietf.org/mail-archive/web/decade/current/msg00149.html
>>>>
>>>>However, note that we must not overlap with ALTO. =A0Note the explicit
>>>>out-of-scope item in the DECADE charter:
>>>> =A0Locating the "best" in-network storage location from which to
>>>>retrieve
>>>> =A0content if there are more than one location can provide the same
>>>> =A0content.
>>>>
>>>>>
>>>>> This now my personal motivation for mobile requirement, I
>>>>hope this can be seen as an acceptable reasoning and shared with you
>>>>others too. In case you agree on the potential concern, then
>>we might
>>>>look more at how to specify the requirement. Is this a good way
>>>>forward?
>>>>
>>>>I think this is fine.
>>>>
>>>>Rich
>>>>
>>>>>
>>>>> Br,
>>>>>
>>>>> +Ove
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On
>>>>Behalf Of
>>>>>>ext David A. Bryan
>>>>>>Sent: 07 June, 2010 22:58
>>>>>>To: Strandberg, Ove (NSN - FI/Espoo)
>>>>>>Cc: decade@ietf.org
>>>>>>Subject: Re: [decade] Merge requirements documents?
>>>>>>
>>>>>>I actually remember things a bit differently at the
>>meeting, with my
>>>>>>general sense being that there wasn't broad support for
>>most of the
>>>>>>new requirements. At least for now (perhaps I don't understand the
>>>>>>rational fully), I personally don't see a need to include
>>>>any of them,
>>>>>>with the exception of application agnostic (in the modified form
>>>>>>below, which isn't a requirement but a guiding principal).
>>>>>>
>>>>>>I think that the mobility requirement needed more discussion
>>>>>>-- most folks seemed to feel that it was a bit too complex
>>for now,
>>>>>>and personally, I didn't really understand the problem this would
>>>>>>address.
>>>>>>A very simplistic description of the major chartered use case of
>>>>>>DECADE is to allow a peer to make things available
>>>>in-network so that
>>>>>>others can obtain it without having to use the link to the peer
>>>>>>itself. In my view, it isn't intended to be generic
>>storage for the
>>>>>>user to place things that they want to be able to access easily
>>>>>>themselves. While having storage near me topologically
>>might reduce
>>>>>>the cost of putting it in the data locker in the first
>>>>place, I don't
>>>>>>really see how mobility is very critical when the major
>>>>purpose is to
>>>>>>allow me to place something in the network for someone else
>>>>to obtain.
>>>>>>I may just not quite understand what you are advocating -- can you
>>>>>>clarify a use case where we need this for the main P2P application?
>>>>>>
>>>>>>Data reuse is something that I simply see as an
>>implementation issue.
>>>>>>Obviously, a given implementation might choose to compare
>>copies of
>>>>>>data that it is storing and to consolidate them, but from a
>>>>>>protocol/network perspective, I think we are adding
>>complexity if we
>>>>>>track versions, number of copies stored, who has shared
>>which access
>>>>>>rights, etc. -- so much so that it seems unlikely to justify
>>>>the cost.
>>>>>>My preference would be that a user has access to their
>>>>locker, and can
>>>>>>place things in it, provide references to it, etc., but that each
>>>>>>user's data -- at least from the perspective of the protocol -- is
>>>>>>unique and managed by them. Again, as I said, that
>>wouldn't preclude
>>>>>>an implementation from making this optimization, I just don't see
>>>>>>requirement/protocol design as the right place for it.
>>>>>>
>>>>>>Finally, my take on the application technique issue at the
>>>>meeting was
>>>>>>this: In P2PSIP, we tried a "do no harm" approach. The
>>protocol for
>>>>>>P2PSIP (RELOAD) is essentially a DHT protocol.
>>>>>>The protocol is optimized for use in SIP
>>>>registration/location, and we
>>>>>>agreed that we wouldn't add unnecessary complexity that
>>>>wasn't needed
>>>>>>by that one application. That said, we have tried very hard (and
>>>>>>deliberately) to make sure that so long as it didn't increase
>>>>>>complexity, that we thought about other applications and
>>>>tried not to
>>>>>>design RELOAD in a way that would preclude use for other
>>>>applications.
>>>>>>I'd like a similar approach here -- we deliberately design for the
>>>>>>single application of storing information for P2P
>>>>applications, but if
>>>>>>others can point out other applications that dictate a
>>>>design decision
>>>>>>and
>>>>>>(critically) which do not add complexity/require new
>>>>features, we try
>>>>>>to make design decisions that allow that flexibility when
>>>>possible. I
>>>>>>see this as quite different from adding different application
>>>>>>scenarios and requiring that the protocol support all of
>>>>them -- that
>>>>>>is, in my opinion, likely to make this problem too broad and
>>>>increase
>>>>>>the difficulty of designing a protocol.
>>>>>>
>>>>>>David
>>>>>>
>>>>>>
>>>>>>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN -
>>>>>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>>>>>> Dear Decade email list,
>>>>>>>
>>>>>>> There were additional requirements identified for Decade
>>that was
>>>>>>> presented and discussed in the Anaheim IETF meeting (see
>>>>minutes in
>>>>>>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We
>>>>>>> basically brought some few additional requirements to
>>>>complement the
>>>>>>> already nice requirement list in draft-gu-decade-reqs-04.
>>>>>>The authors
>>>>>>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft
>>>>would like to
>>>>>>> suggest that the additional requirements could be
>>>>incorporated into
>>>>>>> one
>>>>>>>
>>>>>>> requirement document, albeit into the
>>>>draft-gu-decade-reqs-04 draft.
>>>>>>> The two first requirements "application agnostic" and
>>"data reuse"
>>>>>>> seemed to be well received, while the "mobility"
>>requirement needs
>>>>>>> further discussion. What do the authors of
>>>>>>draft-gu-decade-reqs-04 think about this merge proposal?
>>>>>>>
>>>>>>> We would like to also ask the DECADE email list to make
>>>>comments on
>>>>>>> the suggestion to combine both drafts into one document.
>>>>Is this an
>>>>>>> acceptable way forward?
>>>>>>>
>>>>>>> Br,
>>>>>>>
>>>>>>> +Ove
>>>>>>>
>>>>>>> ove.strandberg@nsn.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> decade mailing list
>>>>>>> decade@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/decade
>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> decade mailing list
>>>>> decade@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/decade
>>>>>
>>>>
>>>
>>
>

From richard.alimi@gmail.com  Fri Jun 11 06:02:24 2010
Return-Path: <richard.alimi@gmail.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82EF53A6836 for <decade@core3.amsl.com>; Fri, 11 Jun 2010 06:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.033
X-Spam-Level: 
X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[AWL=1.944,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12xF8fWiLnEA for <decade@core3.amsl.com>; Fri, 11 Jun 2010 06:02:23 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 7C9123A6820 for <decade@ietf.org>; Fri, 11 Jun 2010 06:02:23 -0700 (PDT)
Received: by wwc33 with SMTP id 33so700562wwc.31 for <decade@ietf.org>; Fri, 11 Jun 2010 06:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LFAO4/R0U8uUPhJm9tW6TY3E+/rCXfBsdRtYLbkye7k=; b=pCG+G5vrz1u+MP0x8EJG5MWUw5ZN7QRwqXWI4vwN3FvfrIyuSLeoSZnqJuXW7LsYSR l87vSbV2c/a2d9FGx8FpMmuzCWo71/YJdR4CpXZHvuFHJiR5KD40a05A7tK99VLZkZ+u 9amhCuhrIk2/feZhkMNIZ4lCOqYfLpHk1I0QQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=sQqYVkn01ctyH6RzZqdEBEAonikPR9h5R/iG8M+KAc/UM1wECgQlWxQgXpGp/tAR7q ah9Evg0LI3z4fBgjf0v2E/lR4spZm9xdOTAZ2imQ600KMM94qt256ej3DbQF9WeKg36s +xkys5r9fvKdH6EpNDhD6fIRSu2XvL/fxWsPI=
MIME-Version: 1.0
Received: by 10.227.155.133 with SMTP id s5mr1879871wbw.17.1276261341816; Fri,  11 Jun 2010 06:02:21 -0700 (PDT)
Sender: richard.alimi@gmail.com
Received: by 10.216.166.21 with HTTP; Fri, 11 Jun 2010 06:02:21 -0700 (PDT)
In-Reply-To: <AANLkTilCcOrxDNTj4Xy47DH_MuEJNuzqv0CPf-3-A-EN@mail.gmail.com>
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net> <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B308BD@FIESEXC015.nsn-intra.net> <AANLkTilo__sCzqv5f3k7z-SZDFkRVfPAhoXcbvoSxiEo@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B657FE@FIESEXC015.nsn-intra.net> <AANLkTilk_YKrzu46-b3a6Vtsa0q6LBqsrmvezLRrcSGY@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B658B6@FIESEXC015.nsn-intra.net> <AANLkTilCcOrxDNTj4Xy47DH_MuEJNuzqv0CPf-3-A-EN@mail.gmail.com>
Date: Fri, 11 Jun 2010 09:02:21 -0400
X-Google-Sender-Auth: vw0Ei9_n8D5dG7l1wG-isnKaGvI
Message-ID: <AANLkTikaBCLQDP4FRTGXb1IrUiouSApDS1ZnU1fqB-L-@mail.gmail.com>
From: Richard Alimi <richard.alimi@yale.edu>
To: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: decade@ietf.org
Subject: Re: [decade] Mobility req
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 13:02:24 -0000

> ... =A0So, in
> short, allowing a client to explicitly store/retrieve to/from multiple
> servers (and possibly explicitly copying/moving data between servers)
> is something that I think is reasonable to consider.

I'll make one other clarification here.  The reason that I think this
is reasonable to support such an approach, is because these basic
operations are likely to be needed anyways for P2P.  It does not
really require any new intelligence on behalf of the DECADE server, or
any coordination between DECADE servers.  In fact, it may not even be
necessary to add an explicit requirement for it.

Rich

From richard.alimi@gmail.com  Fri Jun 11 06:38:30 2010
Return-Path: <richard.alimi@gmail.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4F763A6905 for <decade@core3.amsl.com>; Fri, 11 Jun 2010 06:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.437
X-Spam-Level: 
X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLopzLbyjc-m for <decade@core3.amsl.com>; Fri, 11 Jun 2010 06:38:29 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2335528C152 for <decade@ietf.org>; Fri, 11 Jun 2010 06:38:28 -0700 (PDT)
Received: by fxm13 with SMTP id 13so682196fxm.31 for <decade@ietf.org>; Fri, 11 Jun 2010 06:38:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=t57S+iuMMMiQYFwyAVg2ZX12aY9hFAERP3zmyxI0DXU=; b=hjRJdCMyvQMg2D96QIj4gWJaG8bC7+HbnKv08o7pAIGiEEDegV/i3/sIAyVMPVNtnt R4OO7D+GkdEn9OHA42yS8Y22rDPP5Yyro9pfM8vxl1K6ycFHGiQ46p7QzCRIazpCjBJQ jC8FCG+9Lf86iHP6EIWW5sBUFe4hyZ47JOBmo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=jcRQ3E8Mq++u1lxxD3RHdtoxyO4AExujvxssfqKeqYPE6uPGwD9ojzXA9L3hWpt4RE 3rTL9r1YuW5LeDCJN+38JWVDLryaKA1ZYgp2iohq231HbrKvd1egtk3L1HNKBGuo7zLL Jhr5CTzNrroBGirWt/YGdZqL022R4aPzSC+u0=
MIME-Version: 1.0
Received: by 10.216.187.2 with SMTP id x2mr1961957wem.43.1276263506615; Fri,  11 Jun 2010 06:38:26 -0700 (PDT)
Sender: richard.alimi@gmail.com
Received: by 10.216.166.21 with HTTP; Fri, 11 Jun 2010 06:38:26 -0700 (PDT)
In-Reply-To: <AC126D9A37B1EF4DAE0A39C02E94E64702B6594F@FIESEXC015.nsn-intra.net>
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net> <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B6594F@FIESEXC015.nsn-intra.net>
Date: Fri, 11 Jun 2010 09:38:26 -0400
X-Google-Sender-Auth: avKEHzZI4Qy-lHxrUMbJCZLkKjE
Message-ID: <AANLkTikCBDw4GTNN0NJ-lADOxgrhuhN-NEwIzVz07xIW@mail.gmail.com>
From: Richard Alimi <richard.alimi@yale.edu>
To: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: decade@ietf.org
Subject: Re: [decade] Merge requirements documents?
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 13:38:30 -0000

Hi Ove,

We need to be careful to stay in the charter here.  The charter states:

  .. the WG will
  identify target applications to appropriately scope the problem and
  requirements. P2P applications are the primary target, but suitability
  to other applications with similar requirements may be considered
  depending on additional complexity required to support such
  applications.

The chartered work isn't "complementary" scenarios, but rather ones
with similar requirements.  In my opinion, the "do no harm" tenet can
be a good guidance to see if a particular application has similar
enough requirements.

In any case, if additional requirements are indeed being considered, I
think we need to have something concrete (e.g., a particular
application in use today).  That will tell us whether we're
approaching something with similar requirements to supporting a P2P
application, and where there might be differences in the requirements.

Rich

On Fri, Jun 11, 2010 at 3:47 AM, Strandberg, Ove (NSN - FI/Espoo)
<ove.strandberg@nsn.com> wrote:
> Hi David,
>
> I think that one main reason for difference in opinion between us David i=
s the basic approach and view of DECADE. You clearly think mostly about P2P=
 application scenario. I on the other hand think that when we specify a pro=
tocol for network storage / cache (usually from an client perspective) we s=
hould make sure the same network storage / cache protocol can be used for o=
ther application scenarios too. I fully support the P2P scenario, but the e=
ffort to make the broader applicability possible, should be well worth spen=
ding. Basically it would IMHO be good for us to make the protocol more succ=
eful. Agreed that the scope needs to be narrow enough, however if you like =
to look at P2P, I would be happy look after complementary scenarios ;-) How=
ever to be able to achieve this I hope that these additional requirements s=
hould be included. I am sure we will together make sure that we do not make=
 complex recommendations in the end ;-)
>
> Br,
>
> +Ove
>
>>-----Original Message-----
>>From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On
>>Behalf Of ext David A. Bryan
>>Sent: 07 June, 2010 22:58
>>To: Strandberg, Ove (NSN - FI/Espoo)
>>Cc: decade@ietf.org
>>Subject: Re: [decade] Merge requirements documents?
>>
>>I actually remember things a bit differently at the meeting,
>>with my general sense being that there wasn't broad support
>>for most of the new requirements. At least for now (perhaps I
>>don't understand the rational fully), I personally don't see a
>>need to include any of them, with the exception of application
>>agnostic (in the modified form below, which isn't a
>>requirement but a guiding principal).
>>
>>I think that the mobility requirement needed more discussion
>>-- most folks seemed to feel that it was a bit too complex for
>>now, and personally, I didn't really understand the problem
>>this would address.
>>A very simplistic description of the major chartered use case
>>of DECADE is to allow a peer to make things available
>>in-network so that others can obtain it without having to use
>>the link to the peer itself. In my view, it isn't intended to
>>be generic storage for the user to place things that they want
>>to be able to access easily themselves. While having storage
>>near me topologically might reduce the cost of putting it in
>>the data locker in the first place, I don't really see how
>>mobility is very critical when the major purpose is to allow
>>me to place something in the network for someone else to obtain.
>>I may just not quite understand what you are advocating -- can
>>you clarify a use case where we need this for the main P2P application?
>>
>>Data reuse is something that I simply see as an implementation issue.
>>Obviously, a given implementation might choose to compare
>>copies of data that it is storing and to consolidate them, but
>>from a protocol/network perspective, I think we are adding
>>complexity if we track versions, number of copies stored, who
>>has shared which access rights, etc. -- so much so that it
>>seems unlikely to justify the cost.
>>My preference would be that a user has access to their locker,
>>and can place things in it, provide references to it, etc.,
>>but that each user's data -- at least from the perspective of
>>the protocol -- is unique and managed by them. Again, as I
>>said, that wouldn't preclude an implementation from making
>>this optimization, I just don't see requirement/protocol
>>design as the right place for it.
>>
>>Finally, my take on the application technique issue at the meeting was
>>this: In P2PSIP, we tried a "do no harm" approach. The
>>protocol for P2PSIP (RELOAD) is essentially a DHT protocol.
>>The protocol is optimized for use in SIP
>>registration/location, and we agreed that we wouldn't add
>>unnecessary complexity that wasn't needed by that one
>>application. That said, we have tried very hard (and
>>deliberately) to make sure that so long as it didn't increase
>>complexity, that we thought about other applications and tried
>>not to design RELOAD in a way that would preclude use for
>>other applications. I'd like a similar approach here -- we
>>deliberately design for the single application of storing
>>information for P2P applications, but if others can point out
>>other applications that dictate a design decision and
>>(critically) which do not add complexity/require new features,
>>we try to make design decisions that allow that flexibility
>>when possible. I see this as quite different from adding
>>different application scenarios and requiring that the
>>protocol support all of them -- that is, in my opinion, likely
>>to make this problem too broad and increase the difficulty of
>>designing a protocol.
>>
>>David
>>
>>
>>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN -
>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>> Dear Decade email list,
>>>
>>> There were additional requirements identified for Decade that was
>>> presented and discussed in the Anaheim IETF meeting (see minutes in
>>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We
>>> basically brought some few additional requirements to complement the
>>> already nice requirement list in draft-gu-decade-reqs-04.
>>The authors
>>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft would like to
>>> suggest that the additional requirements could be incorporated into
>>> one
>>>
>>> requirement document, albeit into the draft-gu-decade-reqs-04 draft.
>>> The two first requirements "application agnostic" and "data reuse"
>>> seemed to be well received, while the "mobility" requirement needs
>>> further discussion. What do the authors of
>>draft-gu-decade-reqs-04 think about this merge proposal?
>>>
>>> We would like to also ask the DECADE email list to make comments on
>>> the suggestion to combine both drafts into one document. Is this an
>>> acceptable way forward?
>>>
>>> Br,
>>>
>>> +Ove
>>>
>>> ove.strandberg@nsn.com
>>>
>>> _______________________________________________
>>> decade mailing list
>>> decade@ietf.org
>>> https://www.ietf.org/mailman/listinfo/decade
>>>
>>>
>>
> _______________________________________________
> decade mailing list
> decade@ietf.org
> https://www.ietf.org/mailman/listinfo/decade
>

From davidbryan@gmail.com  Fri Jun 11 06:55:42 2010
Return-Path: <davidbryan@gmail.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8C03A6927 for <decade@core3.amsl.com>; Fri, 11 Jun 2010 06:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Level: 
X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yApdqyr1VWTs for <decade@core3.amsl.com>; Fri, 11 Jun 2010 06:55:41 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 196F43A6817 for <decade@ietf.org>; Fri, 11 Jun 2010 06:55:41 -0700 (PDT)
Received: by yxt33 with SMTP id 33so274359yxt.31 for <decade@ietf.org>; Fri, 11 Jun 2010 06:55:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LrbtFannUsgX9td0rvYIvaPpFMyyW4fXozLSLOB2GJg=; b=GbYgrTtu3NKUzmeAxGiPIyRyh/mUKVW2FOQ5wuBFmmT+O34hd07w4zqGvj3mDlp1rg gWtSqKjtmZFBbTfBoU8ADia0VCqDV00DC7aZQsre8JAMasCl9bHkDlh3ViSKmdGncQQC DHup0iqFS44wBdF0K6aFHduBrW1QzfnVlIMJ8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=pxrQ6eQ4CsSKMlqOO2GZ6yfgpY9463vlO82dUwLNa9M4Ebx8bQuUwqBGG25/N7Ul8b 0LIER94PEla9GGieeyzsO/F7SjG+wZumQgmDfVUh2+O8YZq+r1wzkWLTA1VWb6q2B8cK YIS4IEwLGm+JwtbgmeSLGkt5UUWXIe6vM0ebk=
MIME-Version: 1.0
Received: by 10.150.249.11 with SMTP id w11mr3205665ybh.234.1276264539773;  Fri, 11 Jun 2010 06:55:39 -0700 (PDT)
Sender: davidbryan@gmail.com
Received: by 10.151.51.7 with HTTP; Fri, 11 Jun 2010 06:55:39 -0700 (PDT)
In-Reply-To: <AC126D9A37B1EF4DAE0A39C02E94E64702B6594F@FIESEXC015.nsn-intra.net>
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net> <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B6594F@FIESEXC015.nsn-intra.net>
Date: Fri, 11 Jun 2010 09:55:39 -0400
X-Google-Sender-Auth: Ti3oVlNsYh1E6F1r2rjFIcMiSDc
Message-ID: <AANLkTikLX-cyx85jwKauCY4WmScqysID8qOmVIHCHiJ6@mail.gmail.com>
From: "David A. Bryan" <dbryan@ethernot.org>
To: "Strandberg, Ove (NSN - FI/Espoo)" <ove.strandberg@nsn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: decade@ietf.org
Subject: Re: [decade] Merge requirements documents?
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 13:55:42 -0000

The chartered focus of this WG is the P2P scenario, and has been
limited intentionally to keep the problem tractable (although as I
said, we should try to make things as flexible as possible to
encourage possible reuse). Designing a generic data storage system for
any app to store any kind of information is a far more complex
problem, because it is essentially unconstrained -- where do we draw
the line on applications? Can I use this as a backup for my server? As
a distributed file system? A real-time media streaming server for
handsets? To build a service like drop box? As a web server?

The problem becomes requirements explosion to satisfy all these
different scenarios. Your proposal to add mobility is a perfect
example of this issue. To have a generic storage a mobile client can
quickly access, you would need such a capability, but it is out of
scope explicitly (locating best storage) because it would radically
increase the complexity of the protocol in a way that would make
deployments for the original problem space much more difficult.

In my IETF experience, trying to solve many simultaneous problems is
the biggest obstacle to the success of a protocol, not being too
narrow in the design of the protocol. When we try that, we end up with
protocols that are the equivalent to an all-in-one kitchen gadget. It
blends, mixes, bakes, and of course slices, dices and juliennes, but
it doesn't do any of those things in a way that is really right.

We need to keep the focus sharp and simple, and design a solid
protocol for that task. We'll try hard to keep it flexible, but
remember that if the work is too far off, one can always have a
different WG with a different goal, and design something for that
scenario. In my personal opinion, I see your proposed requirements as
being a bit too far afield here, and believe adding them to the
requirements will increase the time to deliver a protocol and increase
the odds that protocol will fail.

David

On Fri, Jun 11, 2010 at 3:47 AM, Strandberg, Ove (NSN - FI/Espoo)
<ove.strandberg@nsn.com> wrote:
> Hi David,
>
> I think that one main reason for difference in opinion between us David i=
s the basic approach and view of DECADE. You clearly think mostly about P2P=
 application scenario. I on the other hand think that when we specify a pro=
tocol for network storage / cache (usually from an client perspective) we s=
hould make sure the same network storage / cache protocol can be used for o=
ther application scenarios too. I fully support the P2P scenario, but the e=
ffort to make the broader applicability possible, should be well worth spen=
ding. Basically it would IMHO be good for us to make the protocol more succ=
eful. Agreed that the scope needs to be narrow enough, however if you like =
to look at P2P, I would be happy look after complementary scenarios ;-) How=
ever to be able to achieve this I hope that these additional requirements s=
hould be included. I am sure we will together make sure that we do not make=
 complex recommendations in the end ;-)
>
> Br,
>
> +Ove
>
>>-----Original Message-----
>>From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On
>>Behalf Of ext David A. Bryan
>>Sent: 07 June, 2010 22:58
>>To: Strandberg, Ove (NSN - FI/Espoo)
>>Cc: decade@ietf.org
>>Subject: Re: [decade] Merge requirements documents?
>>
>>I actually remember things a bit differently at the meeting,
>>with my general sense being that there wasn't broad support
>>for most of the new requirements. At least for now (perhaps I
>>don't understand the rational fully), I personally don't see a
>>need to include any of them, with the exception of application
>>agnostic (in the modified form below, which isn't a
>>requirement but a guiding principal).
>>
>>I think that the mobility requirement needed more discussion
>>-- most folks seemed to feel that it was a bit too complex for
>>now, and personally, I didn't really understand the problem
>>this would address.
>>A very simplistic description of the major chartered use case
>>of DECADE is to allow a peer to make things available
>>in-network so that others can obtain it without having to use
>>the link to the peer itself. In my view, it isn't intended to
>>be generic storage for the user to place things that they want
>>to be able to access easily themselves. While having storage
>>near me topologically might reduce the cost of putting it in
>>the data locker in the first place, I don't really see how
>>mobility is very critical when the major purpose is to allow
>>me to place something in the network for someone else to obtain.
>>I may just not quite understand what you are advocating -- can
>>you clarify a use case where we need this for the main P2P application?
>>
>>Data reuse is something that I simply see as an implementation issue.
>>Obviously, a given implementation might choose to compare
>>copies of data that it is storing and to consolidate them, but
>>from a protocol/network perspective, I think we are adding
>>complexity if we track versions, number of copies stored, who
>>has shared which access rights, etc. -- so much so that it
>>seems unlikely to justify the cost.
>>My preference would be that a user has access to their locker,
>>and can place things in it, provide references to it, etc.,
>>but that each user's data -- at least from the perspective of
>>the protocol -- is unique and managed by them. Again, as I
>>said, that wouldn't preclude an implementation from making
>>this optimization, I just don't see requirement/protocol
>>design as the right place for it.
>>
>>Finally, my take on the application technique issue at the meeting was
>>this: In P2PSIP, we tried a "do no harm" approach. The
>>protocol for P2PSIP (RELOAD) is essentially a DHT protocol.
>>The protocol is optimized for use in SIP
>>registration/location, and we agreed that we wouldn't add
>>unnecessary complexity that wasn't needed by that one
>>application. That said, we have tried very hard (and
>>deliberately) to make sure that so long as it didn't increase
>>complexity, that we thought about other applications and tried
>>not to design RELOAD in a way that would preclude use for
>>other applications. I'd like a similar approach here -- we
>>deliberately design for the single application of storing
>>information for P2P applications, but if others can point out
>>other applications that dictate a design decision and
>>(critically) which do not add complexity/require new features,
>>we try to make design decisions that allow that flexibility
>>when possible. I see this as quite different from adding
>>different application scenarios and requiring that the
>>protocol support all of them -- that is, in my opinion, likely
>>to make this problem too broad and increase the difficulty of
>>designing a protocol.
>>
>>David
>>
>>
>>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN -
>>FI/Espoo) <ove.strandberg@nsn.com> wrote:
>>> Dear Decade email list,
>>>
>>> There were additional requirements identified for Decade that was
>>> presented and discussed in the Anaheim IETF meeting (see minutes in
>>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We
>>> basically brought some few additional requirements to complement the
>>> already nice requirement list in draft-gu-decade-reqs-04.
>>The authors
>>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft would like to
>>> suggest that the additional requirements could be incorporated into
>>> one
>>>
>>> requirement document, albeit into the draft-gu-decade-reqs-04 draft.
>>> The two first requirements "application agnostic" and "data reuse"
>>> seemed to be well received, while the "mobility" requirement needs
>>> further discussion. What do the authors of
>>draft-gu-decade-reqs-04 think about this merge proposal?
>>>
>>> We would like to also ask the DECADE email list to make comments on
>>> the suggestion to combine both drafts into one document. Is this an
>>> acceptable way forward?
>>>
>>> Br,
>>>
>>> +Ove
>>>
>>> ove.strandberg@nsn.com
>>>
>>> _______________________________________________
>>> decade mailing list
>>> decade@ietf.org
>>> https://www.ietf.org/mailman/listinfo/decade
>>>
>>>
>>
>

From melodysong@huawei.com  Sat Jun 12 18:56:03 2010
Return-Path: <melodysong@huawei.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0877A3A6807 for <decade@core3.amsl.com>; Sat, 12 Jun 2010 18:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.105
X-Spam-Level: 
X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[AWL=-2.000,  BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wBsQFJgVLNc for <decade@core3.amsl.com>; Sat, 12 Jun 2010 18:56:02 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3870E3A67E5 for <decade@ietf.org>; Sat, 12 Jun 2010 18:56:02 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3X00088K13MB@szxga03-in.huawei.com> for decade@ietf.org; Sun, 13 Jun 2010 09:55:51 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3X00BHGK13MV@szxga03-in.huawei.com> for decade@ietf.org; Sun, 13 Jun 2010 09:55:51 +0800 (CST)
Received: from s64081a ([10.138.84.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3X0082BK10FX@szxml04-in.huawei.com> for decade@ietf.org; Sun, 13 Jun 2010 09:55:51 +0800 (CST)
Date: Sun, 13 Jun 2010 09:55:47 +0800
From: Song Haibin <melodysong@huawei.com>
In-reply-to: <AANLkTikaBCLQDP4FRTGXb1IrUiouSApDS1ZnU1fqB-L-@mail.gmail.com>
To: 'Richard Alimi' <richard.alimi@yale.edu>, "'Strandberg, Ove (NSN - FI/Espoo)'" <ove.strandberg@nsn.com>
Message-id: <001401cb0a9b$8abbc040$a03340c0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=ISO-8859-1
Content-language: zh-cn
Content-transfer-encoding: quoted-printable
Thread-index: AcsJZoHZniAMorptT2+GtphRGRSUAABM2awQ
References: <AC126D9A37B1EF4DAE0A39C02E94E64702AF0DDA@FIESEXC015.nsn-intra.net> <AANLkTinhuQirRMJDiDqOW8qWzdHNnKZCI4YXULa7qM1P@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B308BD@FIESEXC015.nsn-intra.net> <AANLkTilo__sCzqv5f3k7z-SZDFkRVfPAhoXcbvoSxiEo@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B657FE@FIESEXC015.nsn-intra.net> <AANLkTilk_YKrzu46-b3a6Vtsa0q6LBqsrmvezLRrcSGY@mail.gmail.com> <AC126D9A37B1EF4DAE0A39C02E94E64702B658B6@FIESEXC015.nsn-intra.net> <AANLkTilCcOrxDNTj4Xy47DH_MuEJNuzqv0CPf-3-A-EN@mail.gmail.com> <AANLkTikaBCLQDP4FRTGXb1IrUiouSApDS1ZnU1fqB-L-@mail.gmail.com>
Cc: decade@ietf.org
Subject: Re: [decade] Mobility req
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Jun 2010 01:56:03 -0000

I think if possible, we can divide the mobility scenario into several
detailed technical requirements.=20

The first one could be copying/moving data between in-network storage, I =
can
see reasons to support it.

The second one I could envision is the service continuity when the IP
address of the client changes. And it should not require additional
re-authentication between the end user and the in-network storage. That
might mean, e.g. when a peer allocate the bandwidth resource in its
in-network storage for data retrieving to another peer, it should not =
depend
on the IP address of the remote peer.

Any other ones?

Xie Xie,
Haibin <as contributor>

> -----Original Message-----
> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On
> Behalf Of Richard Alimi
> Sent: Friday, June 11, 2010 9:02 PM
> To: Strandberg, Ove (NSN - FI/Espoo)
> Cc: decade@ietf.org
> Subject: Re: [decade] Mobility req
>=20
> > ... =A0So, in
> > short, allowing a client to explicitly store/retrieve to/from =
multiple
> > servers (and possibly explicitly copying/moving data between =
servers)
> > is something that I think is reasonable to consider.
>=20
> I'll make one other clarification here.  The reason that I think this
> is reasonable to support such an approach, is because these basic
> operations are likely to be needed anyways for P2P.  It does not
> really require any new intelligence on behalf of the DECADE server, or
> any coordination between DECADE servers.  In fact, it may not even be
> necessary to add an explicit requirement for it.
>=20
> Rich
> _______________________________________________
> decade mailing list
> decade@ietf.org
> https://www.ietf.org/mailman/listinfo/decade



From melodysong@huawei.com  Tue Jun 22 20:02:11 2010
Return-Path: <melodysong@huawei.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779083A6929 for <decade@core3.amsl.com>; Tue, 22 Jun 2010 20:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.247
X-Spam-Level: 
X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=1.352,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys-pcarhqUGl for <decade@core3.amsl.com>; Tue, 22 Jun 2010 20:02:10 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E1DA63A6992 for <decade@ietf.org>; Tue, 22 Jun 2010 20:02:09 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4G005L05RSME@szxga04-in.huawei.com> for decade@ietf.org; Wed, 23 Jun 2010 11:02:17 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4G006K05RSES@szxga04-in.huawei.com> for decade@ietf.org; Wed, 23 Jun 2010 11:02:16 +0800 (CST)
Received: from s64081a ([10.138.84.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4G008JT5RPXY@szxml04-in.huawei.com> for decade@ietf.org; Wed, 23 Jun 2010 11:02:16 +0800 (CST)
Date: Wed, 23 Jun 2010 11:02:13 +0800
From: Song Haibin <melodysong@huawei.com>
To: decade@ietf.org
Message-id: <009101cb1280$7aeb83c0$70c28b40$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-cn
Content-transfer-encoding: 7BIT
Thread-index: AcsRi6z0f/4GfQeYSPuAOf3SpNvHzgA8/YAQ
Subject: [decade] FW: Nomcom 2010-2011: Second Call for Volunteers
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2010 03:02:11 -0000

Hi Folks, if you are interested in upcoming Nomcom, please think about
volunteering.

> -----Original Message-----
> From: ietf-announce-bounces@ietf.org
> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair
> Sent: Tuesday, June 22, 2010 5:49 AM
> To: IETF Announcement list
> Subject: Nomcom 2010-2011: Second Call for Volunteers
> 
> Hi all,
> 
> This is the Second call for Volunteers for the 2010-11 nomcom.  We are
> just about halfway through the volunteer period so if you are considering
> volunteering please do so very soon.
> 
> I am pleased to report that we have 29 volunteers thus far whose
> qualifications have been confirmed by the secretariat. I have notified
> each of these volunteers by email.
> 
> If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve as a
> voting member and have not received a confirmation email from me, please
> re-submit and bring to my attention right away!
> 
> However, we need many more volunteers.  You have until 17:00 PDT (24:00
> UTC) on July 8, 2010 to volunteer for nomcom but it is much better if you
> volunteer as early as possible.  The more volunteers, the better chance we
> have of choosing a random yet representative cross section of the IETF
> pouplation.
> 
> As a reminder, volunteers must have attended 3 of the past 5 IETF
> meetings - per RFC 3777, which means 3 of the following meetings: IETF-73,
> IETF-74, IETF-75, IETF-76 and IETF-77.  If you qualify, and are willing to
> forgo appointment to any of the positions for which the nominating
> committee is responsible, please volunteer.
> 
> The 10 nominating committee members are selected randomly from a pool
> of
> volunteers.  The details of the operation of nomcom may be found in RFC
> 3777.  The process on how to volunteer for nomcom is in the initial
> announcement:  https://datatracker.ietf.org/ann/nomcom/2330/
> 
> The lists of open positions and people whose terms end in March 2011 and
> thus the positions for which the nominating committee is responsible are
> summarized in the initial announcement:
> https://datatracker.ietf.org/ann/nomcom/2330/
> 
> The 29 volunteers who have thus far been qualified by the secretariat
> are:
> 
> Fred Baker, Cisco Systems
> 
> Stephan Wenger, Vidyo, Inc.
> 
> Marc Blanchet, Viagenie
> 
> Lixia Zhang, UCLA
> 
> John Drake, Juniper Networks
> 
> Ole Troan, Cisco
> 
> Jiankang Yao, CNNIC
> 
> Wassim Haddad, Ericsson
> 
> Yi Zhao, Huawei USA
> 
> Teemu Savolainen, Nokia
> 
> Jouni Korhonen, Nokia Siemens Networks
> 
> Mehmet Ersue, Nokia Siemens Networks
> 
> Christian Schmidt, Nokia Siemens Networks
> 
> Stephen Hanna, Juniper Networks
> 
> Suresh Krishnan, Ericsson
> 
> Eric Gray, Ericsson
> 
> David Sinicrope, Ericsson
> 
> Jan Melen, Ericsson
> 
> Richard Barnes, BBN Technologies
> 
> Hugo Salgado Hernandez, NIC Chile
> 
> Ning Zong, Huawei Technologies
> 
> Qin Wu, Huawei Technologies
> 
> Karen Seo, BBN Technologies
> 
> Haibin Song, Huawei Technologies
> 
> Susan Hares, Huawei Technologies
> 
> Tony Hansen. AT&T Labs
> 
> Fuqing Huang, Huawei Technologies Co., Ltd.
> 
> Huub van Helvoort, Huawei Technologies
> 
> Miya Kohno, Juniper Networks
> 
> The primary activity for this nomcom will begin just prior to IETF-78 in
> Maastricht and should be completed in early January 2011.  The nomcom
> will
> be collecting requirements from the community, as well as talking to
> candidates and to community members about candidates. There will be
> weekly
> conference calls to ensure progress. Thus, being a nomcom member does
> require some time commitment.
> 
> While, there is no requirement in RFC 3777 that a participant attend IETF
> meetings while serving on nomcom, please consider that during the IETF
> meetings, people that do not attend would be expected to remotely
> participate during the day in the time zones of the meeting locations -
> Maastricht at the end of July and Beijing in November.
> 
> If you are not yet sure you would like to volunteer, please consider that
> nomcom members play a very important role in shaping the leadership of the
> IETF.  Ensuring the leadership of the IETF is fair and balanced and
> comprised of those who can lead the IETF in the right direction is an
> important responsibility that rests on the IETF participants at large.
> Volunteering for the nomcom is a good way of contributing in that
> direction.
> 
> Please volunteer by sending an email before:
> 17:00 PDT (24:00 UTC) July 8, 2010 as follows:
> 
> To: nomcom-chair@ietf.org
> Subject: Nomcom 2010-11 Volunteer
> 
> Please include the following information in the body:
> 
> <Your Full Name>  // As you enter in the IETF Registration Form,
>                   // First/Given name followed by Last/Family Name
> 
> <Current Primary Affiliation>
>                   // typically what goes in the Company field
>                   // in the IETF Registration Form
> 
> [<all email addresses used to Register for the past 5 IETF meetings>]
> <Preferred email address>  //
> 
> <Telephone number>         // For confirmation if selected
> 
> Please expect an email response from me within 3 days stating whether or
> not you are qualified.  If you don't receive a response, please re-send
> your email with the tag "Duplicate:" added to the subject line.
> 
> Thank you and I hope to hear from you,
> 
> Thomas Walsh
> Chair, Nomcom 2010-11
> Email: nomcom-chair@ietf.org
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce



From Akbar.Rahman@InterDigital.com  Tue Jun 29 10:46:11 2010
Return-Path: <Akbar.Rahman@InterDigital.com>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2346C3A6AD4 for <decade@core3.amsl.com>; Tue, 29 Jun 2010 10:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level: 
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8VsGa+J87aR for <decade@core3.amsl.com>; Tue, 29 Jun 2010 10:46:09 -0700 (PDT)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id C47373A6A8D for <decade@ietf.org>; Tue, 29 Jun 2010 10:46:08 -0700 (PDT)
Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 29 Jun 2010 13:46:19 -0400
Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 13:46:19 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 29 Jun 2010 13:46:19 -0400
Message-ID: <D60519DB022FFA48974A25955FFEC08C031F9840@SAM.InterDigital.com>
In-Reply-To: <20100629154504.E35FA3A6B13@core3.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Fwd: I-D Action:draft-rahman-decade-survey-00.txt 
Thread-Index: AcsXohryKih77bMuStal7nG8KNm4QAAEIN1g
References: <20100629154504.E35FA3A6B13@core3.amsl.com>
From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: <decade@ietf.org>
X-OriginalArrivalTime: 29 Jun 2010 17:46:19.0309 (UTC) FILETIME=[FB030DD0:01CB17B2]
Subject: [decade] Fwd: I-D Action:draft-rahman-decade-survey-00.txt
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2010 17:46:11 -0000

Hi,


We have submitted a draft (see below) with some additional survey
information for In-Network Storage Systems.  We look forward to any
feedback from the group.


Akbar/Juan-Carlos

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Tuesday, June 29, 2010 11:45 AM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-rahman-decade-survey-00.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : An Additional Survey of In-Network Storage
Systems
	Author(s)       : A. Rahman, J. Zuniga
	Filename        : draft-rahman-decade-survey-00.txt
	Pages           : 8
	Date            : 2010-06-29

This document describes some additional network based storage systems to
complement the surveys already performed in the DECADE working group.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rahman-decade-survey-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.