From Akbar.Rahman@InterDigital.com Sun Oct 2 21:21:57 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C67621F84BA for ; Sun, 2 Oct 2011 21:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oNxWQpZJAWT for ; Sun, 2 Oct 2011 21:21:55 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 82E4D21F8496 for ; Sun, 2 Oct 2011 21:21:55 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 00:24:51 -0400 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_01CC8184.652FB629" Date: Mon, 3 Oct 2011 00:24:39 -0400 Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Start of WGLC for draft-ietf-decade-reqs-04 Thread-index: Acu+91Byr8CuZlwMSYaaxFnqkg41Dy/qW7BQALUv98A= References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Woundy, Richard" , X-OriginalArrivalTime: 03 Oct 2011 04:24:51.0765 (UTC) FILETIME=[6508E650:01CC8184] Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 04:21:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8184.652FB629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 =20 Thanks to the authors for updating the I-D. Overall the document looks in good shape. I only have the following two comments: =20 =20 - Section 4.1.1.1 - Often protocols like STUN are required to account for NATs. I was not sure if this requirement meant that we should NOT use something like STUN as part of the overall DECADE solution (especially for DECADE server to server communications)? Is the real intent to force all DECADE servers to be on the public Internet? If so then perhaps it would be better to re-phrase the requirement? Finally, I was confused by the reason for the separate requirement of 6.1.2 that touched on the same issue. =20 - Section 7 - What does the section title of "Discussion" mean? If there is still open issues then the document should not go to WGLC. If these requirements are solid, then they should be written in the same format as the other sections of the document. =20 =20 Akbar =20 =20 =20 From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Thursday, September 29, 2011 8:13 AM To: decade@ietf.org Subject: [decade] Start of WGLC for draft-ietf-decade-reqs-04 =20 Folks, =20 Haibin and I are starting the working group last call for draft-ietf-decade-reqs-04, http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by Monday October 17. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, decade@ietf.org. =20 Authors, please do not make any additional changes to the internet-draft unless directed by the WG chairs. =20 Draft reviewers, it would be helpful to get your confirmation that your previous review comments have been correctly reflected in this version. =20 Thanks. =20 -- Rich and Haibin ------_=_NextPart_001_01CC8184.652FB629 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

 

Thanks to the authors = for updating the I-D.  Overall the document looks in good = shape.  I only have the following two = comments:

 

 

-          = Section = 4.1.1.1 – Often protocols like STUN are required to account for = NATs.  I was not sure if this requirement meant that we should NOT = use something like STUN as part of the overall DECADE solution = (especially for DECADE server to server communications)?   Is = the real intent to force all DECADE servers to be on the public = Internet?  If so then perhaps it would be better to re-phrase the = requirement?  Finally, I was confused by the reason for the = separate requirement of 6.1.2 that touched on the same = issue.

 

-          = Section 7 = – What does the section title of “Discussion” = mean?  If there is still open issues then the document should not = go to WGLC.  If these requirements are solid, then they should be = written in the same format as the other sections of the = document.

 

 

Akbar

 

 

 

From:= = decade-bounces@ietf.org = [mailto:decade-bounces@i= etf.org] On Behalf Of Woundy, Richard
Sent: = Thursday, September 29, 2011 8:13 AM
To: decade@ietf.org
Subject: = [decade] Start of WGLC for = draft-ietf-decade-reqs-04

 

Folks,

 

Haibin and I are = starting the working group last call for draft-ietf-decade-reqs-04, http://d= atatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by = Monday October 17. Please send all concerns, suggestions and comments = about this internet-draft to the DECADE mailing list, decade@ietf.org.

 

Authors, please do not = make any additional changes to the internet-draft unless directed by the = WG chairs.

 

Draft reviewers, it = would be helpful to get your confirmation that your previous review = comments have been correctly reflected in this = version.

 

Thanks.

 

-- Rich and = Haibin

------_=_NextPart_001_01CC8184.652FB629-- From hallam@gmail.com Mon Oct 3 13:38:09 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14E021F8E44; Mon, 3 Oct 2011 13:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAP96zhJnzil; Mon, 3 Oct 2011 13:38:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAED821F8E39; Mon, 3 Oct 2011 13:37:53 -0700 (PDT) Received: by vws5 with SMTP id 5so4856599vws.31 for ; Mon, 03 Oct 2011 13:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=MAyGC8+FRk4H2GjX0QWsd4CisQ7hVqvq8VaQtgFA56c=; b=OW09vOUCc63TR5i4ZPQlsi5ZkbrwqAcrkiuqDId1KPonOjpIUdRJn7rKmkO9czUJlP kjQNMwjZELaQc3QFNsUtQumx6veNWUc+cCyYg8MoHPikNoKV98alzjpbsYbD58wOo5vL u8Ah7C0sADa2VIjZRHEUx31HCWAQ45hJwTMJU= MIME-Version: 1.0 Received: by 10.52.174.36 with SMTP id bp4mr392757vdc.256.1317674456675; Mon, 03 Oct 2011 13:40:56 -0700 (PDT) Received: by 10.220.200.198 with HTTP; Mon, 3 Oct 2011 13:40:56 -0700 (PDT) Date: Mon, 3 Oct 2011 16:40:56 -0400 Message-ID: From: Phillip Hallam-Baker To: websec , khare@alumni.caltech.edu, decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [decade] Updated Digest Scheme URI X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 20:38:09 -0000 I have made major modifications to the digest scheme from the first version: http://www.ietf.org/id/draft-hallambaker-digesturi-01.txt The main changes relevant to the initial WebSEC use cases are: * Identifiers are now text strings using the IANA crypto algs registry * A 'start' has been made on getting the URI template filled in * The encoding scheme base64url encoding is used to comply with URI requirements * The content type is specified as a parameter In addition the following features have been outlined to demonstrate that it is possible to create a digest URI that WebSec and DECADE could both use: * Optional parameters section * Scheme for specifying one or more locations for retrieval * Scheme for decrypting encrypted stored content. Note that these particular use cases actually address recurring WEBSEC type issues, namely how to securely reference content stored on an untrusted server. Simply saying 'SSL' does not in fact solve this question since the linked content may be in a different trust zone. this turns up all the time with 'rickrolling' and general Slashdot fun. The main difference between my approach and Stephen's is that Stephen puts the domain portion first as is traditional for a URL. I throw it in as a parameter. Why? Well for static data (as we are doping here) the digest is a far more permanent and specific identifier of the content than one location that might return the data. So it really makes sense to put that up front and make it the first thing in the digest. Some form of URL transformation is going to be required in either scheme. As has been discussed on the list, relativity really does not provide much leverage here. The big payoff in my mind for DECADE is that this makes specifying more than one download location easy as well. It also makes it easy for aware applications to add and subtract locations as is sensible. If content is deposited in a cache, the cache can add its domain into the URI scheme. So the simplest URI described in the paper is: di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc The simplest secure reference is: di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=text/plain Addressing DECADE type use cases: A reference can be specified to external content: di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?http=di.example.com This maps to the following URL: http://di.example.com/.well-known/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc And the scheme can be extended to cover encrypted content as well: di:sha-128:B_K97zTtFuOhug27fke4_Q?enc=aes-cbc:Fw3x20nEKfq6FDGzq7ttIQ Have to credit Rohit Khare's work here as we both played around with this stuff back in 1995 when we were working for the Web Consortium. Note that the parameter schemes are proposed as illustration, not as something that I insist on. The point I want to make here is purely about the extensibility of the format proposed. If people want to only consider the WEBSEC use cases in that WG and ignore DECADE, then we could strip them out for the base draft and then have a supplemental draft that describes the extra features. My view is that the locator hints are actually very useful in the WEBSEC cert pinning context as they allow means for downloading the related certs. The encryption stuff is likely very interesting in DECADE as it means that the identifier is essentially a self contained capability for the referenced content. -- Website: http://hallambaker.com/ From hallam@gmail.com Mon Oct 3 19:50:50 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951C421F8EAC; Mon, 3 Oct 2011 19:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ9xOKaFI1V6; Mon, 3 Oct 2011 19:50:50 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D35A321F8EA9; Mon, 3 Oct 2011 19:50:49 -0700 (PDT) Received: by yxt33 with SMTP id 33so52897yxt.31 for ; Mon, 03 Oct 2011 19:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mQUy8Khe97BKwiZBbPMbo+QXsSWBPN9XJhcl7ngOJPg=; b=Mhoc8QYIOdqgBrhbaUYI2fXG05gwvavMiixVIq6HFeMI0tvVUVN62eJfm6dcg4e5ZJ iOL9TfWXy1EgSzNhEuDT4Xn/e9ayhL/avzXHZWUGnzngPiGF154A5m1D6nJumriHKT6r /ua/0h407oxrETQtkmcGYcrlyeD2Fx2Q2KR+g= MIME-Version: 1.0 Received: by 10.100.82.6 with SMTP id f6mr558583anb.52.1317696833659; Mon, 03 Oct 2011 19:53:53 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 19:53:53 -0700 (PDT) In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA53@SISPE7MB1.commscope.com> References: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA53@SISPE7MB1.commscope.com> Date: Mon, 3 Oct 2011 22:53:53 -0400 Message-ID: From: Phillip Hallam-Baker To: "Thomson, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "khare@alumni.caltech.edu" , "decade@ietf.org" , websec Subject: Re: [decade] Digest Scheme URI: .well-known X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 02:50:50 -0000 Ooops, that was an oversight in the draft, sorry. I did actually go so far as to specify the allocation of a di .well-known code point, I just forgot to use it! The URL was meant to be: https://di.example.com/.well-known/di/sha-256/B_K97zTtFuOhug... Sorry for the confusion. On Mon, Oct 3, 2011 at 10:02 PM, Thomson, Martin wrote: > On 2011-10-04 at 07:40:56, Phillip Hallam-Baker wrote: >> http://www.ietf.org/id/draft-hallambaker-digesturi-01.txt > ... >> * Scheme for specifying one or more locations for retrieval > > Please don't use /.well-known/ without some sort of extra qualification. = =A0My "mu" digest produces base-64 output that could collide with existing = registrations in that space. =A0It's just like a game of "battleship". =A0I= 'm really hoping to hit "host-meta" some day... > > What do you think of: > > =A0di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?r=3Dhttps://di.= example.com/r/ > or > =A0di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?r=3Dhttps://di.= example.com/r/{d} > > ...where retrieval is performed using: If we went this route I can't see why the digest would appear anywhere other than the end so why not just specify it as a prefix? The slippery slope there would be people looking to take parts of the digest and the algorithm in mix 'n match type approaches. Since this is a domain specified in a fairly tightly controlled URL, I don't see why collisions with other services can't be handled by people creating a new sub-domain specially for di content if required. I am not completely happy with .well-known, it is a yucky approach, but it is now sufficiently well established that it is probably OK. >> * Scheme for decrypting encrypted stored content. > > I don't see the encryption and content type parameters as a necessity. = =A0If the core goal of the document is to identify a resource, then providi= ng resource metadata is, as a generic capability, very useful. =A0However, = the specific subset of cases you have chosen exhibits a bias that might not= fit with all future uses. > True in the case of encryption, but I prefer to do stuff once if possible. The fact that there are parameters and the space is extensible means that there is room for other uses. The content type is essential meta-data if the digest is going to be used to create a strong reference to the specified content. Otherwise the attacker can repurpose an image/jpeg as application/script. This works much better than it should because most processors simply ignore content they don't understand and helpfully try to resynchronize. This creates attacks where the attacker can smuggle his malware into a photosharing site and then get links to it. It would create a new class of cross-site scripting attack if it was not present. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Oct 4 04:53:13 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404D021F8BD5; Tue, 4 Oct 2011 04:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXGVIXhVopXZ; Tue, 4 Oct 2011 04:53:12 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7E8121F8B74; Tue, 4 Oct 2011 04:53:09 -0700 (PDT) Received: by gyd12 with SMTP id 12so483984gyd.31 for ; Tue, 04 Oct 2011 04:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=s2/e/PglRH3B09ApQPww7joh7rDj99wisjea7YNF2yc=; b=JeopN2CaMvDozFj2VQsXk1Y0KO7UH2RqV+Knnrfjxc0qWxdRcj3u5aeShleFF8DKAp w9hvTz1AealtM0RcPUpNVVrYa82HEgPxIyhxCr75XwhcV47J4gL3Id4w3KY9WeMQ4ZGu QE4XsGvbFHiMaAjcBDK6DNXO4OhljU4ZoyWvU= MIME-Version: 1.0 Received: by 10.100.82.6 with SMTP id f6mr902546anb.52.1317729374486; Tue, 04 Oct 2011 04:56:14 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 04:56:14 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112902B30B7@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112902B30B7@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 4 Oct 2011 07:56:14 -0400 Message-ID: From: Phillip Hallam-Baker To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" , websec Subject: Re: [decade] [websec] Updated Digest Scheme URI: truncated digests X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 11:53:13 -0000 On Mon, Oct 3, 2011 at 11:22 PM, Manger, James H wrote: >> di:sha-128:B_K97zTtFuOhug27fke4_Q?enc=3Daes-cbc:Fw3x20nEKfq6FDGzq7ttIQ > > Instead if defining new names for truncated digests, why not simply inclu= de a truncated digest with the existing algorithm name? You can determine t= he truncation (in bytes) from the length of the base64url-encoding so there= is no ambiguity. > > =A0di:sha-256:B_K97zTtFuOhug27fke4_Q > > The only downside I see is the risk of bad implementations accepting a di= gest truncated to, say, 1 byte (eg di:sha-256:Bw) instead of enforcing a mi= nimum security level. That is a risk that has been realized for HMACs in certain circumstances. A caveat is probably sufficient. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Oct 4 05:04:13 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBC521F8C71; Tue, 4 Oct 2011 05:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xovws281LeFF; Tue, 4 Oct 2011 05:04:13 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0421F8C6F; Tue, 4 Oct 2011 05:04:12 -0700 (PDT) Received: by gyd12 with SMTP id 12so494621gyd.31 for ; Tue, 04 Oct 2011 05:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PQ7Uk7d6RR0R999Hpmzkrp/2Z85xAKVP4t2L3Zxqr0s=; b=t8y7K+WDDslwqpbMUntaOSlCrVlSEIr85+IE+RjkbGdP0Ag0R7/FWv4ziL9OY8Q6FK g0L9VRjy4nTE7aEBk46QRad5QiJxuFiur3GbHSR10GDYzwHcm09TO7NUnIF8JOqZ5Ur6 iw2OCyUqNm5pa/9VLB2msNKXRX5lBAPUrl6qE= MIME-Version: 1.0 Received: by 10.101.218.6 with SMTP id v6mr877711anq.140.1317730037771; Tue, 04 Oct 2011 05:07:17 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 05:07:17 -0700 (PDT) In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA5D@SISPE7MB1.commscope.com> References: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA53@SISPE7MB1.commscope.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA5D@SISPE7MB1.commscope.com> Date: Tue, 4 Oct 2011 08:07:17 -0400 Message-ID: From: Phillip Hallam-Baker To: "Thomson, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "khare@alumni.caltech.edu" , "decade@ietf.org" , websec Subject: Re: [decade] Digest Scheme URI: .well-known X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 12:04:13 -0000 On Tue, Oct 4, 2011 at 12:46 AM, Thomson, Martin wrote: > On 2011-10-04 at 13:53:53, Phillip Hallam-Baker wrote: >> The content type is essential meta-data if the digest is going to be >> used to create a strong reference to the specified content. Otherwise >> the attacker can repurpose an image/jpeg as application/script. This >> works much better than it should because most processors simply ignore >> content they don't understand and helpfully try to resynchronize. > > You aren't making the world a less safe place if you leave the problem al= one. =A0Or have I missed something. =A0What makes this scheme any worse for= the attack, other than its inherent opacity? The use case there is creating a strong reference from a https page to a plain http one. In that case there is an issue. It is a real attack and an increasingly serious one. But the issue is moot since DECADE requires the ability to select between locators so that it gets one with a content type it has a codec for. > Regarding de/encryption keys: Is it really the case that you need to decr= ypt before calculating the digest? =A0Excuse my ignorance, but for a file s= tore, I would have thought that encryption would want to come before storag= e. There are pros and cons for the order of operations wrt encryption and authentication. The ideal is actually authenticate (encrypt (content + authenticate (content))) For our application I think it is pretty clear that the digest would need to be of the plaintext. I don't like revealing any info on the plaintext. I will correct that. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Oct 4 10:51:29 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB3C21F8DCA; Tue, 4 Oct 2011 10:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIoFqDJt1Jja; Tue, 4 Oct 2011 10:51:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A57C521F8D6F; Tue, 4 Oct 2011 10:51:28 -0700 (PDT) Received: by ywm3 with SMTP id 3so897461ywm.31 for ; Tue, 04 Oct 2011 10:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=V8wvVxl9XfJe/Qvs0Mp5Yngt6E9EAUYBKMxuMeCRZUI=; b=MrXRMmRB5RCQfol8chwn5zxmfOWa6ZXSJkShHhRi8kK6Rw7ydFaH3jM82ATppxNDDu mwGEae1AS8LdnBHOorj9jzUWL3wtZ4WewwYdA06EhlNiq1pQvP2CXszusgwjGs9cPeQj RrfOep4Eb/13BlG/N408XRWzf4OztKUGJ1dE0= MIME-Version: 1.0 Received: by 10.101.218.6 with SMTP id v6mr1237986anq.140.1317750874196; Tue, 04 Oct 2011 10:54:34 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 10:54:34 -0700 (PDT) Date: Tue, 4 Oct 2011 13:54:34 -0400 Message-ID: From: Phillip Hallam-Baker To: websec , decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [decade] Updated, updated DIGEST spec X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 17:51:29 -0000 In response to comments on and off list, I have revved the draft to produce a -02 * Have fixed the omission of the scheme and algorithm in /.well-known/di/sha-256 * Have changed the colon separating the algorithm and the digest to a semi-colon on advice that some parsers will choke otherwise * Have taken out the SHA-128 scheme and instead put in support for truncation on an arbitrary 32 bit boundary. [This needs a security consideration of course] I guess I should have added the acknowledgements section as well. Stephen and I have had discussions off list. If all goes well this should be the last version of this draft before we get to a merge. The outcome that seems to be most likely to suit people's needs would be to have two drafts. The first would just have the core syntax and security considerations for using digest identifiers. The second would have all the interesting stuff link locators and encryption and stuff. Content-type would likely be in the second. I am going off to write some code. -- Website: http://hallambaker.com/ From hallam@gmail.com Tue Oct 4 10:52:02 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D9421F8B24; Tue, 4 Oct 2011 10:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guE9mqSed9EB; Tue, 4 Oct 2011 10:51:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0C721F8B0F; Tue, 4 Oct 2011 10:51:55 -0700 (PDT) Received: by mail-yw0-f44.google.com with SMTP id 3so897461ywm.31 for ; Tue, 04 Oct 2011 10:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XZ1xnm3rCz3J2yzz6L3u9sebbY4O4W43qjWIqKXiNsg=; b=Y3uw+oQUEQIofnhL/XuSWGjrAHKjBqwU4dN1Y3vZN11EnGetSudNvpeYaoqC4NMmKD b5oD7A4q72Wyy49Myjqv1n6sUCyDA6GKezonchDlUaRWNRDURhCbcTknNMj9QPktdxlt cD6BAQeccxvYXjGdFSnyDc3knRHtpsKwF/XAM= MIME-Version: 1.0 Received: by 10.100.18.21 with SMTP id 21mr1245835anr.118.1317750901332; Tue, 04 Oct 2011 10:55:01 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 10:55:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Oct 2011 13:55:01 -0400 Message-ID: From: Phillip Hallam-Baker To: websec , decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [decade] Updated, updated DIGEST spec X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 17:52:02 -0000 And he left out the URL that the message was about. http://www.ietf.org/id/draft-hallambaker-digesturi-02.txt On Tue, Oct 4, 2011 at 1:54 PM, Phillip Hallam-Baker wrote: > In response to comments on and off list, I have revved the draft to > produce a -02 > > * Have fixed the omission of the scheme and algorithm in > /.well-known/di/sha-256 > * Have changed the colon separating the algorithm and the digest to a > semi-colon on advice that some parsers will choke otherwise > * Have taken out the SHA-128 scheme and instead put in support for > truncation on an arbitrary 32 bit boundary. [This needs a security > consideration of course] > > I guess I should have added the acknowledgements section as well. > > > Stephen and I have had discussions off list. If all goes well this > should be the last version of this draft before we get to a merge. The > outcome that seems to be most likely to suit people's needs would be > to have two drafts. The first would just have the core syntax and > security considerations for using digest identifiers. The second would > have all the interesting stuff link locators and encryption and stuff. > Content-type would likely be in the second. > > I am going off to write some code. > > -- > Website: http://hallambaker.com/ > -- Website: http://hallambaker.com/ From Akbar.Rahman@InterDigital.com Wed Oct 5 07:05:02 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944C921F8D92; Wed, 5 Oct 2011 07:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUNEnM3lDh5H; Wed, 5 Oct 2011 07:04:58 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8664A21F8D56; Wed, 5 Oct 2011 07:04:58 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 10:08:05 -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: Wed, 5 Oct 2011 10:08:04 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Updated, updated DIGEST spec Thread-index: AcyCwNX3MxtHyzQRQSmsotAfXsMRrwApwn2g References: From: "Rahman, Akbar" To: "Phillip Hallam-Baker" X-OriginalArrivalTime: 05 Oct 2011 14:08:05.0960 (UTC) FILETIME=[3406CC80:01CC8368] Cc: decade@ietf.org, websec Subject: Re: [decade] Updated, updated DIGEST spec X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 14:05:02 -0000 Hi Phillip, I read through your draft and it was quite interesting. For DECADE, are you proposing to use your scheme for the naming of DECADE objects or for some other purpose? Please excuse me if the question had already been discussed as I must have missed it. Akbar -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Tuesday, October 04, 2011 1:55 PM To: websec; decade@ietf.org Subject: [decade] Updated, updated DIGEST spec In response to comments on and off list, I have revved the draft to produce a -02 * Have fixed the omission of the scheme and algorithm in /.well-known/di/sha-256 * Have changed the colon separating the algorithm and the digest to a semi-colon on advice that some parsers will choke otherwise * Have taken out the SHA-128 scheme and instead put in support for truncation on an arbitrary 32 bit boundary. [This needs a security consideration of course] I guess I should have added the acknowledgements section as well. Stephen and I have had discussions off list. If all goes well this should be the last version of this draft before we get to a merge. The outcome that seems to be most likely to suit people's needs would be to have two drafts. The first would just have the core syntax and security considerations for using digest identifiers. The second would have all the interesting stuff link locators and encryption and stuff. Content-type would likely be in the second. I am going off to write some code. --=20 Website: http://hallambaker.com/ _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From hallam@gmail.com Wed Oct 5 08:21:08 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AE021F8D70; Wed, 5 Oct 2011 08:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUxpCkx-V3yQ; Wed, 5 Oct 2011 08:21:07 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06B0E21F8D6F; Wed, 5 Oct 2011 08:21:04 -0700 (PDT) Received: by gyd12 with SMTP id 12so2038929gyd.31 for ; Wed, 05 Oct 2011 08:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=p1uWvZV+P1R8dPL9TWgmPhut15ozr96pEEGe/Af2fqc=; b=dqFwSZzXuFh01oW5FoGAXde7Opl33b1CbBF2l98EY9D8gSCLgrq0hiaFhA8cadHG1Z 0cLYJSAWOaHTWd0fptoZbV9uq3vRx2yUOOOwXgg8W/M084zzYj9eDjbm/Sf//D3CaMpW UJZJ+60HdVK2F8SWTv1cE1+TjRW6d31ngnm3w= MIME-Version: 1.0 Received: by 10.101.154.22 with SMTP id g22mr2139775ano.96.1317828252736; Wed, 05 Oct 2011 08:24:12 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Wed, 5 Oct 2011 08:24:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Oct 2011 11:24:12 -0400 Message-ID: From: Phillip Hallam-Baker To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org, websec Subject: Re: [decade] Updated, updated DIGEST spec X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 15:21:08 -0000 Actually the proposal is to merge my proposal with the ni scheme made by Stephen et. al. I generally recon that if two independent proposals converge on essentially the same thing it probably means it is on the right track. At worst it is a necessary dead end that has to be explored:-) On Wed, Oct 5, 2011 at 10:08 AM, Rahman, Akbar wrote: > Hi Phillip, > > > I read through your draft and it was quite interesting. =A0For DECADE, ar= e > you proposing to use your scheme for the naming of DECADE objects or for > some other purpose? =A0Please excuse me if the question had already been > discussed as I must have missed it. > > > Akbar > > > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Phillip Hallam-Baker > Sent: Tuesday, October 04, 2011 1:55 PM > To: websec; decade@ietf.org > Subject: [decade] Updated, updated DIGEST spec > > In response to comments on and off list, I have revved the draft to > produce a -02 > > * Have fixed the omission of the scheme and algorithm in > /.well-known/di/sha-256 > * Have changed the colon separating the algorithm and the digest to a > semi-colon on advice that some parsers will choke otherwise > * Have taken out the SHA-128 scheme and instead put in support for > truncation on an arbitrary 32 bit boundary. [This needs a security > consideration of course] > > I guess I should have added the acknowledgements section as well. > > > Stephen and I have had discussions off list. If all goes well this > should be the last version of this draft before we get to a merge. The > outcome that seems to be most likely to suit people's needs would be > to have two drafts. The first would just have the core syntax and > security considerations for using digest identifiers. The second would > have all the interesting stuff link locators and encryption and stuff. > Content-type would likely be in the second. > > I am going off to write some code. > > -- > Website: http://hallambaker.com/ > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > --=20 Website: http://hallambaker.com/ From richard_woundy@cable.comcast.com Wed Oct 5 14:35:57 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BC511E80C2 for ; Wed, 5 Oct 2011 14:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.479 X-Spam-Level: X-Spam-Status: No, score=-105.479 tagged_above=-999 required=5 tests=[AWL=2.984, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRLEKyuIDIFk for ; Wed, 5 Oct 2011 14:35:57 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id CC6AB11E80F2 for ; Wed, 5 Oct 2011 14:35:56 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.142206228; Wed, 05 Oct 2011 17:39:03 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Wed, 5 Oct 2011 17:39:03 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Nomcom 2011-2012: Second Call for Nominations Thread-Index: Acx1p83SvuomhflHTD2ovtWk+fc/jgN/WS9gAABx+tA= Date: Wed, 5 Oct 2011 21:39:02 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11369DF76@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [decade] FW: Nomcom 2011-2012: Second Call for Nominations X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 21:35:57 -0000 Please note this Nomcom request for nominations for open positions, as well= as feedback for current nominees. Thanks. -- Rich & Haibin -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Saturday, September 17, 2011 10:06 PM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2011-2012: Second Call for Nominations=20 Hi All, We are halfway through the nomination period (it ends on October 2, 2011) a= nd we need more nominees than we have received so far. We appreciate the fo= lks that have taken the time to nominate people and those who have accepted= so far. But the fact remains that the number of nominations have been belo= w average and the acceptance rates of those nominated has also been low. We need **YOUR** input and participation! We cannot properly execute the ta= sk of selecting the best candidates for these positions with so few nominat= ions and acceptances. So, please consider making nominations for the open p= ositions, in particular those for which we have so few nominations it takes just a few minutes of your time. Right now, we just need the names/email addresses. Why do we need more nominations? Well, even if you think a willing incumbe= nt is doing a very good job and should be returned, his or her ability to s= erve again might be impacted by unforeseen circumstances between now and Ma= rch. NomCom needs to consider multiple nominees to be prepared in the event= one or more candidates is unable to serve come next March and to ensure we= have chosen the best candidate. There are several ways you can help the Nomcom - You can nominate yourself. - You can nominate someone you know whom you think would do a good job. Don't worry about whether they might already be nominated. We would much pr= efer to receive the same nomination several times rather than miss a good p= erson we should consider. How to submit Nominations: -------------------------- The list of positions we need to fill, and the provided Job Descriptions, a= nd forms for nominations, can be found in the call for nominations at: https://datatracker.ietf.org/ann/nomcom/3049/ You can enter a nomination by going to the following URL:=20 https://www.ietf.org/group/nomcom/2011/nominate You can also nominate someone by sending an email to nomcom11@ietf.org and = giving us their name, email address and the open position you are nominatin= g them for. We will take care of the rest. If you are asked for a user name and password, use an existing ietf login a= nd password. If you need a login and password, request one from the followi= ng URL: https://datatracker.ietf.org/accounts/create/ Open List: ---------- As you already know, NomCom 2011-2012 will follow the policy for "Open Disc= losure of Willing Nominees" described in RFC 5680. Feedback Collection: -------------------- The open list is currently available on the Nomcom page and the entire comm= unity is invited to provide feedback on all nominees. You can provide your comments on all willing nominees at the following URL: https://www.ietf.org/group/nomcom/2011/input/ Suresh Krishnan Chair, NomCom 2011-2012 nomcom-chair@ietf.org suresh.krishnan@ericsson.com From hallam@gmail.com Thu Oct 6 19:46:05 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AA521F8B34; Thu, 6 Oct 2011 19:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2Oc5jyvaeB9; Thu, 6 Oct 2011 19:46:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8521F8B31; Thu, 6 Oct 2011 19:46:04 -0700 (PDT) Received: by ywm3 with SMTP id 3so3936698ywm.31 for ; Thu, 06 Oct 2011 19:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=PhgkGzI2B2sbpCM/DIJiIhdzr0pnhGlXzM6b1BW47j8=; b=O3Z0zrCkRKL2tpb6E/gT2pVV6dSIIRCsD7EBdg1T4eizWt2w2KAXW75PBxhzoe2FNp omkKO6AjOMlf5mYRUiN98qQ/2GU6dLDKEpOfBwX+X8tpd5yDzNeDCu+XpevyBasBrdn0 qLgou2gjfg0518jkkyq35O2SMtKx7faqZMerU= MIME-Version: 1.0 Received: by 10.101.22.6 with SMTP id z6mr354801ani.140.1317955756751; Thu, 06 Oct 2011 19:49:16 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Thu, 6 Oct 2011 19:49:16 -0700 (PDT) Date: Thu, 6 Oct 2011 22:49:16 -0400 Message-ID: From: Phillip Hallam-Baker To: websec , decade@ietf.org Content-Type: multipart/alternative; boundary=00504502957fb5fb5604aeac7c09 Subject: [decade] Digest: Adventures in encoding X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 02:46:06 -0000 --00504502957fb5fb5604aeac7c09 Content-Type: text/plain; charset=ISO-8859-1 Following on the base16/base64 discussion, I have written some code (see end) and have some ni digests in various flavors of encoding. My conclusion is that we should split the difference and do base32 instead. I think the arguments are actually quite compelling. This is only an encoding issue. So choosing an encoding that requires the least number of systems to be touched is my priority. Choosing base32 allows the resolution scheme to be supported by unmodified Apache and IIS. The additional code burden for ni/digest implementers to write base32 is trivial There is also the option of doing more than one encoding. But Base64 uris are only slightly shorter. *Base16* ni:sha-256;B77B635B2832BF95E8F2935963F134A41F4F11C0BEDD6CED2C5E551F288D9980 Problem - very long even without separators. *Base32:* ni:sha-256;W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA Advantage: more compact than Base16 (somewhat), can be read out over a telephone or terminal room (try that with Base64). Can be printed as a static reference in a journal or equivalent. *Base32s:* ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA This is my own invention, basically Base32 with separators added for readability. *Base64:* ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= This is the traditional base64 encoding. Process disadvantage: You know that someone is bound to challenge the forward slash just as the document gets to last call. I don't see an advantage to risk a discuss. Practical disadvantage: Gets messed up when converted to a well-known URL. Consider the following: ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=?http=example.com This would map to: http://example.com/.well-known/ni/sha-256/t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= The forward slash is not a hierarchy indicator which is bad. Worse still this would mean that support for ni digest objects requires a code plug in for Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to the directory with the digest values. *Base64url:* ni:sha-256;t3tjWygyv5Xo8pNZY_E0pB9PEcC-3WztLF5VHyiNmYA This is essentially the same as base64 for size etc. The only disadvantage being that the encoder has to be scratch written. (Mine took 20 mins). The advantage over plain base64 is that there is no code required to support the .well-known version of the locator scheme on the server at all. Just some admin stuff. Also the URL is completely compatible with URI process lore. *Summary:* Arguments can be made for each one of these schemes. I think the argument for Base16 is the weakest since Base32 can do everything that Base16 can do. Neither is implemented as a standard library function on my platform. If we went for Base32, I would argue for allowing some form of readability separator. Base32s is much easier to transcribe than plain Base32. Base64/Base64url offer the best compression in a practical form. For most applications a truncated digest will be acceptable. The main disadvantage of the Base64 schemes is that they are case sensitive. This will play merry heck with case insensitive but case preserving file systems such as Windows. I think we should knock out base16 from consideration as base32 does it better. Since it is fairly easy to write a filter that strips out the separators, I would argue for allowing separators at any point in the identifier but that the canonical form is with the separators stripped out and this is what is used to create the URL form. So ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA would map to http://example.com/.well-known/ni/sha-256/W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA This preserves the criteria that Apache, IIS etc can be configured to resolve these identifiers without new code. Taking out Base 16 and base32 without separators, I see the following options: Base32s only Base64 only Base64url only Base32s + Base64url I can see pros and cons for the base32 encoding. To make it really readable it is necessary to put in the separators which is something of an overhead. So I can see an argument for both. But if we only pick one I would say take base32 with separators. It is not the most compact but it is good enough. It is fully URL compatible and has the readability benefit. Here is Base32 in C#: string ToBase32String(byte[] data, int Length) { string result = ""; int offset = 0; int a = 0; for (int i = 0; i < Length; i++) { a = (a << 8) | data[i]; offset += 8; while (offset >= 5) { offset -= 5; int n = a >> offset; result = result + BASE32[n]; a = a & (0x1f >> (5 - offset)); } } if (offset > 0) { result = result + BASE32[a]; } return result; } Here is base64url in C#: string ToBase64urlString(byte[] data, int Length) { string result = ""; int offset = 0; int a = 0; for (int i = 0; i < Length; i++) { a = (a << 8) | data[i]; offset += 8; //Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result, offset); while (offset >= 6) { offset -= 6; int n = a >> offset; result = result + BASE64URL[n]; a = a & (0x3f >> (6 - offset)); } } if (offset > 0) { result = result + BASE64URL[a]; } return result; } -- Website: http://hallambaker.com/ --00504502957fb5fb5604aeac7c09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Following on the base16/base64 discussion, I have written some code (see en= d) and have some ni digests in various flavors of encoding.

<= div>My conclusion is that we should split the difference and do base32 inst= ead. I think the arguments are actually quite compelling.

This is only an encoding issue. So choosing an encoding= that requires the least number of systems to be touched is my priority. Ch= oosing base32 allows the resolution scheme to be supported by unmodified Ap= ache and IIS.=A0

The additional code burden for ni/digest implementers t= o write base32 is trivial=A0


There = is also the option of doing more than one encoding. But Base64 uris are onl= y slightly shorter.


Base16
ni:sha-256;B77B635B2832BF95E8F2935963F134A41F= 4F11C0BEDD6CED2C5E551F288D9980

Problem - very long even without sepa= rators.


Base32:
ni:sha-256;W5AGGABIGKAJLAHSSNAGHABUUQA= E6AGAX3AGZABMLZAB6AENTGAA

Advantage: more compact than Base16 (somewhat), can be read out over a = telephone or terminal room (try that with Base64). Can be printed as a stat= ic reference in a journal or equivalent.


Base32s:
ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA
<= br>This is my own invention, basically Base32 with separators added for rea= dability.


Base64:
ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PE= cC+3WztLF5VHyiNmYA=3D

This is the traditional base64 encoding.

Process disadvantage: Y= ou know that someone is bound to challenge the forward slash just as the do= cument gets to last call. I don't see an advantage to risk a discuss.
Practical disadvantage: Gets messed up when converted to a well-known U= RL. Consider the following:

ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3= WztLF5VHyiNmYA=3D?http=3Dexample.com
=
This would map to:

http://example.com/.wel= l-known/ni/sha-256/t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=3D
The forward slash is not a hierarchy indicator which is bad. Worse still th= is would mean that support for ni digest objects requires a code plug in fo= r Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to the di= rectory with the digest values.


Base64url:

ni:sha-256;t3tjWygyv5Xo8pNZY_E0pB9PEcC-3Wz= tLF5VHyiNmYA

This is essentially the same as base64 for size etc. Th= e only disadvantage being that the encoder has to be scratch written. (Mine= took 20 mins).

The advantage over plain base64 is that there is no code required to su= pport the .well-known version of the locator scheme on the server at all. J= ust some admin stuff. Also the URL is completely compatible with URI proces= s lore.


Summary:

Arguments can be made for each o= ne of these schemes. I think the argument for Base16 is the weakest since B= ase32 can do everything that Base16 can do. Neither is implemented as a sta= ndard library function on my platform.

If we went for Base32, I would argue for allowing some = form of readability separator. Base32s is much easier to transcribe than pl= ain Base32.

Base64/Base64url offer the best compre= ssion in a practical form. For most applications a truncated digest will be= acceptable. The main disadvantage of the Base64 schemes is that they are c= ase sensitive. This will play merry heck with case insensitive but case pre= serving file systems such as Windows.=A0

I think we should knock out base16 from consideration as base32 does it= better.

Since it is fairly easy to write a filter= that strips out the separators, I would argue for allowing separators at a= ny point in the identifier but that the canonical form is with the separato= rs stripped out and this is what is used to create the URL form. So

ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AEN= TGAA

would map to


This preserves the criteria that Apache, IIS etc can be= configured to resolve these identifiers without new code.=A0

Taking out Base 16 and base32 without separators= , I see the following options:

Base32s only
Base64 only
Base64url = only
Base32s + Base64url

I can see pros = and cons for the base32 encoding. To make it really readable it is necessar= y to put in the separators which is something of an overhead. So I can see = an argument for both.

But if we only pick one I would say take base32 with se= parators. It is not the most compact but it is good enough. It is fully URL= compatible and has the readability benefit.


Here is Base32 in C#:

=A0 =A0 =A0 = =A0 string ToBase32String(byte[] data, int Length) {
=A0 =A0 =A0 = =A0 =A0 =A0 string result =3D "";
=A0 =A0 =A0 =A0 =A0 = =A0 int offset =3D 0;
=A0 =A0 =A0 =A0 =A0 =A0 int a =3D 0;

=A0 =A0 =A0 =A0 =A0 =A0 for (int i =3D 0; i < Length= ; i++) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a =3D (a << 8) | d= ata[i];
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offset +=3D 8;
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 while (offset >=3D 5) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offset -=3D 5;

<= /div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int n =3D a >> offs= et;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 result =3D result + B= ASE32[n];
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a =3D a & (= 0x1f >> (5 - offset));
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 }

=A0 =A0 =A0 =A0 =A0 =A0 if (offs= et > 0) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 result =3D result + = BASE32[a];
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 = =A0 =A0 =A0 =A0 return result;
=A0 =A0 =A0 =A0 =A0 =A0 }

Here is base64url in C#:

= =A0 =A0 =A0 =A0string ToBase64urlString(byte[] data, int Length) {
=A0 = =A0 =A0 =A0 =A0 =A0string result =3D "";
=A0 =A0 =A0 =A0 =A0 = =A0int offset =3D 0;
=A0 =A0 =A0 =A0 =A0 =A0int a =3D 0;

=A0 =A0 =A0 =A0 =A0 =A0for (int i =3D 0; i < Length; i++) {
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0a =3D (a << 8) | data[i];
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0offset +=3D 8;

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/= /Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result, offset);

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while (offset >=3D 6) {
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0offset -=3D 6;

=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0int n =3D a >> offset;
=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0result =3D result + BASE64URL[n];
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0a =3D a & (0x3f >> (6 - offset));
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0}
=A0 =A0 =A0 =A0 =A0 =A0if (offset > 0) {
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0result =3D result + BASE64URL[a];
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0return result;
=A0 =A0 =A0 =A0 = =A0 =A0}
--
Website: http://hall= ambaker.com/


--00504502957fb5fb5604aeac7c09-- From stephen.farrell@cs.tcd.ie Fri Oct 7 01:51:36 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD6F21F8B3D; Fri, 7 Oct 2011 01:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlWvuVow4Rpg; Fri, 7 Oct 2011 01:51:35 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id B1A1921F8B34; Fri, 7 Oct 2011 01:51:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E90F4171C9B; Fri, 7 Oct 2011 09:54:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1317977681; bh=YTIY6uVdUuIR46 h7VY0nAHn2MGJrnG0s7kbqFSTGsf8=; b=uA4Yjrslhb2TbZOymV7juD45KLPnmB Li7XlkVUhYG/YZB2VKRgtEoJSDXBYGQ2X/3jlYrjl0Ofj9iOwBaLSPCEY6EfjYzE y6ToiWCI5Ab3EUEZbdQWWdK/Yo2h3DwwopOzYuPQHdlii+vCYUxSWfVhr8zZc9Tv UKVp+QsoGYsUUhVvtUvxYNr9ua+1GMU6ypko6bsDQTGeVAx5W5iklm+3OpjZwAEh Yvev7V2jRBZrWlXEQCSnhG9KpPt4MMWaMY72s4bzkjdd6ffkHOTmHxjTSqxVPEy/ ry53sMe9nNv60shjo4VSsuEIUHCexbK+8IY5zKOmgwwIoG+YKPCb1Y1Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id hM2bPlkPZajj; Fri, 7 Oct 2011 09:54:41 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.20.64]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3E919171C2C; Fri, 7 Oct 2011 09:54:39 +0100 (IST) Message-ID: <4E8EBE4E.2040203@cs.tcd.ie> Date: Fri, 07 Oct 2011 09:54:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: decade@ietf.org, websec Subject: Re: [decade] Digest: Adventures in encoding X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 08:51:36 -0000 Hi Phill, Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by [W3C.REC-html401-19991224]" all over the place to solve basically this problem but in the context of HTTP URLs which has to be worse than for a new URI scheme. Why not do the same here? S. [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.1 On 10/07/2011 03:49 AM, Phillip Hallam-Baker wrote: > Following on the base16/base64 discussion, I have written some code (see > end) and have some ni digests in various flavors of encoding. > > My conclusion is that we should split the difference and do base32 instead. > I think the arguments are actually quite compelling. > > This is only an encoding issue. So choosing an encoding that requires the > least number of systems to be touched is my priority. Choosing base32 allows > the resolution scheme to be supported by unmodified Apache and IIS. > > The additional code burden for ni/digest implementers to write base32 is > trivial > > > There is also the option of doing more than one encoding. But Base64 uris > are only slightly shorter. > > > *Base16* > ni:sha-256;B77B635B2832BF95E8F2935963F134A41F4F11C0BEDD6CED2C5E551F288D9980 > > Problem - very long even without separators. > > > *Base32:* > ni:sha-256;W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA > > Advantage: more compact than Base16 (somewhat), can be read out over a > telephone or terminal room (try that with Base64). Can be printed as a > static reference in a journal or equivalent. > > > *Base32s:* > ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA > > This is my own invention, basically Base32 with separators added for > readability. > > > *Base64:* > ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= > > This is the traditional base64 encoding. > > Process disadvantage: You know that someone is bound to challenge the > forward slash just as the document gets to last call. I don't see an > advantage to risk a discuss. > > Practical disadvantage: Gets messed up when converted to a well-known URL. > Consider the following: > > ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=?http=example.com > > This would map to: > > http://example.com/.well-known/ni/sha-256/t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= > > The forward slash is not a hierarchy indicator which is bad. Worse still > this would mean that support for ni digest objects requires a code plug in > for Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to the > directory with the digest values. > > > *Base64url:* > > ni:sha-256;t3tjWygyv5Xo8pNZY_E0pB9PEcC-3WztLF5VHyiNmYA > > This is essentially the same as base64 for size etc. The only disadvantage > being that the encoder has to be scratch written. (Mine took 20 mins). > > The advantage over plain base64 is that there is no code required to support > the .well-known version of the locator scheme on the server at all. Just > some admin stuff. Also the URL is completely compatible with URI process > lore. > > > *Summary:* > > Arguments can be made for each one of these schemes. I think the argument > for Base16 is the weakest since Base32 can do everything that Base16 can do. > Neither is implemented as a standard library function on my platform. > > If we went for Base32, I would argue for allowing some form of readability > separator. Base32s is much easier to transcribe than plain Base32. > > Base64/Base64url offer the best compression in a practical form. For most > applications a truncated digest will be acceptable. The main disadvantage of > the Base64 schemes is that they are case sensitive. This will play merry > heck with case insensitive but case preserving file systems such as > Windows. > > I think we should knock out base16 from consideration as base32 does it > better. > > Since it is fairly easy to write a filter that strips out the separators, I > would argue for allowing separators at any point in the identifier but that > the canonical form is with the separators stripped out and this is what is > used to create the URL form. So > > ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA > > would map to > > http://example.com/.well-known/ni/sha-256/W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA > > This preserves the criteria that Apache, IIS etc can be configured to > resolve these identifiers without new code. > > > Taking out Base 16 and base32 without separators, I see the following > options: > > Base32s only > Base64 only > Base64url only > Base32s + Base64url > > I can see pros and cons for the base32 encoding. To make it really readable > it is necessary to put in the separators which is something of an overhead. > So I can see an argument for both. > > But if we only pick one I would say take base32 with separators. It is not > the most compact but it is good enough. It is fully URL compatible and has > the readability benefit. > > > Here is Base32 in C#: > > string ToBase32String(byte[] data, int Length) { > string result = ""; > int offset = 0; > int a = 0; > > for (int i = 0; i< Length; i++) { > a = (a<< 8) | data[i]; > offset += 8; > > while (offset>= 5) { > offset -= 5; > > int n = a>> offset; > result = result + BASE32[n]; > a = a& (0x1f>> (5 - offset)); > } > } > > if (offset> 0) { > result = result + BASE32[a]; > } > return result; > } > > Here is base64url in C#: > > string ToBase64urlString(byte[] data, int Length) { > string result = ""; > int offset = 0; > int a = 0; > > for (int i = 0; i< Length; i++) { > a = (a<< 8) | data[i]; > offset += 8; > > //Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result, > offset); > > while (offset>= 6) { > offset -= 6; > > int n = a>> offset; > result = result + BASE64URL[n]; > a = a& (0x3f>> (6 - offset)); > } > } > if (offset> 0) { > result = result + BASE64URL[a]; > } > return result; > } > > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From duerst@it.aoyama.ac.jp Fri Oct 7 04:19:59 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3736F21F8B28 for ; Fri, 7 Oct 2011 04:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.74 X-Spam-Level: X-Spam-Status: No, score=-99.74 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hlx4ptKT+Xf for ; Fri, 7 Oct 2011 04:19:58 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id E812A21F8B19 for ; Fri, 7 Oct 2011 04:19:57 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p97BN4ga012741 for ; Fri, 7 Oct 2011 20:23:04 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 57bd_213e_b9123ae6_f0d6_11e0_8944_001d096c566a; Fri, 07 Oct 2011 20:23:03 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51137) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 7 Oct 2011 20:23:06 +0900 Message-ID: <4E8EE110.9090502@it.aoyama.ac.jp> Date: Fri, 07 Oct 2011 20:22:56 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <4E8EBE4E.2040203@cs.tcd.ie> In-Reply-To: <4E8EBE4E.2040203@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 07 Oct 2011 04:45:40 -0700 Cc: websec , decade@ietf.org Subject: Re: [decade] [websec] Digest: Adventures in encoding X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 11:19:59 -0000 Hello Stephen, On 2011/10/07 17:54, Stephen Farrell wrote: > > Hi Phill, > > Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by > [W3C.REC-html401-19991224]" all over the place to solve basically > this problem but in the context of HTTP URLs which has to be worse > than for a new URI scheme. > > Why not do the same here? Are you thinking about this for escaping characters such as slashes? Or do you think we should take the binary hash, look at it as a series of 8-bit bytes, and escape each of these bytes with %-encoding? For the former, we already have the filesystem-safe version (passing a slash with %-encoding to a decent server might allow the server to use the slash *in* the filename, but that would confuse users and a whole lot of other software. For the later, this would essentially be base16 with a lot of '%' characters mixed in. As for Phil's original ideas, if there's a security issue with distinguishing upper- and lowercase filenames on Windows, then abandoning base64 may be a good idea. I wouldn't know of and couldn't imagine a structural security issue, but then I'm no security expert, but there's certainly some erosion, up to one bit per 6 bits if all of the characters are alphabetic. As for Base32, I don't like it too much because it seems to be totally new, and I prefer using existing stuff if it's good enough. This may show up in code. In scripting languages (think Perl, Ruby,...), Base64 and Base16 are simple pack operations, and Base64url is a pack and a tr, but Base32 needs handcoding. Also, Base32 aligns 8 characters to 5 bytes, Base64 4 characters to 3 bytes, and Base16 2 characters to 1 byte, and I somehow prefer a more regular alignment (although the reason for this may be that I never completely figured out how to handle the non-aligned stuff at the end). As for the Base32 with slashes, why not just leave the choice of having slashes or not to the creator, and require the consumer to take them out (as Phil proposed anyway). But with the "slashes being taken out" I don't understand Phil's argument about direct mapping to file names. On the other hand, I think allowing both Base32s and Base64url is a non-starter. Why have two if one is good enough? And then you can't map to URI paths because somebody could transform the digest from one version to another to squeeze it. Also, I don't understand Phil's length issues (Base32 is almost as good as Base64, so it's good, but Base16 is too long); he seems to have a specific upper length in mind for a specific use case, which I think is always a bad idea. (Others may have other limits that are a bit shorter or a bit longer.) What I still don't understand is where the pressure for having to have the digest and part of the URI path needing to be the same comes from. If I want to have a digest protection for a page directly at http://www.example.org/, shouldn't I be able to do so? I tried to ask about this previously, but I still didn't get the point, sorry. Regards, Martin. > S. > > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.1 > > On 10/07/2011 03:49 AM, Phillip Hallam-Baker wrote: >> Following on the base16/base64 discussion, I have written some code (see >> end) and have some ni digests in various flavors of encoding. >> >> My conclusion is that we should split the difference and do base32 >> instead. >> I think the arguments are actually quite compelling. >> >> This is only an encoding issue. So choosing an encoding that requires the >> least number of systems to be touched is my priority. Choosing base32 >> allows >> the resolution scheme to be supported by unmodified Apache and IIS. >> >> The additional code burden for ni/digest implementers to write base32 is >> trivial >> >> >> There is also the option of doing more than one encoding. But Base64 uris >> are only slightly shorter. >> >> >> *Base16* >> ni:sha-256;B77B635B2832BF95E8F2935963F134A41F4F11C0BEDD6CED2C5E551F288D9980 >> >> >> Problem - very long even without separators. >> >> >> *Base32:* >> ni:sha-256;W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA >> >> Advantage: more compact than Base16 (somewhat), can be read out over a >> telephone or terminal room (try that with Base64). Can be printed as a >> static reference in a journal or equivalent. >> >> >> *Base32s:* >> ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA >> >> This is my own invention, basically Base32 with separators added for >> readability. >> >> >> *Base64:* >> ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= >> >> This is the traditional base64 encoding. >> >> Process disadvantage: You know that someone is bound to challenge the >> forward slash just as the document gets to last call. I don't see an >> advantage to risk a discuss. >> >> Practical disadvantage: Gets messed up when converted to a well-known >> URL. >> Consider the following: >> >> ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=?http=example.com >> >> This would map to: >> >> http://example.com/.well-known/ni/sha-256/t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= >> >> >> The forward slash is not a hierarchy indicator which is bad. Worse still >> this would mean that support for ni digest objects requires a code >> plug in >> for Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to >> the >> directory with the digest values. >> >> >> *Base64url:* >> >> ni:sha-256;t3tjWygyv5Xo8pNZY_E0pB9PEcC-3WztLF5VHyiNmYA >> >> This is essentially the same as base64 for size etc. The only >> disadvantage >> being that the encoder has to be scratch written. (Mine took 20 mins). >> >> The advantage over plain base64 is that there is no code required to >> support >> the .well-known version of the locator scheme on the server at all. Just >> some admin stuff. Also the URL is completely compatible with URI process >> lore. >> >> >> *Summary:* >> >> Arguments can be made for each one of these schemes. I think the argument >> for Base16 is the weakest since Base32 can do everything that Base16 >> can do. >> Neither is implemented as a standard library function on my platform. >> >> If we went for Base32, I would argue for allowing some form of >> readability >> separator. Base32s is much easier to transcribe than plain Base32. >> >> Base64/Base64url offer the best compression in a practical form. For most >> applications a truncated digest will be acceptable. The main >> disadvantage of >> the Base64 schemes is that they are case sensitive. This will play merry >> heck with case insensitive but case preserving file systems such as >> Windows. >> >> I think we should knock out base16 from consideration as base32 does it >> better. >> >> Since it is fairly easy to write a filter that strips out the >> separators, I >> would argue for allowing separators at any point in the identifier but >> that >> the canonical form is with the separators stripped out and this is >> what is >> used to create the URL form. So >> >> ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA >> >> would map to >> >> http://example.com/.well-known/ni/sha-256/W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA >> >> >> This preserves the criteria that Apache, IIS etc can be configured to >> resolve these identifiers without new code. >> >> >> Taking out Base 16 and base32 without separators, I see the following >> options: >> >> Base32s only >> Base64 only >> Base64url only >> Base32s + Base64url >> >> I can see pros and cons for the base32 encoding. To make it really >> readable >> it is necessary to put in the separators which is something of an >> overhead. >> So I can see an argument for both. >> >> But if we only pick one I would say take base32 with separators. It is >> not >> the most compact but it is good enough. It is fully URL compatible and >> has >> the readability benefit. >> >> >> Here is Base32 in C#: >> >> string ToBase32String(byte[] data, int Length) { >> string result = ""; >> int offset = 0; >> int a = 0; >> >> for (int i = 0; i< Length; i++) { >> a = (a<< 8) | data[i]; >> offset += 8; >> >> while (offset>= 5) { >> offset -= 5; >> >> int n = a>> offset; >> result = result + BASE32[n]; >> a = a& (0x1f>> (5 - offset)); >> } >> } >> >> if (offset> 0) { >> result = result + BASE32[a]; >> } >> return result; >> } >> >> Here is base64url in C#: >> >> string ToBase64urlString(byte[] data, int Length) { >> string result = ""; >> int offset = 0; >> int a = 0; >> >> for (int i = 0; i< Length; i++) { >> a = (a<< 8) | data[i]; >> offset += 8; >> >> //Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result, >> offset); >> >> while (offset>= 6) { >> offset -= 6; >> >> int n = a>> offset; >> result = result + BASE64URL[n]; >> a = a& (0x3f>> (6 - offset)); >> } >> } >> if (offset> 0) { >> result = result + BASE64URL[a]; >> } >> return result; >> } >> >> >> >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From stephen.farrell@cs.tcd.ie Fri Oct 7 04:46:07 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D960E21F8ADC; Fri, 7 Oct 2011 04:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvKz1GcoGDhT; Fri, 7 Oct 2011 04:46:07 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1D84421F893C; Fri, 7 Oct 2011 04:46:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C651C171C9B; Fri, 7 Oct 2011 12:49:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1317988155; bh=4fCIEuBE/GR0xh aFp8n+ehl2/TrbYl5uCqkU5ee3Gdk=; b=nmd/o0na46quSlhfXkSXx3ROIIJyTY o6rHFlayj9OcjatKcezGPsGh3lro7m9TaaFg70aGkDszDDRkJCZbQ/HbRAygcR4f fO/f0SCTMI2jQ1961FmjpRWQw8xk2PTMwQJ0Gx+BxRCkDEMaxyHR1Z8tICZ2UtFd uDWlXdTproNVcDcskzA1fnJDuFKBBCHLVnQqr8cnVx0smVEJhkMygz9YMPDsoJhI 7+dDn5S5/xP/BNoE4ev4NlEuW+jZCARC/zsgYvFlT9air77CxSbRgxfx7VrJvei3 dofj3SVgzjZZYvbKn1u953NpOml0YMzeb0Emp1bX+RZvso6TgqKXG9Yw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id SWrsxcqISJrG; Fri, 7 Oct 2011 12:49:15 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B8B15171C43; Fri, 7 Oct 2011 12:49:13 +0100 (IST) Message-ID: <4E8EE72E.8070809@cs.tcd.ie> Date: Fri, 07 Oct 2011 12:49:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <4E8EBE4E.2040203@cs.tcd.ie> <4E8EE110.9090502@it.aoyama.ac.jp> In-Reply-To: <4E8EE110.9090502@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: websec , decade@ietf.org Subject: Re: [decade] [websec] Digest: Adventures in encoding X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 11:46:08 -0000 On 10/07/2011 12:22 PM, "Martin J. Dürst" wrote: > Hello Stephen, > > On 2011/10/07 17:54, Stephen Farrell wrote: >> >> Hi Phill, >> >> Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by >> [W3C.REC-html401-19991224]" all over the place to solve basically >> this problem but in the context of HTTP URLs which has to be worse >> than for a new URI scheme. >> >> Why not do the same here? > > Are you thinking about this for escaping characters such as slashes? Right. Sorry I should've been clearer. I meant use base64 like pretty much all other crypyo->text stuff and then do the application/x-www-form-urlencoded thing. > As for Phil's original ideas, if there's a security issue with > distinguishing upper- and lowercase filenames on Windows, then > abandoning base64 may be a good idea. I wouldn't know of and couldn't > imagine a structural security issue, but then I'm no security expert, > but there's certainly some erosion, up to one bit per 6 bits if all of > the characters are alphabetic. I don't know of a real use-case where windows case sensitive file names are a real issue. > What I still don't understand is where the pressure for having to have > the digest and part of the URI path needing to be the same comes from. > If I want to have a digest protection for a page directly at > http://www.example.org/, shouldn't I be able to do so? I tried to ask > about this previously, but I still didn't get the point, sorry. I'm not sure what you're asking;-) But, if we use b64+form encoding then does this question go away? S. From hallam@gmail.com Fri Oct 7 08:18:18 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6ED21F8ABE; Fri, 7 Oct 2011 08:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr2rOveHq7TO; Fri, 7 Oct 2011 08:18:14 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFEB21F888A; Fri, 7 Oct 2011 08:18:14 -0700 (PDT) Received: by ggnk3 with SMTP id k3so3479514ggn.31 for ; Fri, 07 Oct 2011 08:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0WhVXQkOjRLcgFA7g4Z53t8VF0paqYtieJDVRe2Hu58=; b=CTF3aP/B6wHyda+ctnN8S6SRZQk+mvR0BXuIyhFyRQZNRP/nUl6bXGACduClAQiAmu OBOlr/+xz/D8nRKdwNK7hqKXpIzUaoPaEVsNxl3nWP41NQjdOo2FZJmHouV7YsCAqWkk sjvwIMbiz4sCj8jcYZIqYiy0t015CMSP5m1GY= MIME-Version: 1.0 Received: by 10.100.18.21 with SMTP id 21mr1560011anr.118.1318000888097; Fri, 07 Oct 2011 08:21:28 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Fri, 7 Oct 2011 08:21:28 -0700 (PDT) In-Reply-To: <4E8EBE4E.2040203@cs.tcd.ie> References: <4E8EBE4E.2040203@cs.tcd.ie> Date: Fri, 7 Oct 2011 11:21:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=0016e6476472bfad5f04aeb6fe76 Cc: decade@ietf.org, websec Subject: Re: [decade] Digest: Adventures in encoding X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 15:18:18 -0000 --0016e6476472bfad5f04aeb6fe76 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 7, 2011 at 4:54 AM, Stephen Farrell wrote: > > Hi Phill, > > Oauth [1] uses ""application/x-www-form-**urlencoded" format as defined by > [W3C.REC-html401-19991224]" all over the place to solve basically > this problem but in the context of HTTP URLs which has to be worse > than for a new URI scheme. > > Why not do the same here? > > S. > > [1] http://tools.ietf.org/html/**draft-ietf-oauth-v2-22#**section-4.1.1 That works for me. It is easy enough to do in scripting. May even be possible to use the plain base64 in the ni form of the identifier and form encode it when using it to form a URL (or whatever else required in a protocol). -- Website: http://hallambaker.com/ --0016e6476472bfad5f04aeb6fe76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 7, 2011 at 4:54 AM, Stephen Farrell <= stephen.farrell@cs.tcd.ie&= gt; wrote:

Hi Phill,

Oauth [1] uses ""application/x-www-form-urlencoded" f= ormat as defined by
[W3C.REC-html401-19991224]" all over the place to solve basically
this problem but in the context of HTTP URLs which has to be worse
than for a new URI scheme.

Why not do the same here?

S.

[1] http://tools.ietf.org/html/draft-ietf-oauth-v= 2-22#section-4.1.1

That works fo= r me. It is easy enough to do in scripting.

May even be possible to use the plain base64 in t= he ni form of the identifier and form encode it when using it to form a URL= (or whatever else required in a protocol).


--
Website: http://hallambake= r.com/

--0016e6476472bfad5f04aeb6fe76-- From hallam@gmail.com Fri Oct 7 08:41:27 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B18421F8C59; Fri, 7 Oct 2011 08:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIPEGqQkCyCn; Fri, 7 Oct 2011 08:41:23 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id F386B21F8C58; Fri, 7 Oct 2011 08:41:22 -0700 (PDT) Received: by ggnk3 with SMTP id k3so3505908ggn.31 for ; Fri, 07 Oct 2011 08:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zZw8qKv4tUTebjVT2CACbL5O7FGrJoMOhp5keBYu8rI=; b=u1optjdr6Ikzm/gRutosMlGCzLDLiIa+QRPOHhNUiF8/DtIwjbyoQ3TOsXTAkCXBLX R8WR4Txz+Pg//2btfjnjmUOa1DVBfNuArbmS650Ad3wiR53Y5a02VvE6Ndm47TM6bjV/ 0VI2x3VnytKPtYxasldihY0JIJapTrq4Rrwiw= MIME-Version: 1.0 Received: by 10.101.169.16 with SMTP id w16mr368490ano.74.1318002276554; Fri, 07 Oct 2011 08:44:36 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Fri, 7 Oct 2011 08:44:36 -0700 (PDT) In-Reply-To: <4E8EE110.9090502@it.aoyama.ac.jp> References: <4E8EBE4E.2040203@cs.tcd.ie> <4E8EE110.9090502@it.aoyama.ac.jp> Date: Fri, 7 Oct 2011 11:44:36 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=001636c92c9881d74204aeb751c9 Cc: decade@ietf.org, websec Subject: Re: [decade] [websec] Digest: Adventures in encoding X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 15:41:27 -0000 --001636c92c9881d74204aeb751c9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 7, 2011 at 7:22 AM, "Martin J. D=FCrst" wrote: > > As for Phil's original ideas, if there's a security issue with > distinguishing upper- and lowercase filenames on Windows, then abandoning > base64 may be a good idea. I wouldn't know of and couldn't imagine a > structural security issue, but then I'm no security expert, but there's > certainly some erosion, up to one bit per 6 bits if all of the characters > are alphabetic. > It may not be too much of an issue. Windows probably couldn't cope with 2^6= 4 files in one directory, let alone 2^128 so there would have to be some post-processing on the back end for those cases. > As for Base32, I don't like it too much because it seems to be totally ne= w, > and I prefer using existing stuff if it's good enough. This may show up i= n > code. In scripting languages (think Perl, Ruby,...), Base64 and Base16 ar= e > simple pack operations, and Base64url is a pack and a tr, but Base32 need= s > handcoding. Also, Base32 aligns 8 characters to 5 bytes, Base64 4 charact= ers > to 3 bytes, and Base16 2 characters to 1 byte, and I somehow prefer a mor= e > regular alignment (although the reason for this may be that I never > completely figured out how to handle the non-aligned stuff at the end). > It just drops out with zero bits padding the last chunk. The code is not complex, about 10 lines for the inner loop. > As for the Base32 with slashes, why not just leave the choice of having > slashes or not to the creator, and require the consumer to take them out = (as > Phil proposed anyway). But with the "slashes being taken out" I don't > understand Phil's argument about direct mapping to file names. > It is probably a separate use case to DECADE. I was thinking we might need it in WebSec - possibly. For example, imagine that we have an attack going on with Bank of Ethel and Ethel is asking me to push out a security policy in our AV system by telephone. I have tried reading Base64 over the telephone and it is not a pleasant thing to do. > On the other hand, I think allowing both Base32s and Base64url is a > non-starter. Why have two if one is good enough? And then you can't map t= o > URI paths because somebody could transform the digest from one version to > another to squeeze it. > Well the pragmatic issue is that I am holding up someone who is wanting to write code. So if I take a guess and it is wrong we end up with a legacy issue :-( We do have an escape hole though. The separator between the algorithm and the data. That can be used as an encoding switch. So we can use ; for one encoding, | for another and so on. For forwards compatibility we can require the interim stuff to accept both encodings and decode form encoding and to generate base64 by default but be capable of emitting base32 and formencode(base64)). > What I still don't understand is where the pressure for having to have th= e > digest and part of the URI path needing to be the same comes from. If I w= ant > to have a digest protection for a page directly at http://www.example.org= /, > shouldn't I be able to do so? I tried to ask about this previously, but I > still didn't get the point, sorry. > Ah the issue there is that if the browser has the necessary smarts it can look at: ">This is a strong link to static content And determine that the URL is a strong link and apply appropriate processin= g when in strict mode (or whatever). This link is 100% backwards compatible with existing browsers. all it does is to add in some extra semantics. So for the 'strong link' application, browsers would not need to support th= e ni: scheme at all and it would not be necessary to provide different conten= t according to whether the browser did or did not understand the content. > Regards, Martin. > > S. >> >> [1] http://tools.ietf.org/html/**draft-ietf-oauth-v2-22#**section-4.1.1<= http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.1> >> >> On 10/07/2011 03:49 AM, Phillip Hallam-Baker wrote: >> >>> Following on the base16/base64 discussion, I have written some code (se= e >>> end) and have some ni digests in various flavors of encoding. >>> >>> My conclusion is that we should split the difference and do base32 >>> instead. >>> I think the arguments are actually quite compelling. >>> >>> This is only an encoding issue. So choosing an encoding that requires t= he >>> least number of systems to be touched is my priority. Choosing base32 >>> allows >>> the resolution scheme to be supported by unmodified Apache and IIS. >>> >>> The additional code burden for ni/digest implementers to write base32 i= s >>> trivial >>> >>> >>> There is also the option of doing more than one encoding. But Base64 ur= is >>> are only slightly shorter. >>> >>> >>> *Base16* >>> ni:sha-256;**B77B635B2832BF95E8F2935963F134** >>> A41F4F11C0BEDD6CED2C5E551F288D**9980 >>> >>> >>> Problem - very long even without separators. >>> >>> >>> *Base32:* >>> ni:sha-256;**W5AGGABIGKAJLAHSSNAGHABUUQAE6A**GAX3AGZABMLZAB6AENTGAA >>> >>> Advantage: more compact than Base16 (somewhat), can be read out over a >>> telephone or terminal room (try that with Base64). Can be printed as a >>> static reference in a journal or equivalent. >>> >>> >>> *Base32s:* >>> ni:sha-256;W5AGGA-BIGKAJ-**LAHSSNA-GHABUU-QAE6AGA-X3AGZA-** >>> BMLZAB-6AENTGAA >>> >>> This is my own invention, basically Base32 with separators added for >>> readability. >>> >>> >>> *Base64:* >>> ni:sha-256;t3tjWygyv5Xo8pNZY/**E0pB9PEcC+3WztLF5VHyiNmYA=3D >>> >>> This is the traditional base64 encoding. >>> >>> Process disadvantage: You know that someone is bound to challenge the >>> forward slash just as the document gets to last call. I don't see an >>> advantage to risk a discuss. >>> >>> Practical disadvantage: Gets messed up when converted to a well-known >>> URL. >>> Consider the following: >>> >>> ni:sha-256;t3tjWygyv5Xo8pNZY/**E0pB9PEcC+3WztLF5VHyiNmYA=3D?**http=3D >>> example.com >>> >>> This would map to: >>> >>> http://example.com/.well-**known/ni/sha-256/** >>> t3tjWygyv5Xo8pNZY/E0pB9PEcC+**3WztLF5VHyiNmYA=3D >>> >>> >>> The forward slash is not a hierarchy indicator which is bad. Worse stil= l >>> this would mean that support for ni digest objects requires a code >>> plug in >>> for Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to >>> the >>> directory with the digest values. >>> >>> >>> *Base64url:* >>> >>> ni:sha-256;t3tjWygyv5Xo8pNZY_**E0pB9PEcC-3WztLF5VHyiNmYA >>> >>> This is essentially the same as base64 for size etc. The only >>> disadvantage >>> being that the encoder has to be scratch written. (Mine took 20 mins). >>> >>> The advantage over plain base64 is that there is no code required to >>> support >>> the .well-known version of the locator scheme on the server at all. Jus= t >>> some admin stuff. Also the URL is completely compatible with URI proces= s >>> lore. >>> >>> >>> *Summary:* >>> >>> Arguments can be made for each one of these schemes. I think the argume= nt >>> for Base16 is the weakest since Base32 can do everything that Base16 >>> can do. >>> Neither is implemented as a standard library function on my platform. >>> >>> If we went for Base32, I would argue for allowing some form of >>> readability >>> separator. Base32s is much easier to transcribe than plain Base32. >>> >>> Base64/Base64url offer the best compression in a practical form. For mo= st >>> applications a truncated digest will be acceptable. The main >>> disadvantage of >>> the Base64 schemes is that they are case sensitive. This will play merr= y >>> heck with case insensitive but case preserving file systems such as >>> Windows. >>> >>> I think we should knock out base16 from consideration as base32 does it >>> better. >>> >>> Since it is fairly easy to write a filter that strips out the >>> separators, I >>> would argue for allowing separators at any point in the identifier but >>> that >>> the canonical form is with the separators stripped out and this is >>> what is >>> used to create the URL form. So >>> >>> ni:sha-256;W5AGGA-BIGKAJ-**LAHSSNA-GHABUU-QAE6AGA-X3AGZA-** >>> BMLZAB-6AENTGAA >>> >>> would map to >>> >>> http://example.com/.well-**known/ni/sha-256/** >>> W5AGGABIGKAJLAHSSNAGHABUUQAE6A**GAX3AGZABMLZAB6AENTGAA >>> >>> >>> This preserves the criteria that Apache, IIS etc can be configured to >>> resolve these identifiers without new code. >>> >>> >>> Taking out Base 16 and base32 without separators, I see the following >>> options: >>> >>> Base32s only >>> Base64 only >>> Base64url only >>> Base32s + Base64url >>> >>> I can see pros and cons for the base32 encoding. To make it really >>> readable >>> it is necessary to put in the separators which is something of an >>> overhead. >>> So I can see an argument for both. >>> >>> But if we only pick one I would say take base32 with separators. It is >>> not >>> the most compact but it is good enough. It is fully URL compatible and >>> has >>> the readability benefit. >>> >>> >>> Here is Base32 in C#: >>> >>> string ToBase32String(byte[] data, int Length) { >>> string result =3D ""; >>> int offset =3D 0; >>> int a =3D 0; >>> >>> for (int i =3D 0; i< Length; i++) { >>> a =3D (a<< 8) | data[i]; >>> offset +=3D 8; >>> >>> while (offset>=3D 5) { >>> offset -=3D 5; >>> >>> int n =3D a>> offset; >>> result =3D result + BASE32[n]; >>> a =3D a& (0x1f>> (5 - offset)); >>> } >>> } >>> >>> if (offset> 0) { >>> result =3D result + BASE32[a]; >>> } >>> return result; >>> } >>> >>> Here is base64url in C#: >>> >>> string ToBase64urlString(byte[] data, int Length) { >>> string result =3D ""; >>> int offset =3D 0; >>> int a =3D 0; >>> >>> for (int i =3D 0; i< Length; i++) { >>> a =3D (a<< 8) | data[i]; >>> offset +=3D 8; >>> >>> //Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result, >>> offset); >>> >>> while (offset>=3D 6) { >>> offset -=3D 6; >>> >>> int n =3D a>> offset; >>> result =3D result + BASE64URL[n]; >>> a =3D a& (0x3f>> (6 - offset)); >>> } >>> } >>> if (offset> 0) { >>> result =3D result + BASE64URL[a]; >>> } >>> return result; >>> } >>> >>> >>> >>> ______________________________**_________________ >>> decade mailing list >>> decade@ietf.org >>> https://www.ietf.org/mailman/**listinfo/decade >>> >> ______________________________**_________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/**listinfo/websec >> >> --=20 Website: http://hallambaker.com/ --001636c92c9881d74204aeb751c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 7, 2011 at 7:22 AM, "Martin J. D=FCrst" <duerst@it.aoyama.ac.jp> wrote:

As for Phil's original ideas, if there's a security issue with dist= inguishing upper- and lowercase filenames on Windows, then abandoning base6= 4 may be a good idea. I wouldn't know of and couldn't imagine a str= uctural security issue, but then I'm no security expert, but there'= s certainly some erosion, up to one bit per 6 bits if all of the characters= are alphabetic.

It may not be too much of an issue. Window= s probably couldn't cope with 2^64 files in one directory, let alone 2^= 128 so there would have to be some post-processing on the back end for thos= e cases.

=A0
As for Base32, I don't like it too much because it seems to be totally = new, and I prefer using existing stuff if it's good enough. This may sh= ow up in code. In scripting languages (think Perl, Ruby,...), Base64 and Ba= se16 are simple pack operations, and Base64url is a pack and a tr, but Base= 32 needs handcoding. Also, Base32 aligns 8 characters to 5 bytes, Base64 4 = characters to 3 bytes, and Base16 2 characters to 1 byte, and I somehow pre= fer a more regular alignment (although the reason for this may be that I ne= ver completely figured out how to handle the non-aligned stuff at the end).=

It just drops out with zero bits padding t= he last chunk.

The code is not complex, about 10 l= ines for the inner loop.

=A0
As for the Base32 with slashes, why not just leave the choice of having sla= shes or not to the creator, and require the consumer to take them out (as P= hil proposed anyway). But with the "slashes being taken out" I do= n't understand Phil's argument about direct mapping to file names.<= br>

It is probably a separate use case to DECA= DE. I was thinking we might need it in WebSec - possibly.

For example, imagine that we have an attack going on with Bank of E= thel and Ethel is asking me to push out a security policy in our AV system = by telephone. I have tried reading Base64 over the telephone and it is not = a pleasant thing to do.

=A0
On the other hand, I think allowing both Base32s and Base64url is a non-sta= rter. Why have two if one is good enough? And then you can't map to URI= paths because somebody could transform the digest from one version to anot= her to squeeze it.

Well the pragmatic issue is that I am hold= ing up someone who is wanting to write code. So if I take a guess and it is= wrong we end up with a legacy issue :-(

We do hav= e an escape hole though. The separator between the algorithm and the data. = That can be used as an encoding switch.

So we can use ; for one encoding, | for another and so = on.


For forwards compatibility we c= an require the interim stuff to accept both encodings and decode form encod= ing and to generate base64 by default but be capable of emitting base32 and= formencode(base64)).=A0

=A0
What I still don't understand is where the pressure for having to have = the digest and part of the URI path needing to be the same comes from. If I= want to have a digest protection for a page directly at http://www.example.org/, shouldn= 9;t I be able to do so? I tried to ask about this previously, but I still d= idn't get the point, sorry.

Ah the issue there is that if the browser = has the necessary smarts it can look at:


And determine that the URL is a strong= link and apply appropriate processing when in strict mode (or whatever).


This link is 100% backwards compatible with existing= browsers. all it does is to add in some extra semantics.

So for the 'strong link' appli= cation, browsers would not need to support the ni: scheme at all and it wou= ld not be necessary to provide different content according to whether the b= rowser did or did not understand the content.

=A0
Regards, =A0 Martin.

S.

[1] http://tools.ietf.org/html/draft-ietf-oauth-v= 2-22#section-4.1.1

On 10/07/2011 03:49 AM, Phillip Hallam-Baker wrote:
Following on the base16/base64 discussion, I have written some code (see end) and have some ni digests in various flavors of encoding.

My conclusion is that we should split the difference and do base32
instead.
I think the arguments are actually quite compelling.

This is only an encoding issue. So choosing an encoding that requires the least number of systems to be touched is my priority. Choosing base32
allows
the resolution scheme to be supported by unmodified Apache and IIS.

The additional code burden for ni/digest implementers to write base32 is trivial


There is also the option of doing more than one encoding. But Base64 uris are only slightly shorter.


*Base16*
ni:sha-256;B77B635B2832BF95E8F2935963F134A41F4F11C0BEDD6CED2C= 5E551F288D9980


Problem - very long even without separators.


*Base32:*
ni:sha-256;W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTG= AA

Advantage: more compact than Base16 (somewhat), can be read out over a
telephone or terminal room (try that with Base64). Can be printed as a
static reference in a journal or equivalent.


*Base32s:*
ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB= -6AENTGAA

This is my own invention, basically Base32 with separators added for
readability.


*Base64:*
ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=3D

This is the traditional base64 encoding.

Process disadvantage: You know that someone is bound to challenge the
forward slash just as the document gets to last call. I don't see an advantage to risk a discuss.

Practical disadvantage: Gets messed up when converted to a well-known
URL.
Consider the following:

ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=3D?htt= p=3Dexample.com

This would map to:

http://example.com/.well-known/ni/sha-256/t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= =3D


The forward slash is not a hierarchy indicator which is bad. Worse still this would mean that support for ni digest objects requires a code
plug in
for Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to
the
directory with the digest values.


*Base64url:*

ni:sha-256;t3tjWygyv5Xo8pNZY_E0pB9PEcC-3WztLF5VHyiNmYA

This is essentially the same as base64 for size etc. The only
disadvantage
being that the encoder has to be scratch written. (Mine took 20 mins).

The advantage over plain base64 is that there is no code required to
support
the .well-known version of the locator scheme on the server at all. Just some admin stuff. Also the URL is completely compatible with URI process lore.


*Summary:*

Arguments can be made for each one of these schemes. I think the argument for Base16 is the weakest since Base32 can do everything that Base16
can do.
Neither is implemented as a standard library function on my platform.

If we went for Base32, I would argue for allowing some form of
readability
separator. Base32s is much easier to transcribe than plain Base32.

Base64/Base64url offer the best compression in a practical form. For most applications a truncated digest will be acceptable. The main
disadvantage of
the Base64 schemes is that they are case sensitive. This will play merry heck with case insensitive but case preserving file systems such as
Windows.

I think we should knock out base16 from consideration as base32 does it
better.

Since it is fairly easy to write a filter that strips out the
separators, I
would argue for allowing separators at any point in the identifier but
that
the canonical form is with the separators stripped out and this is
what is
used to create the URL form. So

ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB= -6AENTGAA

would map to

http://example.com/.well-= known/ni/sha-256/W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZ= ABMLZAB6AENTGAA


This preserves the criteria that Apache, IIS etc can be configured to
resolve these identifiers without new code.


Taking out Base 16 and base32 without separators, I see the following
options:

Base32s only
Base64 only
Base64url only
Base32s + Base64url

I can see pros and cons for the base32 encoding. To make it really
readable
it is necessary to put in the separators which is something of an
overhead.
So I can see an argument for both.

But if we only pick one I would say take base32 with separators. It is
not
the most compact but it is good enough. It is fully URL compatible and
has
the readability benefit.


Here is Base32 in C#:

string ToBase32String(byte[] data, int Length) {
string result =3D "";
int offset =3D 0;
int a =3D 0;

for (int i =3D 0; i< Length; i++) {
a =3D (a<< 8) | data[i];
offset +=3D 8;

while (offset>=3D 5) {
offset -=3D 5;

int n =3D a>> offset;
result =3D result + BASE32[n];
a =3D a& (0x1f>> (5 - offset));
}
}

if (offset> 0) {
result =3D result + BASE32[a];
}
return result;
}

Here is base64url in C#:

string ToBase64urlString(byte[] data, int Length) {
string result =3D "";
int offset =3D 0;
int a =3D 0;

for (int i =3D 0; i< Length; i++) {
a =3D (a<< 8) | data[i];
offset +=3D 8;

//Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result,
offset);

while (offset>=3D 6) {
offset -=3D 6;

int n =3D a>> offset;
result =3D result + BASE64URL[n];
a =3D a& (0x3f>> (6 - offset));
}
}
if (offset> 0) {
result =3D result + BASE64URL[a];
}
return result;
}



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




--
Website: http://hallambaker.com/

--001636c92c9881d74204aeb751c9-- From stephen.farrell@cs.tcd.ie Fri Oct 7 08:42:33 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5FB21F86D0; Fri, 7 Oct 2011 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAM4oXGnJU7I; Fri, 7 Oct 2011 08:42:29 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4D93221F87D9; Fri, 7 Oct 2011 08:42:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C9EA6171C9B; Fri, 7 Oct 2011 16:45:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1318002339; bh=0rc2SiQmV6Rw3a CJIcuBFNfo7z3FxDG12nqh3ZBitd8=; b=hXm+GHeOi4auP34VanbpmX3oVbrmao pX5swrhT6xaVAs2jEpvJxY0UzeyjYeENRMuqx3ofudKEjyLN3cgFFVG2uiVHDjnl tzIgN2Ck76CoNhP6isiS4YWQJvhL2dMiB+evqlGpxvnwgQ95MYKRDfmQmx8nADP1 XbTDrWfTBoiy1/N76hJsQkb8/l9stJAYgI2X0EivB6gDgMuM0bwGyNHA0yagkgcz NDRM8exNiWd+trS1qi7iqaYZ9wVBh5cKiMY+YcVL43anZSM7atKZhfuBs+3fdXn/ JwdSg2k2Df8HcUI0Udb2s6ZiJq2TfUv4PHDRY9GhcgYoBjS8GDt6VYdw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id KpDXnfow-8sr; Fri, 7 Oct 2011 16:45:39 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6B4BD171C43; Fri, 7 Oct 2011 16:45:39 +0100 (IST) Message-ID: <4E8F1E92.8090700@cs.tcd.ie> Date: Fri, 07 Oct 2011 16:45:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4E8EBE4E.2040203@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: decade@ietf.org, websec Subject: Re: [decade] Digest: Adventures in encoding X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 15:42:33 -0000 On 10/07/2011 04:21 PM, Phillip Hallam-Baker wrote: > On Fri, Oct 7, 2011 at 4:54 AM, Stephen Farrell > wrote: > >> >> Hi Phill, >> >> Oauth [1] uses ""application/x-www-form-**urlencoded" format as defined by >> [W3C.REC-html401-19991224]" all over the place to solve basically >> this problem but in the context of HTTP URLs which has to be worse >> than for a new URI scheme. >> >> Why not do the same here? >> >> S. >> >> [1] http://tools.ietf.org/html/**draft-ietf-oauth-v2-22#**section-4.1.1 > > > That works for me. It is easy enough to do in scripting. > > May even be possible to use the plain base64 in the ni form of the > identifier and form encode it when using it to form a URL (or whatever else > required in a protocol). Actually, you're right - that's better. Just use b64 here and note that protocols might have to urlencode. If it turns out to be a problem we can fix later. S. > > From hallam@gmail.com Fri Oct 7 09:37:58 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9629C21F8C1D; Fri, 7 Oct 2011 09:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjwcfmRt0Zq3; Fri, 7 Oct 2011 09:37:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B52A621F8BFB; Fri, 7 Oct 2011 09:37:57 -0700 (PDT) Received: by gyd12 with SMTP id 12so4595539gyd.31 for ; Fri, 07 Oct 2011 09:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lPeCwT5o29/UZ4M1/LSQCa+rEQy3Xm9Rl2O4gAfl4vg=; b=tz66cN9w7B23krPL8u0Zz1w+jBP04wn+xB3XoDCSuvi65Nm9OovE5Yg0cNRJDq+Yom rTvLQAoCTtbxkEj71ogtsnf5U6+kDG2+VWq5apM9jkzS3ToP/sTMB6sTIoYb838RWW7q 2gHKpK9jB8biQMUYq5Wof9gJ4jAwWNwlgzQIk= MIME-Version: 1.0 Received: by 10.100.18.21 with SMTP id 21mr1649451anr.118.1318005670463; Fri, 07 Oct 2011 09:41:10 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Fri, 7 Oct 2011 09:41:10 -0700 (PDT) In-Reply-To: <4E8F1E92.8090700@cs.tcd.ie> References: <4E8EBE4E.2040203@cs.tcd.ie> <4E8F1E92.8090700@cs.tcd.ie> Date: Fri, 7 Oct 2011 12:41:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=0016e6476472ccca4904aeb81b8a Cc: decade@ietf.org, websec Subject: Re: [decade] Digest: Adventures in encoding X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 16:37:58 -0000 --0016e6476472ccca4904aeb81b8a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 7, 2011 at 11:45 AM, Stephen Farrell wrote: > > > On 10/07/2011 04:21 PM, Phillip Hallam-Baker wrote: > >> On Fri, Oct 7, 2011 at 4:54 AM, Stephen Farrell >> **wrote: >> >> >>> Hi Phill, >>> >>> Oauth [1] uses ""application/x-www-form-****urlencoded" format as >>> defined by >>> [W3C.REC-html401-19991224]" all over the place to solve basically >>> this problem but in the context of HTTP URLs which has to be worse >>> than for a new URI scheme. >>> >>> Why not do the same here? >>> >>> S. >>> >>> [1] http://tools.ietf.org/html/****draft-ietf-oauth-v2-22#**** >>> section-4.1.1 >>> >>> > >>> >> >> >> That works for me. It is easy enough to do in scripting. >> >> May even be possible to use the plain base64 in the ni form of the >> identifier and form encode it when using it to form a URL (or whatever >> else >> required in a protocol). >> > > Actually, you're right - that's better. Just use b64 here and note > that protocols might have to urlencode. If it turns out to be a > problem we can fix later. > Given that the requirement is a SHOULD, a draft that demonstrates that the point was considered should be enough to avoid time in the DISCUSS penalty box. -- Website: http://hallambaker.com/ --0016e6476472ccca4904aeb81b8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 7, 2011 at 11:45 AM, Stephen= Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 10/07/2011 04:21 PM, Phillip Hallam-Baker wrote:
On Fri, Oct 7, 2011 at 4:54 AM, Stephen Farrell
<stephen.= farrell@cs.tcd.ie>wrote:


Hi Phill,

Oauth [1] uses ""application/x-www-form-**urlencoded"= format as defined by
[W3C.REC-html401-19991224]" all over the place to solve basically
this problem but in the context of HTTP URLs which has to be worse
than for a new URI scheme.

Why not do the same here?

S.

[1] http://tools.ietf.org/html/**draft-ietf-o= auth-v2-22#**section-4.1.1<http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.1>


That works for me. It is easy enough to do in scripting.

May even be possible to use the plain base64 in the ni form of the
identifier and form encode it when using it to form a URL (or whatever else=
required in a protocol).

Actually, you're right - that's better. Just use b64 here and note<= br> that protocols might have to urlencode. If it turns out to be a
problem we can fix later.

Given that th= e requirement is a SHOULD, a draft that demonstrates that the point was con= sidered should be enough to avoid time in the DISCUSS penalty box.


--
Website: http://hallambaker.com/

--0016e6476472ccca4904aeb81b8a-- From julian.reschke@gmx.de Fri Oct 7 09:44:39 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2690721F8CAE for ; Fri, 7 Oct 2011 09:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.249 X-Spam-Level: X-Spam-Status: No, score=-104.249 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayBevh30ZBQL for ; Fri, 7 Oct 2011 09:44:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 335B321F8C97 for ; Fri, 7 Oct 2011 09:44:38 -0700 (PDT) Received: (qmail invoked by alias); 07 Oct 2011 16:47:51 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp043) with SMTP; 07 Oct 2011 18:47:51 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19OW3IkwoNO604qh8f2ELdvLBTttw0rIzEwAm6UVp Ns6VSXNGKkZ0/z Message-ID: <4E8F2D35.2060806@gmx.de> Date: Fri, 07 Oct 2011 18:47:49 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <4E8EBE4E.2040203@cs.tcd.ie> In-Reply-To: <4E8EBE4E.2040203@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Fri, 07 Oct 2011 10:07:24 -0700 Cc: websec , decade@ietf.org Subject: Re: [decade] [websec] Digest: Adventures in encoding X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 16:44:39 -0000 On 2011-10-07 10:54, Stephen Farrell wrote: > > Hi Phill, > > Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by > [W3C.REC-html401-19991224]" all over the place to solve basically > this problem but in the context of HTTP URLs which has to be worse > than for a new URI scheme. > > Why not do the same here? > ... ...because the definition is vague with respect to non-ASCII (that *is* a problem for OAuth, but might be ok here), and because it also leaks the special-casing of SP (encoded as "+") into new areas. If you like the encoding otherwise, then just refer to RFC 3986 for percent-encoding: . Best regards, Julian From richard_woundy@cable.comcast.com Tue Oct 11 07:19:36 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A006121F8DC7 for ; Tue, 11 Oct 2011 07:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.507 X-Spam-Level: X-Spam-Status: No, score=-101.507 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH005gRoklM8 for ; Tue, 11 Oct 2011 07:19:36 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id F230D21F8DBA for ; Tue, 11 Oct 2011 07:19:35 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.56661334; Tue, 11 Oct 2011 08:26:43 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Tue, 11 Oct 2011 10:19:29 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-decade-reqs-04 Thread-Index: Acu+91Byr8CuZlwMSYaaxFnqkg41Dy/qW7BQAl+qvvA= Date: Tue, 11 Oct 2011 14:19:29 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136A2790@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.69.4] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1136A2790PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:19:36 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1136A2790PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder that the WGLC for the DECADE requirements draft (draft-ietf= -decade-reqs-04) ends next Monday October 17. If you think the document is ready to move forward, please state this on th= e list by Monday and not just silently agree. It would also help if our WG expert reviewers (Dave McDysan, Akbar Rahman, = and Borje Ohlman) would confirm that their draft comments were addressed in= this version by Monday. -- Rich From: Woundy, Richard Sent: Thursday, September 29, 2011 8:13 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-reqs-04 Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -reqs-04, http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be co= mpleted by Monday October 17. Please send all concerns, suggestions and com= ments about this internet-draft to the DECADE mailing list, decade@ietf.org= . Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD1136A2790PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder that t= he WGLC for the DECADE requirements draft (draft-ietf-decade-reqs-04) ends = next Monday October 17.

 

If you think the docum= ent is ready to move forward, please state this on the list by Monday and n= ot just silently agree.

 

It would also help if = our WG expert reviewers (Dave McDysan, Akbar Rahman, and Borje Ohlman) woul= d confirm that their draft comments were addressed in this version by Monda= y.

 

-- Rich

 

From: Woundy, = Richard
Sent: Thursday, September 29, 2011 8:13 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-reqs-04

 

Folks,

 

Haibin and I are start= ing the working group last call for draft-ietf-decade-reqs-04, http://= datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by Mo= nday October 17. Please send all concerns, suggestions and comments about t= his internet-draft to the DECADE mailing list, decade@ietf.org.

 

Authors, please do not= make any additional changes to the internet-draft unless directed by the W= G chairs.

 

Draft reviewers, it wo= uld be helpful to get your confirmation that your previous review comments = have been correctly reflected in this version.

 

Thanks.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD1136A2790PACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Tue Oct 11 07:22:39 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0565E21F8D3F for ; Tue, 11 Oct 2011 07:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.984 X-Spam-Level: X-Spam-Status: No, score=-104.984 tagged_above=-999 required=5 tests=[AWL=3.478, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmGnamtcgPJt for ; Tue, 11 Oct 2011 07:22:38 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id A448421F8D9A for ; Tue, 11 Oct 2011 07:22:37 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.142744273; Tue, 11 Oct 2011 10:22:31 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Tue, 11 Oct 2011 10:22:31 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-decade-arch-03 Thread-Index: AQHMfqFCTxqrA0OtdEywpt6h+qbSY5V3iDTA Date: Tue, 11 Oct 2011 14:22:30 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136A27A8@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.69.4] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1136A27A8PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:22:39 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1136A27A8PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder that the WGLC for the DECADE architecture draft (draft-ietf= -decade-arch-03) ends next Monday October 17. If you think the document is ready to move forward, please state this on th= e list by Monday and not just silently agree. It would also help if our WG expert reviewers (Martin Stiemerling, David Mc= Dysan, and Borje Ohlman) would confirm that their draft comments were addre= ssed in this version by Monday. -- Rich From: Woundy, Richard Sent: Thursday, September 29, 2011 8:14 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-arch-03 Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -arch-03, http://datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be co= mpleted by Monday October 17. Please send all concerns, suggestions and com= ments about this internet-draft to the DECADE mailing list, decade@ietf.org= . Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD1136A27A8PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder that t= he WGLC for the DECADE architecture draft (draft-ietf-decade-arch-03) ends = next Monday October 17.

 

If you think the docum= ent is ready to move forward, please state this on the list by Monday and n= ot just silently agree.

 

It would also help if = our WG expert reviewers (Martin Stiemerling, David McDysan, and Borje Ohlma= n) would confirm that their draft comments were addressed in this version b= y Monday.

 

-- Rich

 

From: Woundy, = Richard
Sent: Thursday, September 29, 2011 8:14 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-arch-03

 

Folks,

 

Haibin and I are start= ing the working group last call for draft-ietf-decade-arch-03, http://= datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be completed by Mo= nday October 17. Please send all concerns, suggestions and comments about t= his internet-draft to the DECADE mailing list, decade@ietf.org.

 

Authors, please do not= make any additional changes to the internet-draft unless directed by the W= G chairs.

 

Draft reviewers, it wo= uld be helpful to get your confirmation that your previous review comments = have been correctly reflected in this version.

 

Thanks.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD1136A27A8PACDCEXMB05cabl_-- From Akbar.Rahman@InterDigital.com Tue Oct 11 09:07:36 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC7721F8E7B for ; Tue, 11 Oct 2011 09:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGpofkcnZlMr for ; Tue, 11 Oct 2011 09:07:34 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA8321F8E78 for ; Tue, 11 Oct 2011 09:07:34 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 12:07:33 -0400 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_01CC882F.E21B1FD8" Date: Tue, 11 Oct 2011 12:07:32 -0400 Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136A2790@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Start of WGLC for draft-ietf-decade-reqs-04 Thread-index: Acu+91Byr8CuZlwMSYaaxFnqkg41Dy/qW7BQAl+qvvAAA/8s4A== References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com><1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136A2790@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Woundy, Richard" X-OriginalArrivalTime: 11 Oct 2011 16:07:33.0186 (UTC) FILETIME=[E2813220:01CC882F] Cc: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:07:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC882F.E21B1FD8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard, =20 =20 All the comments from my previous review were addressed in rev -04 of the requirements document. Thanks to the authors for taking care of that. I did however have two new comments on rev -04: =20 =20 Section 4.1.1.1 - Often protocols like STUN are required to account for NATs. I was not sure if this requirement meant that we should NOT use something like STUN as part of the overall DECADE solution (especially for DECADE server to server communications)? Is the real intent to force all DECADE servers to be on the public Internet? If so then perhaps it would be better to re-phrase the requirement? Finally, I was confused by the reason for the separate requirement of 6.1.2 that touched on the same issue. =20 - Section 7 - What does the section title of "Discussion" mean? If there is still open issues then the document should not go to WGLC. If these requirements are solid, then they should be written in the same format as the other sections of the document. =20 =20 http://www.ietf.org/mail-archive/web/decade/current/msg00517.html =20 =20 =20 =20 From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Tuesday, October 11, 2011 10:19 AM To: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 =20 Just a reminder that the WGLC for the DECADE requirements draft (draft-ietf-decade-reqs-04) ends next Monday October 17. =20 If you think the document is ready to move forward, please state this on the list by Monday and not just silently agree. =20 It would also help if our WG expert reviewers (Dave McDysan, Akbar Rahman, and Borje Ohlman) would confirm that their draft comments were addressed in this version by Monday. =20 -- Rich =20 From: Woundy, Richard=20 Sent: Thursday, September 29, 2011 8:13 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-reqs-04 =20 Folks, =20 Haibin and I are starting the working group last call for draft-ietf-decade-reqs-04, http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by Monday October 17. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, decade@ietf.org. =20 Authors, please do not make any additional changes to the internet-draft unless directed by the WG chairs. =20 Draft reviewers, it would be helpful to get your confirmation that your previous review comments have been correctly reflected in this version. =20 Thanks. =20 -- Rich and Haibin ------_=_NextPart_001_01CC882F.E21B1FD8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard,

 

 

All the comments from my = previous review were addressed in rev -04 of the requirements = document.  Thanks to the authors for taking care of that.  I = did however have two new comments on rev -04:

 

 

Section 4.1.1.1 – Often protocols = like STUN are required to account for NATs.  I was not sure if this = requirement meant that we should NOT use something like STUN as part of = the overall DECADE solution (especially for DECADE server to server = communications)?   Is the real intent to force all DECADE = servers to be on the public Internet?  If so then perhaps it would = be better to re-phrase the requirement?  Finally, I was confused by = the reason for the separate requirement of 6.1.2 that touched on the = same issue.

 

-       &= nbsp;  Section 7 – What does the = section title of “Discussion” mean?  If there is still = open issues then the document should not go to WGLC.  If these = requirements are solid, then they should be written in the same format = as the other sections of the document.

 

 

http://www.ietf.org/mail-archive/web/decade/current/msg00517.html

 

 

 

 

From:= = decade-bounces@ietf.org = [mailto:decade-bounces@i= etf.org] On Behalf Of Woundy, Richard
Sent: = Tuesday, October 11, 2011 10:19 AM
To: decade@ietf.org
Subject: = Re: [decade] Start of WGLC for = draft-ietf-decade-reqs-04

 

Just a reminder that the WGLC for the DECADE = requirements draft (draft-ietf-decade-reqs-04) ends next Monday October = 17.

 

If you think the = document is ready to move forward, please state this on the list by = Monday and not just silently agree.

 

It would also help if = our WG expert reviewers (Dave McDysan, Akbar Rahman, and Borje Ohlman) = would confirm that their draft comments were addressed in this version = by Monday.

 

-- = Rich

 

From:= = Woundy, Richard
Sent: Thursday, September 29, 2011 8:13 = AM
To: decade@ietf.org
Cc: = Songhaibin; Woundy, Richard
Subject: Start of WGLC for = draft-ietf-decade-reqs-04

 

Folks,

 

Haibin and I are = starting the working group last call for draft-ietf-decade-reqs-04, http://d= atatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by = Monday October 17. Please send all concerns, suggestions and comments = about this internet-draft to the DECADE mailing list, decade@ietf.org.

 

Authors, please do not = make any additional changes to the internet-draft unless directed by the = WG chairs.

 

Draft reviewers, it = would be helpful to get your confirmation that your previous review = comments have been correctly reflected in this = version.

 

Thanks.

 

-- Rich and = Haibin

------_=_NextPart_001_01CC882F.E21B1FD8-- From internet-drafts@ietf.org Tue Oct 11 23:52:30 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C54721F8C49; Tue, 11 Oct 2011 23:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYG-Kq+W99dM; Tue, 11 Oct 2011 23:52:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297F321F8C39; Tue, 11 Oct 2011 23:52:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111012065230.5237.98873.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2011 23:52:30 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-problem-statement-04.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 06:52:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : DECoupled Application Data Enroute (DECADE) Problem Stat= ement Author(s) : Haibin Song Ning Zong Y. Richard Yang Richard Alimi Filename : draft-ietf-decade-problem-statement-04.txt Pages : 15 Date : 2011-10-11 Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network (the download traffic may increase because the in- network storage is likely much better connected). Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols and cache refreshing mechanisms) and they do not have the feature to allow users to manage access to content in the cache. For example, Content Providers cannot easily control cache access and resource usage policies to satisfy their own requirements. In this document, a content provider is also the user of in-network storage. This document discusses the introduction of in-network storage for P2P applications, and shows the need for a standard protocol for accessing this storage. It can also be used by other applications with similar requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-04.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-04.t= xt From richard_woundy@cable.comcast.com Wed Oct 12 06:59:00 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D814821F8CD2 for ; Wed, 12 Oct 2011 06:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.36 X-Spam-Level: X-Spam-Status: No, score=-103.36 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQLJh1eUCIV4 for ; Wed, 12 Oct 2011 06:59:00 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 49AE921F8CB6 for ; Wed, 12 Oct 2011 06:59:00 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.56828510; Wed, 12 Oct 2011 08:05:59 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Wed, 12 Oct 2011 09:58:49 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: [decade] I-D Action: draft-ietf-decade-problem-statement-04.txt Thread-Index: AQHMiKuHVQ0NSle/+U2Ey5540nSx9pV4uziw Date: Wed, 12 Oct 2011 13:58:48 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136A3C34@PACDCEXMB05.cable.comcast.com> References: <20111012065230.5237.98873.idtracker@ietfa.amsl.com> In-Reply-To: <20111012065230.5237.98873.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.69.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] I-D Action: draft-ietf-decade-problem-statement-04.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 13:59:01 -0000 I would like to request the WG to review this draft version for correctness= and clarity before I take the draft back to our AD. Dave Harrington's AD review comments can be found here: . Obviously we need to ensu= re that this draft is responsive to his comments. -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: Wednesday, October 12, 2011 2:52 AM To: i-d-announce@ietf.org Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-problem-statement-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : DECoupled Application Data Enroute (DECADE) Problem Stat= ement Author(s) : Haibin Song Ning Zong Y. Richard Yang Richard Alimi Filename : draft-ietf-decade-problem-statement-04.txt Pages : 15 Date : 2011-10-11 Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network (the download traffic may increase because the in- network storage is likely much better connected). Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols and cache refreshing mechanisms) and they do not have the feature to allow users to manage access to content in the cache. For example, Content Providers cannot easily control cache access and resource usage policies to satisfy their own requirements. In this document, a content provider is also the user of in-network storage. This document discusses the introduction of in-network storage for P2P applications, and shows the need for a standard protocol for accessing this storage. It can also be used by other applications with similar requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-04.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-04.t= xt _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From zongning@huawei.com Wed Oct 12 16:57:06 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9868C21F8B5D for ; Wed, 12 Oct 2011 16:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS7RT1Kb8s5q for ; Wed, 12 Oct 2011 16:57:05 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7850B21F8B71 for ; Wed, 12 Oct 2011 16:57:05 -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 <0LSZ000A99739R@szxga04-in.huawei.com> for decade@ietf.org; Thu, 13 Oct 2011 07:57:04 +0800 (CST) Received: from szxrg01-dlp.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 <0LSZ00JO99731W@szxga04-in.huawei.com> for decade@ietf.org; Thu, 13 Oct 2011 07:57:03 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ93448; Thu, 13 Oct 2011 07:57:03 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Oct 2011 07:56:57 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.252]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 07:56:57 +0800 Date: Wed, 12 Oct 2011 23:56:57 +0000 From: ZongNing In-reply-to: <1CA25301D2219F40B3AA37201F0EACD1136A27A8@PACDCEXMB05.cable.comcast.com> X-Originating-IP: [10.138.41.128] To: "Woundy, Richard" , "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_sqG5WabksXlJAd2pH8NVfA)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: Start of WGLC for draft-ietf-decade-arch-03 Thread-index: AQHMfqFgze5YeAw2rEyLfQANZAG+xpV2vwwAgAK4kwA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136A27A8@PACDCEXMB05.cable.comcast.com> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 23:57:06 -0000 --Boundary_(ID_sqG5WabksXlJAd2pH8NVfA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I have read the draft and think it forms a good basis for further DECADE protocol design. Yes, I want to see it move forward. BR, Ning Zong From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Tuesday, October 11, 2011 10:23 PM To: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 Just a reminder that the WGLC for the DECADE architecture draft (draft-ietf-decade-arch-03) ends next Monday October 17. If you think the document is ready to move forward, please state this on the list by Monday and not just silently agree. It would also help if our WG expert reviewers (Martin Stiemerling, David McDysan, and Borje Ohlman) would confirm that their draft comments were addressed in this version by Monday. -- Rich From: Woundy, Richard Sent: Thursday, September 29, 2011 8:14 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-arch-03 Folks, Haibin and I are starting the working group last call for draft-ietf-decade-arch-03, http://datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be completed by Monday October 17. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, decade@ietf.org. Authors, please do not make any additional changes to the internet-draft unless directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your previous review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --Boundary_(ID_sqG5WabksXlJAd2pH8NVfA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

I have read the draft and think it forms a good basis for further= DECADE protocol design.

Yes, I want to see it move forward.

 

BR,

Ning Zong

 

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Woundy, Richard
Sent: Tuesday, October 11, 2011 10:23 PM
To: decade@ietf.org
Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03

 

Just a = reminder that the WGLC for the DECADE architecture draft (draft-ietf-decade= -arch-03) ends next Monday October 17.

&n= bsp;

If you = think the document is ready to move forward, please state this on the list = by Monday and not just silently agree.

&n= bsp;

It woul= d also help if our WG expert reviewers (Martin Stiemerling, David McDysan, = and Borje Ohlman) would confirm that their draft comments were addressed in= this version by Monday.

&n= bsp;

-- Rich=

&n= bsp;

From: Woundy, Richard
Sent: Thursday, September 29, 2011 8:14 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-arch-03

 

Folks,<= o:p>

&n= bsp;

Haibin = and I are starting the working group last call for draft-ietf-decade-arch-0= 3, http://= datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be completed by Mo= nday October 17. Please send all concerns, suggestions and comments about t= his internet-draft to the DECADE mailing list, decade@ietf.org.

&n= bsp;

Authors= , please do not make any additional changes to the internet-draft unless di= rected by the WG chairs.

&n= bsp;

Draft r= eviewers, it would be helpful to get your confirmation that your previous r= eview comments have been correctly reflected in this version.

&n= bsp;

Thanks.=

&n= bsp;

-- Rich= and Haibin

--Boundary_(ID_sqG5WabksXlJAd2pH8NVfA)-- From borje.ohlman@ericsson.com Fri Oct 14 04:12:00 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B7421F8B16 for ; Fri, 14 Oct 2011 04:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.071 X-Spam-Level: X-Spam-Status: No, score=-6.071 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISHgGzi8x13b for ; Fri, 14 Oct 2011 04:11:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4B22821F8AF8 for ; Fri, 14 Oct 2011 04:11:59 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4b-4e9818fd0b66 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 24.F3.20773.DF8189E4; Fri, 14 Oct 2011 13:11:58 +0200 (CEST) Received: from dhcp-147-214-183-82.ki.sw.ericsson.se (153.88.115.8) by smtps.internal.ericsson.com (153.88.115.84) with Microsoft SMTP Server id 8.3.137.0; Fri, 14 Oct 2011 13:11:57 +0200 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary="Apple-Mail-16-981100153" From: =?iso-8859-1?Q?B=F6rje_Ohlman?= In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> Date: Fri, 14 Oct 2011 13:11:56 +0200 Message-ID: <1437EB69-B337-4B88-80D8-5BF4FEB42C34@ericsson.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> To: decade ietf X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 11:12:00 -0000 --Apple-Mail-16-981100153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, I think the draft is in very good shape, thanks to the authors for an = excellent job. All my previous comments are addressed by this draft. = However looking through it last night I have some additional comments. ---------- > 5.1. Immutable Data > REQUIREMENT(S): DECADE MUST provide the ability to manage data > objects that are immutable once they are written to storage. I think this requirement is a bit unclear on what is actually meant. My = understanding from our discussions is that DECADE MUST *only* store = immutable data objects. If that is the intention, I think that should be = stated more clearly. I don't think the word "ability" is the best to = express this requirement. An alternative formulation could be: "DECADE MUST only store and manage data objects that are immutable once = they are written to storage." If I have misunderstood the intention of this requirement and that it = should also be possible to store mutable data in DECADE servers, then I = think such an explicit requirement should be added. ------------ > 5.2. Explicit Deletion of Data > REQUIREMENT(S): DECADE MUST support the ability for a DECADE client > to explicitly delete data from its own in-network storage. > RATIONALE: A DECADE client may continually be writing data to its > in-network storage. Since there may be a limit (e.g., imposed by > the storage provider) to how much total storage can be used, some > data may need to be removed to make room for additional data. A > DECADE client should be able to explicitly remove particular > data. This may be implemented using existing protocols. When reading the rationale for this requirement I start to thinking that = we might want to add something about automatic removal of old data = according to some policy, e.g. that DECADE storage servers SHOULD be = able to remove old data according to some policy, e.g. LLRU. This should = be of interest, e.g. when a quota is being filled up, to avoid having to = deny further writings. This should be especially relevant in the = mentioned case of continuous writings, e.g. for streaming data. ----------------- B=F6rje On 29 sep 2011, at 14.12, Woundy, Richard wrote: > Folks, > =20 > Haibin and I are starting the working group last call for = draft-ietf-decade-reqs-04, = http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed = by Monday October 17. Please send all concerns, suggestions and comments = about this internet-draft to the DECADE mailing list, decade@ietf.org. > =20 > Authors, please do not make any additional changes to the = internet-draft unless directed by the WG chairs. > =20 > Draft reviewers, it would be helpful to get your confirmation that = your previous review comments have been correctly reflected in this = version. > =20 > Thanks. > =20 > -- Rich and Haibin > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade --Apple-Mail-16-981100153 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" Hi,

I think the draft is in very = good shape, thanks to the authors for an excellent job. All my previous = comments are addressed by this draft. However looking through it last = night I have some additional = comments.
----------

5.1. Immutable Data
objects that are immutable once they are = written to storage.

I think this = requirement is a bit unclear on what is actually meant. My understanding = from our discussions is that DECADE MUST *only* store immutable data = objects. If that is the intention, I think that should be stated more = clearly. I don't think the word "ability" is the best to express this = requirement. An alternative formulation could be:
"DECADE MUST = only store and manage data objects that are immutable once they are = written to storage."

If I have misunderstood = the intention of this requirement and that it should also be possible to = store mutable data in DECADE servers, then I think such an explicit = requirement should be = added.
------------

5.2. Explicit Deletion of Data
to explicitly delete data from its own = in-network storage.

in-network storage. Since there may be a limit = (e.g., imposed by
the storage provider) to how much total storage = can be used, some
data may need to be removed to make room for = additional data. A
DECADE client should be able to explicitly = remove particular
data. This may be implemented using existing = protocols.

When reading the = rationale for this requirement I start to thinking that we might want to = add something about automatic removal of old data according to some = policy, e.g. that DECADE storage servers SHOULD be able to remove old = data according to some policy, e.g. LLRU. This should be of interest, = e.g. when a quota is being filled up, to avoid having to deny further = writings. This should be especially relevant in the mentioned = case of continuous writings,  e.g. for streaming = data.
-----------------

= B=F6rje




=
On 29 sep 2011, at 14.12, Woundy, Richard = wrote:

Folks,
Haibin and I are starting the working group last call for = draft-ietf-decade-reqs-04,  decade@ietf.org.
Authors, please do not make any additional changes to the = internet-draft unless directed by the WG = chairs.
 
Draft reviewers, it would be helpful to get your = confirmation that your previous review comments have been correctly = reflected in this version.
Thanks.
 
-- Rich and = Haibin
______________________________________= _________
decade mailing list
To: "decade@ietf.org" Thread-Topic: Tentative: DECADE slot at IETF 82 Thread-Index: AcyKbiTXETk0iGskRPe2+QGXce6HXQ== Date: Fri, 14 Oct 2011 12:38:15 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136B3763@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1136B3763PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [decade] Tentative: DECADE slot at IETF 82 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 12:38:21 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1136B3763PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, DECADE is *tentatively* scheduled for Thursday afternoon 17:40-19:40. I wou= ld still advise to make plans to attend the entire week if possible, as the= agenda is subject to change. Here is a pointer to the current agenda: . -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD1136B3763PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

DECADE is *tentatively* scheduled for Thursda= y afternoon 17:40-19:40. I would still advise to make plans to attend the e= ntire week if possible, as the agenda is subject to change.

 

Here is a pointer to the current agenda: <https://datatracke= r.ietf.org/meeting/82/agenda.html>.

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD1136B3763PACDCEXMB05cabl_-- From richard.alimi@gmail.com Sun Oct 16 08:10:08 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EAC21F87C2 for ; Sun, 16 Oct 2011 08:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de0laSRc62XS for ; Sun, 16 Oct 2011 08:10:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4077D21F8797 for ; Sun, 16 Oct 2011 08:10:07 -0700 (PDT) Received: by iabn5 with SMTP id n5so5391111iab.31 for ; Sun, 16 Oct 2011 08:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=NdcQX+QXaT3dnyZPHg9gCRsxe70fXL7IjSiisXNe3M4=; b=UL/81AcunbnR+lZ0CVTGKXv7eROOyo/hZZTR055v8zQWdvvRM7fo7ACMWfRBmwvuwL iCmYOo+Nu7iit7SnNLiOh8gem3kl/VwdCgloWs23h8FL+fFVHxXe483K5UAw7uFpT95+ eDCfeYfma7YnFEeX8JATrTd8YqtFmzxs9WvKQ= Received: by 10.42.158.9 with SMTP id f9mr31391659icx.31.1318777609082; Sun, 16 Oct 2011 08:06:49 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.3.144 with HTTP; Sun, 16 Oct 2011 08:06:29 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136A2790@PACDCEXMB05.cable.comcast.com> From: Richard Alimi Date: Sun, 16 Oct 2011 08:06:29 -0700 X-Google-Sender-Auth: LG3K9igsOiKmIedkmIeUUWhC9_4 Message-ID: To: "Rahman, Akbar" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 15:10:08 -0000 Hi Akbar, On Tue, Oct 11, 2011 at 9:07 AM, Rahman, Akbar wrote: > Hi Richard, > > > > > > All the comments from my previous review were addressed in rev -04 of the > requirements document.=A0 Thanks to the authors for taking care of that.= =A0 I > did however have two new comments on rev -04: > > > > > > Section 4.1.1.1 =96 Often protocols like STUN are required to account for > NATs.=A0 I was not sure if this requirement meant that we should NOT use > something like STUN as part of the overall DECADE solution (especially fo= r > DECADE server to server communications)? For client <-> server communications, the intent is that we should not be required to use something like STUN. For server <-> server, see below... > =A0=A0Is the real intent to force all > DECADE servers to be on the public Internet?=A0 If so then perhaps it wou= ld be > better to re-phrase the requirement? Looking at this again, I think we should be more careful to limit this requirement to client <-> server communications. The current thoughts for the server <-> server protocol treat servers as peers of each other. If servers are behind NATs I think we'd have to resort to dirty tricks. Any complaints with that? As to whether they need to be on the public Internet, I could imagine enterprise networks having deployments of DECADE servers that are not accessible from the public Internet, but only for use by internal applications. >=A0 Finally, I was confused by the reason > for the separate requirement of 6.1.2 that touched on the same issue. > That one refers to the discovery protocol as a separate entity. I might see good reasons to be explicit about this. Without it, I could imagine solutions in which discovery didn't work behind NATs, and the application using DECADE was just supposed to deal with it. > > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 7 =96 What does the section title of= =93Discussion=94 mean?=A0 If > there is still open issues then the document should not go to WGLC.=A0 If > these requirements are solid, then they should be written in the same for= mat > as the other sections of the document. To be more specific, these are issues that came up during the design of the other requirements in the document. However, they are things explicitly left out. The intent was to tell the reader "yes, we considered them, but they are not requirements and here's why". That said, the first one (7.1. Non-DECADE Internal Protocols) might be better placed somewhere else. Thanks again, Rich > > > > > > http://www.ietf.org/mail-archive/web/decade/current/msg00517.html > > > > > > > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > Woundy, Richard > Sent: Tuesday, October 11, 2011 10:19 AM > To: decade@ietf.org > Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 > > > > Just a reminder that the WGLC for the DECADE requirements draft > (draft-ietf-decade-reqs-04) ends next Monday October 17. > > > > If you think the document is ready to move forward, please state this on = the > list by Monday and not just silently agree. > > > > It would also help if our WG expert reviewers (Dave McDysan, Akbar Rahman= , > and Borje Ohlman) would confirm that their draft comments were addressed = in > this version by Monday. > > > > -- Rich > > > > From: Woundy, Richard > Sent: Thursday, September 29, 2011 8:13 AM > To: decade@ietf.org > Cc: Songhaibin; Woundy, Richard > Subject: Start of WGLC for draft-ietf-decade-reqs-04 > > > > Folks, > > > > Haibin and I are starting the working group last call for > draft-ietf-decade-reqs-04, > http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed = by > Monday October 17. Please send all concerns, suggestions and comments abo= ut > this internet-draft to the DECADE mailing list, decade@ietf.org. > > > > Authors, please do not make any additional changes to the internet-draft > unless directed by the WG chairs. > > > > Draft reviewers, it would be helpful to get your confirmation that your > previous review comments have been correctly reflected in this version. > > > > Thanks. > > > > -- Rich and Haibin > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > > From richard.alimi@gmail.com Sun Oct 16 08:41:53 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543E521F8770 for ; Sun, 16 Oct 2011 08:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHvDHIxT7VW2 for ; Sun, 16 Oct 2011 08:41:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9261B21F86EC for ; Sun, 16 Oct 2011 08:41:52 -0700 (PDT) Received: by iabn5 with SMTP id n5so5421090iab.31 for ; Sun, 16 Oct 2011 08:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=RipyR7HF4nj6ZV72YvN+Qxv01QUIgKbUMm55MBYqvVw=; b=usjWbyTM7kAlbwppd2o2b8AWampWBEzqTM0etSLqlkqcnvsfptpmvJlqAxd66vPzXE fhZW/GdwKgWuLRm/wA3REK9mDEyTtZGQdQ/F6+/fa65OBqI8zSkQD2YXm5eePW5iIen8 iNmzhm/rNVtcg4vV2licrQRZCSo29mNYFeuHw= Received: by 10.231.62.146 with SMTP id x18mr7395998ibh.25.1318779711103; Sun, 16 Oct 2011 08:41:51 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.3.144 with HTTP; Sun, 16 Oct 2011 08:41:31 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136A2790@PACDCEXMB05.cable.comcast.com> From: Richard Alimi Date: Sun, 16 Oct 2011 08:41:31 -0700 X-Google-Sender-Auth: XPhSfGfjAcgzUTOId71nS3F2cLU Message-ID: To: "Rahman, Akbar" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 15:41:53 -0000 On Sun, Oct 16, 2011 at 8:06 AM, Richard Alimi wrote: > Hi Akbar, > > On Tue, Oct 11, 2011 at 9:07 AM, Rahman, Akbar > wrote: >> Hi Richard, >> >> >> >> >> >> All the comments from my previous review were addressed in rev -04 of th= e >> requirements document.=A0 Thanks to the authors for taking care of that.= =A0 I >> did however have two new comments on rev -04: >> >> >> >> >> >> Section 4.1.1.1 =96 Often protocols like STUN are required to account fo= r >> NATs.=A0 I was not sure if this requirement meant that we should NOT use >> something like STUN as part of the overall DECADE solution (especially f= or >> DECADE server to server communications)? > > For client <-> server communications, the intent is that we should not > be required to use something like STUN. > > For server <-> server, see below... > >> =A0=A0Is the real intent to force all >> DECADE servers to be on the public Internet?=A0 If so then perhaps it wo= uld be >> better to re-phrase the requirement? > > Looking at this again, I think we should be more careful to limit this > requirement to client <-> server communications. =A0The current thoughts > for the server <-> server protocol treat servers as peers of each > other. =A0If servers are behind NATs I think we'd have to resort to > dirty tricks. > > Any complaints with that? > > As to whether they need to be on the public Internet, I could imagine > enterprise networks having deployments of DECADE servers that are not > accessible from the public Internet, but only for use by internal > applications. > >>=A0 Finally, I was confused by the reason >> for the separate requirement of 6.1.2 that touched on the same issue. >> > > That one refers to the discovery protocol as a separate entity. =A0I > might see good reasons to be explicit about this. =A0Without it, I could > imagine solutions in which discovery didn't work behind NATs, and the > application using DECADE was just supposed to deal with it. > >> >> >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 7 =96 What does the section title o= f =93Discussion=94 mean?=A0 If >> there is still open issues then the document should not go to WGLC.=A0 I= f >> these requirements are solid, then they should be written in the same fo= rmat >> as the other sections of the document. > > To be more specific, these are issues that came up during the design > of the other requirements in the document. However, they are things > explicitly left out. =A0The intent was to tell the reader "yes, we > considered them, but they are not requirements and here's why". And I left out... might there be a better suggestion for naming the section= ? :) > > That said, the first one (7.1. Non-DECADE Internal Protocols) might be > better placed somewhere else. > > Thanks again, > Rich > >> >> >> >> >> >> http://www.ietf.org/mail-archive/web/decade/current/msg00517.html >> >> >> >> >> >> >> >> >> >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf= Of >> Woundy, Richard >> Sent: Tuesday, October 11, 2011 10:19 AM >> To: decade@ietf.org >> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 >> >> >> >> Just a reminder that the WGLC for the DECADE requirements draft >> (draft-ietf-decade-reqs-04) ends next Monday October 17. >> >> >> >> If you think the document is ready to move forward, please state this on= the >> list by Monday and not just silently agree. >> >> >> >> It would also help if our WG expert reviewers (Dave McDysan, Akbar Rahma= n, >> and Borje Ohlman) would confirm that their draft comments were addressed= in >> this version by Monday. >> >> >> >> -- Rich >> >> >> >> From: Woundy, Richard >> Sent: Thursday, September 29, 2011 8:13 AM >> To: decade@ietf.org >> Cc: Songhaibin; Woundy, Richard >> Subject: Start of WGLC for draft-ietf-decade-reqs-04 >> >> >> >> Folks, >> >> >> >> Haibin and I are starting the working group last call for >> draft-ietf-decade-reqs-04, >> http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed= by >> Monday October 17. Please send all concerns, suggestions and comments ab= out >> this internet-draft to the DECADE mailing list, decade@ietf.org. >> >> >> >> Authors, please do not make any additional changes to the internet-draft >> unless directed by the WG chairs. >> >> >> >> Draft reviewers, it would be helpful to get your confirmation that your >> previous review comments have been correctly reflected in this version. >> >> >> >> Thanks. >> >> >> >> -- Rich and Haibin >> >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >> >> > From richard_woundy@cable.comcast.com Sun Oct 16 08:53:27 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B1121F8ABD for ; Sun, 16 Oct 2011 08:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.705 X-Spam-Level: X-Spam-Status: No, score=-102.705 tagged_above=-999 required=5 tests=[AWL=-1.197, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9Qgb-58rllc for ; Sun, 16 Oct 2011 08:53:26 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 10A1821F8A97 for ; Sun, 16 Oct 2011 08:53:25 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.57355078; Sun, 16 Oct 2011 10:00:44 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Sun, 16 Oct 2011 11:53:20 -0400 From: "Woundy, Richard" To: Richard Alimi , "Rahman, Akbar" Thread-Topic: [decade] Start of WGLC for draft-ietf-decade-reqs-04 Thread-Index: Acu+91Byr8CuZlwMSYaaxFnqkg41Dy/qW7BQAl+qvvAA/YzAsQAJf1WAAAf/0lA= Date: Sun, 16 Oct 2011 15:53:19 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136B59AB@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136A2790@PACDCEXMB05.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 15:53:27 -0000 >>> - Section 7 - What does the section title of "Discussion" mean= ? >> >> To be more specific, these are issues that came up during the design >> of the other requirements in the document. However, they are things >> explicitly left out. The intent was to tell the reader "yes, we >> considered them, but they are not requirements and here's why". > > And I left out... might there be a better suggestion for naming the secti= on? :) Future considerations. -----Original Message----- From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On Behalf Of= Richard Alimi Sent: Sunday, October 16, 2011 11:42 AM To: Rahman, Akbar Cc: Woundy, Richard; decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 On Sun, Oct 16, 2011 at 8:06 AM, Richard Alimi wrote: > Hi Akbar, > > On Tue, Oct 11, 2011 at 9:07 AM, Rahman, Akbar > wrote: >> Hi Richard, >> >> >> >> >> >> All the comments from my previous review were addressed in rev -04 of th= e >> requirements document.=A0 Thanks to the authors for taking care of that.= =A0 I >> did however have two new comments on rev -04: >> >> >> >> >> >> Section 4.1.1.1 - Often protocols like STUN are required to account for >> NATs.=A0 I was not sure if this requirement meant that we should NOT use >> something like STUN as part of the overall DECADE solution (especially f= or >> DECADE server to server communications)? > > For client <-> server communications, the intent is that we should not > be required to use something like STUN. > > For server <-> server, see below... > >> =A0=A0Is the real intent to force all >> DECADE servers to be on the public Internet?=A0 If so then perhaps it wo= uld be >> better to re-phrase the requirement? > > Looking at this again, I think we should be more careful to limit this > requirement to client <-> server communications. =A0The current thoughts > for the server <-> server protocol treat servers as peers of each > other. =A0If servers are behind NATs I think we'd have to resort to > dirty tricks. > > Any complaints with that? > > As to whether they need to be on the public Internet, I could imagine > enterprise networks having deployments of DECADE servers that are not > accessible from the public Internet, but only for use by internal > applications. > >>=A0 Finally, I was confused by the reason >> for the separate requirement of 6.1.2 that touched on the same issue. >> > > That one refers to the discovery protocol as a separate entity. =A0I > might see good reasons to be explicit about this. =A0Without it, I could > imagine solutions in which discovery didn't work behind NATs, and the > application using DECADE was just supposed to deal with it. > >> >> >> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 7 - What does the section title of = "Discussion" mean?=A0 If >> there is still open issues then the document should not go to WGLC.=A0 I= f >> these requirements are solid, then they should be written in the same fo= rmat >> as the other sections of the document. > > To be more specific, these are issues that came up during the design > of the other requirements in the document. However, they are things > explicitly left out. =A0The intent was to tell the reader "yes, we > considered them, but they are not requirements and here's why". And I left out... might there be a better suggestion for naming the section= ? :) > > That said, the first one (7.1. Non-DECADE Internal Protocols) might be > better placed somewhere else. > > Thanks again, > Rich > >> >> >> >> >> >> http://www.ietf.org/mail-archive/web/decade/current/msg00517.html >> >> >> >> >> >> >> >> >> >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf= Of >> Woundy, Richard >> Sent: Tuesday, October 11, 2011 10:19 AM >> To: decade@ietf.org >> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 >> >> >> >> Just a reminder that the WGLC for the DECADE requirements draft >> (draft-ietf-decade-reqs-04) ends next Monday October 17. >> >> >> >> If you think the document is ready to move forward, please state this on= the >> list by Monday and not just silently agree. >> >> >> >> It would also help if our WG expert reviewers (Dave McDysan, Akbar Rahma= n, >> and Borje Ohlman) would confirm that their draft comments were addressed= in >> this version by Monday. >> >> >> >> -- Rich >> >> >> >> From: Woundy, Richard >> Sent: Thursday, September 29, 2011 8:13 AM >> To: decade@ietf.org >> Cc: Songhaibin; Woundy, Richard >> Subject: Start of WGLC for draft-ietf-decade-reqs-04 >> >> >> >> Folks, >> >> >> >> Haibin and I are starting the working group last call for >> draft-ietf-decade-reqs-04, >> http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed= by >> Monday October 17. Please send all concerns, suggestions and comments ab= out >> this internet-draft to the DECADE mailing list, decade@ietf.org. >> >> >> >> Authors, please do not make any additional changes to the internet-draft >> unless directed by the WG chairs. >> >> >> >> Draft reviewers, it would be helpful to get your confirmation that your >> previous review comments have been correctly reflected in this version. >> >> >> >> Thanks. >> >> >> >> -- Rich and Haibin >> >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >> >> > From richard.alimi@gmail.com Sun Oct 16 08:53:54 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0440E21F8AD2 for ; Sun, 16 Oct 2011 08:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8sNBduZoHnR for ; Sun, 16 Oct 2011 08:53:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 542AB21F8A97 for ; Sun, 16 Oct 2011 08:53:53 -0700 (PDT) Received: by iabn5 with SMTP id n5so5432045iab.31 for ; Sun, 16 Oct 2011 08:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=5fYgjYj7EPCvDBnW/OfLhMMP2rPSHlmy0RsYK5Z/71o=; b=eonzxXveZuwUYvPiZXujcfng5qqS5t1eOojrugOYid4gBdbz1Xyg5KzNV+MsLRdEnO 30e0F1QrUEwp2rBxlLkVI+wEtBHOe6lhK3553emFlCGgwP7sB4G/7gYwcfhA8PsupdyM +rpYNYEGkJxnT7LzRR5DFs+AOwkN/LVZ33t8k= Received: by 10.231.65.74 with SMTP id h10mr7351266ibi.38.1318780420100; Sun, 16 Oct 2011 08:53:40 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.3.144 with HTTP; Sun, 16 Oct 2011 08:53:20 -0700 (PDT) In-Reply-To: <1437EB69-B337-4B88-80D8-5BF4FEB42C34@ericsson.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1437EB69-B337-4B88-80D8-5BF4FEB42C34@ericsson.com> From: Richard Alimi Date: Sun, 16 Oct 2011 08:53:20 -0700 X-Google-Sender-Auth: bYtcr57fP3EkLWYvAawNZZs1SCo Message-ID: To: =?ISO-8859-1?Q?B=F6rje_Ohlman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 15:53:54 -0000 On Fri, Oct 14, 2011 at 4:11 AM, B=F6rje Ohlman = wrote: > Hi, > I think the draft is in very good shape, thanks to the authors for an > excellent job. All my previous comments are addressed by this draft. Howe= ver > looking through it last night I have some additional comments. > ---------- > > 5.1. Immutable Data > REQUIREMENT(S): DECADE MUST provide the ability to manage data > objects that are immutable once they are written to storage. > > I think this requirement is a bit unclear on what is actually meant. My > understanding from our discussions is that DECADE MUST *only* store > immutable data objects. If that is the intention, I think that should be > stated more clearly. I don't think the word "ability" is the best to expr= ess > this requirement. An alternative formulation could be: > "DECADE MUST only store and manage data=A0objects that are immutable once= they > are written to storage." > If I have misunderstood the intention of this requirement and that it sho= uld > also be possible to store mutable data in DECADE servers, then I think su= ch > an explicit requirement should be added. Your understanding was correct, and I agree with your suggested text. Any complaints from others with adopting that? > ------------ > > 5.2. Explicit Deletion of Data > REQUIREMENT(S): DECADE MUST support the ability for a DECADE client > to explicitly delete data from its own in-network storage. > > RATIONALE: A DECADE client may continually be writing data to its > in-network storage. Since there may be a limit (e.g., imposed by > the storage provider) to how much total storage can be used, some > data may need to be removed to make room for additional data. A > DECADE client should be able to explicitly remove particular > data. This may be implemented using existing protocols. > > When reading the rationale for this requirement I start to thinking that = we > might want to add something about automatic removal of old data according= to > some policy, e.g. that DECADE storage servers SHOULD be able to remove ol= d > data according to some policy, e.g. LLRU. This should be of interest, e.g= . > when a quota is being filled up, to avoid having to deny further writings= . > This should be=A0especially=A0relevant in the mentioned case of continuou= s > writings, =A0e.g.=A0for=A0streaming data. This is a very good question. Two comments here: (1) We already have 4.4.3 which allows objects to be deleted after a time-to-live, which can help with the streaming case. (2) I think what you are proposing is a more general mechanism for cache-replacement. While I think that would be a nice feature to have, I'm a bit concerned about the complexity. I might imagine something as complex as designing a new specification language for custom cache replacement policies, or something as simple as "we specify LRU and LFU - the rest are extensions". The latter might work in certain cases, but for cases such as VoD / DVR type stuff, I'm not sure either is sufficient (I may just not have watched the program yet). Furthermore, what happens when multiple applications (run by the same user, accessing the same account) each want to have their own cache replacement policy and they might be in conflict? Thoughts? Thanks, Rich > ----------------- > B=F6rje > > > > On 29 sep 2011, at 14.12, Woundy, Richard wrote: > > Folks, > > Haibin and I are starting the working group last call for > draft-ietf-decade-reqs-04,=A0http://datatracker.ietf.org/doc/draft-ietf-d= ecade-reqs/, > to be completed by Monday October 17. Please send all concerns, suggestio= ns > and comments about this internet-draft to the DECADE mailing > list,=A0decade@ietf.org. > > Authors, please do not make any additional changes to the internet-draft > unless directed by the WG chairs. > > Draft reviewers, it would be helpful to get your confirmation that your > previous review comments have been correctly reflected in this version. > > Thanks. > > -- Rich and Haibin > _______________________________________________ > 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 Akbar.Rahman@InterDigital.com Sun Oct 16 21:25:14 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0721F0C36 for ; Sun, 16 Oct 2011 21:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njROqE70x8Y6 for ; Sun, 16 Oct 2011 21:25:13 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id A09CD1F0C35 for ; Sun, 16 Oct 2011 21:25:13 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 00:25:12 -0400 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: Mon, 17 Oct 2011 00:25:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Start of WGLC for draft-ietf-decade-reqs-04 Thread-index: AcyMFZ1KHjaqxb+PQOeu5Lm9YmSITQAbkaMA References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136A2790@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Richard Alimi" X-OriginalArrivalTime: 17 Oct 2011 04:25:12.0803 (UTC) FILETIME=[C35B8B30:01CC8C84] Cc: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 04:25:14 -0000 Hi Rich, Thanks for your responses. I have given my feedback identified by "**** = AKBAR: ". Akbar -----Original Message----- From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On Behalf = Of Richard Alimi Sent: Sunday, October 16, 2011 11:06 AM To: Rahman, Akbar Cc: Woundy, Richard; decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 Hi Akbar, On Tue, Oct 11, 2011 at 9:07 AM, Rahman, Akbar wrote: > Hi Richard, > > > > > > All the comments from my previous review were addressed in rev -04 of = the > requirements document.=A0 Thanks to the authors for taking care of = that.=A0 I > did however have two new comments on rev -04: > > > > > > Section 4.1.1.1 - Often protocols like STUN are required to account = for > NATs.=A0 I was not sure if this requirement meant that we should NOT = use > something like STUN as part of the overall DECADE solution (especially = for > DECADE server to server communications)? For client <-> server communications, the intent is that we should not be required to use something like STUN. For server <-> server, see below... > =A0=A0Is the real intent to force all > DECADE servers to be on the public Internet?=A0 If so then perhaps it = would be > better to re-phrase the requirement? Looking at this again, I think we should be more careful to limit this requirement to client <-> server communications. The current thoughts for the server <-> server protocol treat servers as peers of each other. If servers are behind NATs I think we'd have to resort to dirty tricks. Any complaints with that? **** AKBAR: OKAY. I AGREE WITH YOUR ABOVE CLARIFICATION.********* As to whether they need to be on the public Internet, I could imagine enterprise networks having deployments of DECADE servers that are not accessible from the public Internet, but only for use by internal applications. **** AKBAR: YES, I AGREE WITH YOUR POINT.********* >=A0 Finally, I was confused by the reason > for the separate requirement of 6.1.2 that touched on the same issue. > That one refers to the discovery protocol as a separate entity. I might see good reasons to be explicit about this. Without it, I could imagine solutions in which discovery didn't work behind NATs, and the application using DECADE was just supposed to deal with it. **** AKBAR: OKAY.********* > > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 7 - What does the section title = of "Discussion" mean?=A0 If > there is still open issues then the document should not go to WGLC.=A0 = If > these requirements are solid, then they should be written in the same = format > as the other sections of the document. To be more specific, these are issues that came up during the design of the other requirements in the document. However, they are things explicitly left out. The intent was to tell the reader "yes, we considered them, but they are not requirements and here's why". **** AKBAR: THEN I THINK THAT YOU SHOULD RENAME THE SECTION AS PER RICH = WOUNDY'S SUGGESTION IN HIS EMAIL. ALSO I THINK YOU NEED TO ADD AN INTRODUCTORY = PARAGRAPH CAPTURING WHAT YOU SAID ABOVE.********* That said, the first one (7.1. Non-DECADE Internal Protocols) might be better placed somewhere else. **** AKBAR: OKAY.********* Thanks again, Rich > > > > > > http://www.ietf.org/mail-archive/web/decade/current/msg00517.html > > > > > > > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On = Behalf Of > Woundy, Richard > Sent: Tuesday, October 11, 2011 10:19 AM > To: decade@ietf.org > Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 > > > > Just a reminder that the WGLC for the DECADE requirements draft > (draft-ietf-decade-reqs-04) ends next Monday October 17. > > > > If you think the document is ready to move forward, please state this = on the > list by Monday and not just silently agree. > > > > It would also help if our WG expert reviewers (Dave McDysan, Akbar = Rahman, > and Borje Ohlman) would confirm that their draft comments were = addressed in > this version by Monday. > > > > -- Rich > > > > From: Woundy, Richard > Sent: Thursday, September 29, 2011 8:13 AM > To: decade@ietf.org > Cc: Songhaibin; Woundy, Richard > Subject: Start of WGLC for draft-ietf-decade-reqs-04 > > > > Folks, > > > > Haibin and I are starting the working group last call for > draft-ietf-decade-reqs-04, > http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be = completed by > Monday October 17. Please send all concerns, suggestions and comments = about > this internet-draft to the DECADE mailing list, decade@ietf.org. > > > > Authors, please do not make any additional changes to the = internet-draft > unless directed by the WG chairs. > > > > Draft reviewers, it would be helpful to get your confirmation that = your > previous review comments have been correctly reflected in this = version. > > > > Thanks. > > > > -- Rich and Haibin > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > > From Akbar.Rahman@InterDigital.com Sun Oct 16 21:40:31 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3492911E8089 for ; Sun, 16 Oct 2011 21:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe128pi4Oe6t for ; Sun, 16 Oct 2011 21:40:30 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7BA11E8088 for ; Sun, 16 Oct 2011 21:40:30 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 00:40:29 -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: Mon, 17 Oct 2011 00:40:28 -0400 Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136A3C34@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] I-D Action: draft-ietf-decade-problem-statement-04.txt Thread-index: AQHMiKuHVQ0NSle/+U2Ey5540nSx9pV4uziwgAc9ycA= References: <20111012065230.5237.98873.idtracker@ietfa.amsl.com> <1CA25301D2219F40B3AA37201F0EACD1136A3C34@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Woundy, Richard" X-OriginalArrivalTime: 17 Oct 2011 04:40:29.0352 (UTC) FILETIME=[E5A9D280:01CC8C86] Cc: decade@ietf.org Subject: Re: [decade] I-D Action: draft-ietf-decade-problem-statement-04.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 04:40:31 -0000 Hi Rich, I read the updated draft, and I think that the authors have done a good job in addressing the comments from Dave Harrington. So, I would vote to send the draft back to Dave. Akbar -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Wednesday, October 12, 2011 9:59 AM To: decade@ietf.org Subject: Re: [decade] I-D Action: draft-ietf-decade-problem-statement-04.txt I would like to request the WG to review this draft version for correctness and clarity before I take the draft back to our AD. Dave Harrington's AD review comments can be found here: . Obviously we need to ensure that this draft is responsive to his comments. -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, October 12, 2011 2:52 AM To: i-d-announce@ietf.org Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-problem-statement-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Decoupled Application Data Enroute Working Group of the IETF. Title : DECoupled Application Data Enroute (DECADE) Problem Statement Author(s) : Haibin Song Ning Zong Y. Richard Yang Richard Alimi Filename : draft-ietf-decade-problem-statement-04.txt Pages : 15 Date : 2011-10-11 Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network (the download traffic may increase because the in- network storage is likely much better connected). Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols and cache refreshing mechanisms) and they do not have the feature to allow users to manage access to content in the cache. For example, Content Providers cannot easily control cache access and resource usage policies to satisfy their own requirements. In this document, a content provider is also the user of in-network storage. This document discusses the introduction of in-network storage for P2P applications, and shows the need for a standard protocol for accessing this storage. It can also be used by other applications with similar requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-problem-statement- 04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-0 4.txt _______________________________________________ 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 borje.ohlman@ericsson.com Mon Oct 17 08:02:45 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE93121F8C39 for ; Mon, 17 Oct 2011 08:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI-wt1xd2bEn for ; Mon, 17 Oct 2011 08:02:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2B43D21F8C37 for ; Mon, 17 Oct 2011 08:02:43 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e0-4e9c439269d9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 46.40.20773.2934C9E4; Mon, 17 Oct 2011 17:02:42 +0200 (CEST) Received: from dhcp-147-214-183-82.ki.sw.ericsson.se (153.88.115.8) by smtps.internal.ericsson.com (153.88.115.93) with Microsoft SMTP Server id 8.3.137.0; Mon, 17 Oct 2011 17:02:42 +0200 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary="Apple-Mail-7--893337761" From: =?iso-8859-1?Q?B=F6rje_Ohlman?= In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> Date: Mon, 17 Oct 2011 17:02:42 +0200 Message-ID: <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> To: decade ietf X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:02:45 -0000 --Apple-Mail-7--893337761 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Dear All, I think the current draft is in a very good shape, great thanks to the = authors. Regarding my comments from the previous review I happy to say = that, as far as I can see, all, except one has been addressed. The one I = see not directly addressed I think is of lesser importance and maybe it = was a conscious decision not to include that, if so I have no major = problem with it. I have a number of new comments regarding the current text but they do = not constitute any objections but points to were the text could be made = clear to avoid misunderstandings. The one thing I comment on that could cause some discussion is whether = both clients and servers should be allowed to name objects. I think it = is not entirely clear from the current draft how this should be dealt = with. I think both cases should be allowed. Please see below for my review report. Best regards, B=F6rje The previous comment that I do not see as addressed is how overbooking = of resources should be dealt with in DECADE. This is probably to large = extent an SLA issue, but I think it would raise the issue in this draft. = In my review of the previous draft I wrote: > Is it allowed for decade service providers to oversell the resources = of their servers (both bandwidth and storage), similar to airline = overbooking? I think overbooking should be allowed to maximize resource = utilization. Especially regarding bandwidth I think it is unavoidable. = It would be good if this was addressed in the draft, e.g. in 4.2. For comments on the current draft: 6.1.14 last =A7 "If an application wishes to store such metadata persistently within = DECADE, it can be stored within data objects themselves." Add "or as separate objects" to be consistent with previous formulations = regarding this. 6.2.1 =A71 In the first =A7 it is unclear if the client or the server is naming the = object. If both alternatives are allowed this should be stated = explicitly and it should be added a comment to the parameter NAME that = it can be empty.=20 Then in =A74 it is stated "The application that originates the objects = MUST generate DECADE object names according to the naming specification = in Section 5.3." Is it sure that we want this? Sensors might want the = server to generate the names. 6.2.1 last =A7 It states "Specifics regarding error handling, including additional = error conditions, precedence for returned errors and its relation with = server policy, are deferred to eventual protocol specification." Should = not lack of resources be mentioned here as well as it is an obvious = issue. This would be a possible place to add a comment on the issue with = overbookings. 7 =A72 It states "All data operations are performed on behalf of DECADE clients = via explicit instruction, ..." It is unclear from this text if the client has to be using the DECADE = Protocol to perform this action or if an management or application = protocol can be used to instruct the remote server. Should it not also = be allowed for the client to delegate these operations to e.g. a cache = managment application? 7.1 =A75 It states "Though explicitly supplying these may provide additional = freedom, it is not clear what benefit they might provide." It is unclear what the "they" refers to. I have problems understanding = the meaning of this sentence. 7.1 last =A7 It states "In the case of a GET operation, the DECADE server is to = retrieve the data object from the remote server using the specified = credentials (via a GET request to the remote server), and then return = the object to the client." Why should the object be returned to the client? If this is just about = cache management there is no reason to return the object to the client.=20= Further it states: "In the case of a PUT operation, the DECADE server is = to store the object from the client..." This sounds like the client = making this PUT I thought this was about server to server communication. = Also should not policies for the object, e.g. ttl, be stored? 8.1 first =A7 It states "A DECADE server may choose to not fully store an object = before beginning to serve it." The 'may choose' is not consistent with = the MUST requierment to be able to deliver before fully stored. A.1.4 s/deleting/deletion/ On 29 sep 2011, at 14.13, Woundy, Richard wrote: > Folks, > =20 > Haibin and I are starting the working group last call for = draft-ietf-decade-arch-03, = http://datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be completed = by Monday October 17. Please send all concerns, suggestions and comments = about this internet-draft to the DECADE mailing list, decade@ietf.org. > =20 > Authors, please do not make any additional changes to the = internet-draft unless directed by the WG chairs. > =20 > Draft reviewers, it would be helpful to get your confirmation that = your previous review comments have been correctly reflected in this = version. > =20 > Thanks. > =20 > -- Rich and Haibin > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade --Apple-Mail-7--893337761 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Dear All,

I think the current draft is = in a very good shape, great thanks to the authors. Regarding my comments = from the previous review I happy to say that, as far as I can see, all, = except one has been addressed. The one I see not directly addressed I = think is of lesser importance and maybe it was a conscious decision not = to include that, if so I have no major problem with it.
I have = a number of new comments regarding the current text but they do not = constitute any objections but points to were the text could be made = clear to avoid misunderstandings.
The one thing I comment on = that could cause some discussion is whether both clients and servers = should be allowed to name objects. I think it is not entirely clear from = the current draft how this should be dealt with. I think both cases = should be allowed.
Please see below for my review = report.

Best regards,
= B=F6rje

The previous comment that I do = not see as addressed is how overbooking of resources should be dealt = with in DECADE. This is probably to large extent an SLA issue, but I = think it would raise the issue in this draft. In my review of the = previous draft I wrote:
Is it allowed for = decade service providers to oversell the resources of their servers = (both bandwidth and storage), similar to airline overbooking? I think = overbooking should be allowed to maximize resource utilization. = Especially regarding bandwidth I think it is unavoidable. It would be = good if this was addressed in the draft, e.g. in = 4.2.

For comments on the current = draft:

6.1.14 last =A7
"If an application = wishes to store such metadata persistently within DECADE, it can = be stored within data objects themselves."
Add = "or as separate objects" to be consistent with previous formulations = regarding this.

6.2.1 =A71
In the = first =A7 it is unclear if the client or the server is naming the = object. If both alternatives are allowed this should be stated = explicitly and it should be added a comment to the parameter NAME that = it can be empty. 

Then in =A74 it is = stated "The application that originates the objects MUST generate = DECADE object names according to the naming specification in = Section 5.3." Is it sure that we want this? Sensors might want the = server to generate the names.

6.2.1 last = =A7
It states "Specifics regarding error handling, including = additional error conditions, precedence for returned errors and its = relation with server policy, are deferred to eventual = protocol specification." Should not lack of resources be mentioned = here as well as it is an obvious issue. This would be a possible place = to add a comment on the issue with = overbookings.

7 =A72
It states "All = data operations are performed on behalf of DECADE clients via = explicit instruction, ..."
It is unclear from this = text if the client has to be using the DECADE Protocol to perform this = action or if an management or application protocol can be used to = instruct the remote server. Should it not also be allowed for the client = to delegate these operations to e.g. a cache managment = application?

7.1 =A75
It states "Though explicitly supplying these may provide = additional freedom, it is not clear what benefit they might = provide."
It is unclear what the "they" refers to. = I have problems understanding the meaning of this = sentence.

7.1 last =A7
It states "In = the case of a GET operation, the DECADE server is to retrieve = the data object from the remote server using the specified = credentials (via a GET request to the remote server), and then = return the object to the client."
Why should the object = be returned to the client? If this is just about cache management there = is no reason to return the object to the client. 
Further = it states: "In the case of a PUT operation, the DECADE server = is to store the object from the client..." This sounds like = the client making this PUT I thought this was about server to server = communication. Also should not policies for the object, e.g. ttl, be = stored?

8.1 first =A7
It states "A = DECADE server may choose to not fully store an object = before beginning to serve it." The 'may choose' is not consistent = with the MUST requierment to be able to deliver before fully = stored.

A.1.4
s/deleting/deletion/



On 29 sep 2011, at = 14.13, Woundy, Richard wrote:

Folks,
 
Authors, please do not make any additional changes to the = internet-draft unless directed by the WG = chairs.
 
Draft reviewers, it would be helpful to get your = confirmation that your previous review comments have been correctly = reflected in this version.
Thanks.
 
-- Rich and = Haibin
______________________________________= _________
decade mailing list
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 06:51:57 -0000 Hi B=F6rje, Thank you very much for the review. Responses inline... On Mon, Oct 17, 2011 at 8:02 AM, B=F6rje Ohlman = wrote: > Dear All, > > I think the current draft is in a very good shape, great thanks to the > authors. Regarding my comments from the previous review I happy to say th= at, > as far as I can see, all, except one has been addressed. The one I see no= t > directly addressed I think is of lesser importance and maybe it was a > conscious decision not to include that, if so I have no major problem wit= h > it. > I have a number of new comments regarding the current text but they do no= t > constitute any objections but points to were the text could be made clear= to > avoid misunderstandings. > The one thing I comment on that could cause some discussion is whether bo= th > clients and servers should be allowed to name objects. I think it is not > entirely clear from the current draft how this should be dealt with. I th= ink > both cases should be allowed. > Please see below for my review report. > > Best regards, > B=F6rje > The previous comment that I do not see as addressed is how overbooking of > resources should be dealt with in DECADE. This is probably to large exten= t > an SLA issue, but I think it would raise the issue in this draft. In my > review of the previous draft I wrote: > > Is it allowed for decade service providers to oversell the resources of > their servers (both bandwidth and storage), similar to airline overbookin= g? > I think overbooking should be allowed to maximize resource utilization. > Especially regarding bandwidth I think it is unavoidable. It would be goo= d > if this was addressed in the draft, e.g. in 4.2. My personal feeling is that this is a question of policy and not a question for the protocol or architecture. Do you think that leaving it out of scope will cause issues in the design or eventual protocol specification? I could see policy, algorithms, and deployments changing based on whether oversubscription is used, but what do you think the protocol ramifications might be? Presumably we will need the architecture/protocol to have all the nice features of any protocol such as overload handling anyways (those are already in the requirements). > > For comments on the current draft: > 6.1.14 last =A7 > "If an application wishes to store such=A0metadata persistently within DE= CADE, > it can be stored within data=A0objects themselves." > Add "or as separate objects" to be consistent with previous formulations > regarding this. Sounds good to me. So noted. > 6.2.1 =A71 > In the first =A7 it is unclear if the client or the server is naming the > object. If both alternatives are allowed this should be stated explicitly > and it should be added a comment to the parameter NAME that it can be > empty. > Then in =A74 it is stated "The application that originates the objects MU= ST > generate DECADE=A0object names according to the naming specification in > Section 5.3."=A0Is it sure that we want this? Sensors might want the serv= er to > generate the names. The original intent was for the name to be sent by the client, and then validated by the server. That said, I have only two reservations about having the server compute the name (if the client does not want to): (1) the server is forced to compute the hash which may be expensive. I might imagine certain cases where servers disable this (knowing the risks of not validating the hashes), in which case a request from such a client would be rejected. I don't think this would be common, though. (2) the client must trust the server if this is done (otherwise the server can insert, remove, or completely fabricate the content and lie about the name). Therefore, I don't have a problem as long as the security consideration is made completely clear. Thoughts? > 6.2.1 last =A7 > It states "Specifics regarding error handling, including additional > error=A0conditions, precedence for returned errors and its relation=A0wit= h > server policy, are deferred to eventual protocol=A0specification." Should= not > lack of resources be mentioned here as well as it is an obvious issue. Th= is > would be a possible place to add a comment on the issue with overbookings= . Would additionally mentioning "overload conditions" (as it is worded in the requirements draft) suffice? > 7 =A72 > It states "All data operations are performed on behalf of DECADE clients= =A0via > explicit instruction, ..." > It is unclear from this text if the client has to be using the DECADE > Protocol to perform this action or if an management or application protoc= ol > can be used to instruct the remote server. The intent was not to disallow access by administrative/management protocols. Would dropping the word "all" from the beginning of the sentence help to clarify this? > Should it not also be allowed for > the client to delegate these operations to e.g. a cache managment > application? Can you clarify the use case? Who owns/manages the cache management application? Is it the same person as the DECADE server? Is it the same person as the DECADE client? > 7.1 =A75 > It states "Though explicitly supplying these may provide additional freed= om, > it=A0is not clear what benefit they might provide." > It is unclear what the "they" refers to. I have problems understanding th= e > meaning of this sentence. "they" refers to the data object and operation parameters. For example, a typical (normal) use case might be to request to download object 1 from Server A, but indicating that it must fetch object 1 from Server B first. Extending that slightly, I could imagine constructing protocol messages to request to download object 1 from Server A, but indicating it must fetch object 2 from Server B first. There may be interesting use cases for something like that - this sentence was merely trying to point this out. We can drop this sentence if it creates confusion. > 7.1 last =A7 > It states "In the case of a GET operation, the DECADE server is to retrie= ve > the=A0data object from the remote server using the specified credentials= =A0(via > a GET request to the remote server), and then return the object=A0to the > client." > Why should the object be returned to the client? If this is just about ca= che > management there is no reason to return the object to the client. No - it is not only about cache management. The client may not have the object yet. However, that said, I might imagine cases where the last step (downloading to the client itself) is optional, e.g., if it wishes to delay downloading it over the last mile for later. We should add a note saying that it is optional. > Further it states: "In the case of a PUT=A0operation, the DECADE server i= s=A0to > store the object from the client..."=A0This sounds like the client making= this > PUT I thought this was about server to server communication. Yes - the server-to-server communication is explicitly controlled by the cl= ient. Similarly, we should add a note here saying that the upload from the client to its own server is optional (the object may already exist at one server, and the client may want it replicated to another server). > Also should not > policies for the object, e.g. ttl, be stored? Yes. This section states "DECADE re-uses the already-specified protocols to support operations directly between servers", and these were mentioned in Section 6. Should we explicitly mention that such attributes can also be configured on requests involving server-to-server communication? > 8.1 first =A7 > It states "A DECADE server may choose to not fully store an object > before=A0beginning to serve it." The 'may choose' is not consistent with = the > MUST requierment to be able to deliver before fully stored. Just to be sure, you are referring to this statement? "A server MUST accept download requests for an object that is still being uploaded." That should indeed be a MAY to be consistent with the requirements draft. Objections? > A.1.4 > s/deleting/deletion/ Indeed. Noted. Thanks! Rich > > > On 29 sep 2011, at 14.13, Woundy, Richard wrote: > > Folks, > > Haibin and I are starting the working group last call for > draft-ietf-decade-arch-03,=A0http://datatracker.ietf.org/doc/draft-ietf-d= ecade-arch/, > to be completed by Monday October 17. Please send all concerns, suggestio= ns > and comments about this internet-draft to the DECADE mailing > list,=A0decade@ietf.org. > > Authors, please do not make any additional changes to the internet-draft > unless directed by the WG chairs. > > Draft reviewers, it would be helpful to get your confirmation that your > previous review comments have been correctly reflected in this version. > > Thanks. > > -- Rich and Haibin > _______________________________________________ > 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 borje.ohlman@ericsson.com Tue Oct 18 09:02:14 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF55121F8BA7 for ; Tue, 18 Oct 2011 09:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.242 X-Spam-Level: X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n6NVlmMp6zU for ; Tue, 18 Oct 2011 09:02:13 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0EC21F8BA2 for ; Tue, 18 Oct 2011 09:02:13 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-9a-4e9da303a745 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BB.95.13753.303AD9E4; Tue, 18 Oct 2011 18:02:11 +0200 (CEST) Received: from dhcp-147-214-183-82.ki.sw.ericsson.se (153.88.115.8) by smtps.internal.ericsson.com (153.88.115.81) with Microsoft SMTP Server id 8.3.137.0; Tue, 18 Oct 2011 18:02:11 +0200 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?Q?B=F6rje_Ohlman?= In-Reply-To: Date: Tue, 18 Oct 2011 18:02:13 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> To: Richard Alimi X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:02:14 -0000 Comments inline... On 18 okt 2011, at 08.51, Richard Alimi wrote: > Hi B=F6rje, >=20 > Thank you very much for the review. Responses inline... >=20 > On Mon, Oct 17, 2011 at 8:02 AM, B=F6rje Ohlman = wrote: >>=20 >> The previous comment that I do not see as addressed is how = overbooking of >> resources should be dealt with in DECADE. This is probably to large = extent >> an SLA issue, but I think it would raise the issue in this draft. In = my >> review of the previous draft I wrote: >>=20 >> Is it allowed for decade service providers to oversell the resources = of >> their servers (both bandwidth and storage), similar to airline = overbooking? >> I think overbooking should be allowed to maximize resource = utilization. >> Especially regarding bandwidth I think it is unavoidable. It would be = good >> if this was addressed in the draft, e.g. in 4.2. >=20 > My personal feeling is that this is a question of policy and not a > question for the protocol or architecture. Do you think that leaving > it out of scope will cause issues in the design or eventual protocol > specification? I could see policy, algorithms, and deployments > changing based on whether oversubscription is used, but what do you > think the protocol ramifications might be? Presumably we will need > the architecture/protocol to have all the nice features of any > protocol such as overload handling anyways (those are already in the > requirements). Ok, fine. >=20 >> 6.2.1 =A71 >> In the first =A7 it is unclear if the client or the server is naming = the >> object. If both alternatives are allowed this should be stated = explicitly >> and it should be added a comment to the parameter NAME that it can be >> empty. >> Then in =A74 it is stated "The application that originates the = objects MUST >> generate DECADE object names according to the naming specification in >> Section 5.3." Is it sure that we want this? Sensors might want the = server to >> generate the names. >=20 > The original intent was for the name to be sent by the client, and > then validated by the server. That said, I have only two reservations > about having the server compute the name (if the client does not want > to): > (1) the server is forced to compute the hash which may be expensive. > I might imagine certain cases where servers disable this (knowing the > risks of not validating the hashes), in which case a request from such > a client would be rejected. I don't think this would be common, > though. > (2) the client must trust the server if this is done (otherwise the > server can insert, remove, or completely fabricate the content and lie > about the name). >=20 > Therefore, I don't have a problem as long as the security > consideration is made completely clear. >=20 > Thoughts? I think both clients and servers should be allowed to create name it is = not up to the architecture to decide on what is appropriate in specific = network environments. >=20 >> 6.2.1 last =A7 >> It states "Specifics regarding error handling, including additional >> error conditions, precedence for returned errors and its relation = with >> server policy, are deferred to eventual protocol specification." = Should not >> lack of resources be mentioned here as well as it is an obvious = issue. This >> would be a possible place to add a comment on the issue with = overbookings. >=20 > Would additionally mentioning "overload conditions" (as it is worded > in the requirements draft) suffice? Fine. >=20 >> 7 =A72 >> It states "All data operations are performed on behalf of DECADE = clients via >> explicit instruction, ..." >> It is unclear from this text if the client has to be using the DECADE >> Protocol to perform this action or if an management or application = protocol >> can be used to instruct the remote server. >=20 > The intent was not to disallow access by administrative/management > protocols. Would dropping the word "all" from the beginning of the > sentence help to clarify this? I think I should have included some more of the draft text here: "All data operations are performed on behalf of DECADE clients via explicit instruction, so additional capabilities are needed in the DECADE client-server protocols DECADE clients must be able to indicate to a DECADE server the following additional parameters:" I think it is the formulation " additional capabilities are needed in the DECADE client-server protocols" that is causing the problem by = explicitly mentioning the DECADE protocols, a more neutral formulation = not mentioning specific protocols I think would help. >=20 >> Should it not also be allowed for >> the client to delegate these operations to e.g. a cache managment >> application? >=20 > Can you clarify the use case? Who owns/manages the cache management > application? Is it the same person as the DECADE server? Is it the > same person as the DECADE client? One example would be a customer of network (and DECADE server) provider = that just want to put data objects in it's 'local' DECADE storage and = then want the network provider to populate other DECADE servers to = provide a flexible CDN like functionality for the published objects. >=20 >> 7.1 =A75 >> It states "Though explicitly supplying these may provide additional = freedom, >> it is not clear what benefit they might provide." >> It is unclear what the "they" refers to. I have problems = understanding the >> meaning of this sentence. >=20 > "they" refers to the data object and operation parameters. For > example, a typical (normal) use case might be to request to download > object 1 from Server A, but indicating that it must fetch object 1 > from Server B first. Extending that slightly, I could imagine > constructing protocol messages to request to download object 1 from > Server A, but indicating it must fetch object 2 from Server B first. > There may be interesting use cases for something like that - this > sentence was merely trying to point this out. >=20 > We can drop this sentence if it creates confusion. Please do. >=20 >> 7.1 last =A7 >> It states "In the case of a GET operation, the DECADE server is to = retrieve >> the data object from the remote server using the specified = credentials (via >> a GET request to the remote server), and then return the object to = the >> client." >> Why should the object be returned to the client? If this is just = about cache >> management there is no reason to return the object to the client. >=20 > No - it is not only about cache management. The client may not have > the object yet. However, that said, I might imagine cases where the > last step (downloading to the client itself) is optional, e.g., if it > wishes to delay downloading it over the last mile for later. We > should add a note saying that it is optional. Fine. >=20 >> Further it states: "In the case of a PUT operation, the DECADE server = is to >> store the object from the client..." This sounds like the client = making this >> PUT I thought this was about server to server communication. >=20 > Yes - the server-to-server communication is explicitly controlled by = the client. >=20 > Similarly, we should add a note here saying that the upload from the > client to its own server is optional (the object may already exist at > one server, and the client may want it replicated to another server). Ok. >=20 >> Also should not >> policies for the object, e.g. ttl, be stored? >=20 > Yes. This section states "DECADE re-uses the already-specified > protocols to support operations directly between servers", and these > were mentioned in Section 6. Should we explicitly mention that such > attributes can also be configured on requests involving > server-to-server communication? Would be good for clarity. >=20 >> 8.1 first =A7 >> It states "A DECADE server may choose to not fully store an object >> before beginning to serve it." The 'may choose' is not consistent = with the >> MUST requierment to be able to deliver before fully stored. >=20 > Just to be sure, you are referring to this statement? >=20 > "A server MUST accept download requests for an object that is still > being uploaded." yes. >=20 > That should indeed be a MAY to be consistent with the requirements > draft. Objections? ok. From richard.alimi@gmail.com Tue Oct 18 09:15:19 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBEB21F8BE5 for ; Tue, 18 Oct 2011 09:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cszk-7yyhi6e for ; Tue, 18 Oct 2011 09:15:18 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 970D221F8B84 for ; Tue, 18 Oct 2011 09:15:18 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so805197vcb.31 for ; Tue, 18 Oct 2011 09:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=X6x2fSoQeLDJo29XX0LPFtTuYwIg48KAHH5CjxDjL+E=; b=mCF2Dsp4Z5qttkCZRgSmvdfblQ5v1bVpLQp41pJ6vyotKjN/qWtz9U6ODFqUDSjV4B /eaZSxfI56cAmAXOUXsRc+geQ30u3giNEb3Q+OqSNF1s6zzWNrCBkYB0rSh2l3V0BZk5 LFOgeKL3/1MuplwJXayLRfL/DfpVa24od5EBk= Received: by 10.52.184.103 with SMTP id et7mr3235826vdc.35.1318954518020; Tue, 18 Oct 2011 09:15:18 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.52.186.39 with HTTP; Tue, 18 Oct 2011 09:14:56 -0700 (PDT) In-Reply-To: <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> From: Richard Alimi Date: Tue, 18 Oct 2011 09:14:56 -0700 X-Google-Sender-Auth: LjfgOnsmTi1Ixc4d7PZbrAo7uVU Message-ID: To: =?ISO-8859-1?Q?B=F6rje_Ohlman?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:15:19 -0000 On Tue, Oct 18, 2011 at 9:02 AM, B=F6rje Ohlman = wrote: > Comments inline... > > On 18 okt 2011, at 08.51, Richard Alimi wrote: > >> Hi B=F6rje, >> >> Thank you very much for the review. =A0Responses inline... >> >> On Mon, Oct 17, 2011 at 8:02 AM, B=F6rje Ohlman wrote: >>> >>> The previous comment that I do not see as addressed is how overbooking = of >>> resources should be dealt with in DECADE. This is probably to large ext= ent >>> an SLA issue, but I think it would raise the issue in this draft. In my >>> review of the previous draft I wrote: >>> >>> Is it allowed for decade service providers to oversell the resources of >>> their servers (both bandwidth and storage), similar to airline overbook= ing? >>> I think overbooking should be allowed to maximize resource utilization. >>> Especially regarding bandwidth I think it is unavoidable. It would be g= ood >>> if this was addressed in the draft, e.g. in 4.2. >> >> My personal feeling is that this is a question of policy and not a >> question for the protocol or architecture. =A0Do you think that leaving >> it out of scope will cause issues in the design or eventual protocol >> specification? =A0I could see policy, algorithms, and deployments >> changing based on whether oversubscription is used, but what do you >> think the protocol ramifications might be? =A0Presumably we will need >> the architecture/protocol to have all the nice features of any >> protocol such as overload handling anyways (those are already in the >> requirements). > > Ok, fine. > >> >>> 6.2.1 =A71 >>> In the first =A7 it is unclear if the client or the server is naming th= e >>> object. If both alternatives are allowed this should be stated explicit= ly >>> and it should be added a comment to the parameter NAME that it can be >>> empty. >>> Then in =A74 it is stated "The application that originates the objects = MUST >>> generate DECADE object names according to the naming specification in >>> Section 5.3." Is it sure that we want this? Sensors might want the serv= er to >>> generate the names. >> >> The original intent was for the name to be sent by the client, and >> then validated by the server. That said, I have only two reservations >> about having the server compute the name (if the client does not want >> to): >> (1) the server is forced to compute the hash which may be expensive. >> I might imagine certain cases where servers disable this (knowing the >> risks of not validating the hashes), in which case a request from such >> a client would be rejected. =A0I don't think this would be common, >> though. >> (2) the client must trust the server if this is done (otherwise the >> server can insert, remove, or completely fabricate the content and lie >> about the name). >> >> Therefore, I don't have a problem as long as the security >> consideration is made completely clear. >> >> Thoughts? > > I think both clients and servers =A0should be allowed to create name it i= s not up to the architecture to decide on what is appropriate in specific n= etwork environments. That's fine - but the security properties are different and need to be called out explicitly. Objections from others about allowing the server to compute the name? > >> >>> 6.2.1 last =A7 >>> It states "Specifics regarding error handling, including additional >>> error conditions, precedence for returned errors and its relation with >>> server policy, are deferred to eventual protocol specification." Should= not >>> lack of resources be mentioned here as well as it is an obvious issue. = This >>> would be a possible place to add a comment on the issue with overbookin= gs. >> >> Would additionally mentioning "overload conditions" (as it is worded >> in the requirements draft) suffice? > > Fine. > >> >>> 7 =A72 >>> It states "All data operations are performed on behalf of DECADE client= s via >>> explicit instruction, ..." >>> It is unclear from this text if the client has to be using the DECADE >>> Protocol to perform this action or if an management or application prot= ocol >>> can be used to instruct the remote server. >> >> The intent was not to disallow access by administrative/management >> protocols. =A0Would dropping the word "all" from the beginning of the >> sentence help to clarify this? > > I think I should have included some more of the draft text here: > "All data operations are performed on behalf of DECADE clients > via explicit instruction, so additional capabilities are needed in > the DECADE client-server protocols DECADE clients must be able to > indicate to a DECADE server the following additional parameters:" Well, there is a missing period in there. Noted :) > > I think it is the formulation " additional capabilities are needed in > the DECADE client-server protocols" that is causing the problem by explic= itly mentioning the DECADE protocols, a more neutral formulation not mentio= ning specific protocols I think would help. > We could certainly drop the phrase "additional capabilities are needed in the DECADE client-server protocols", but I think it would be understood that we are only talking about DECADE (since thats what the document is about, and the protocol that would eventually be defined). Right? >> >>> Should it not also be allowed for >>> the client to delegate these operations to e.g. a cache managment >>> application? >> >> Can you clarify the use case? =A0Who owns/manages the cache management >> application? =A0Is it the same person as the DECADE server? =A0Is it the >> same person as the DECADE client? > > One example would be a customer of network (and DECADE server) provider t= hat just want to put data objects in it's 'local' DECADE storage and then w= ant the network provider to populate other DECADE servers to provide a flex= ible CDN like functionality for the published objects. > I think this case can be handled by the existing architecture. The client could give the entity doing the replication (the network provider in this case) tokens that provide read/write access to its data objects. If you wanted to short-circuit this case by having the client not give the tokens (since presumably the network provider owns the DECADE servers and could replicate objects using some mechanism other than DECADE), then that would be fine too - but that seems a bit too specialized of a use case for this document. >>> 7.1 =A75 >>> It states "Though explicitly supplying these may provide additional fre= edom, >>> it is not clear what benefit they might provide." >>> It is unclear what the "they" refers to. I have problems understanding = the >>> meaning of this sentence. >> >> "they" refers to the data object and operation parameters. =A0For >> example, a typical (normal) use case might be to request to download >> object 1 from Server A, but indicating that it must fetch object 1 >> from Server B first. =A0Extending that slightly, I could imagine >> constructing protocol messages to request to download object 1 from >> Server A, but indicating it must fetch object 2 from Server B first. >> There may be interesting use cases for something like that - this >> sentence was merely trying to point this out. >> >> We can drop this sentence if it creates confusion. > > Please do. > >> >>> 7.1 last =A7 >>> It states "In the case of a GET operation, the DECADE server is to retr= ieve >>> the data object from the remote server using the specified credentials = (via >>> a GET request to the remote server), and then return the object to the >>> client." >>> Why should the object be returned to the client? If this is just about = cache >>> management there is no reason to return the object to the client. >> >> No - it is not only about cache management. The client may not have >> the object yet. However, that said, I might imagine cases where the >> last step (downloading to the client itself) is optional, e.g., if it >> wishes to delay downloading it over the last mile for later. =A0We >> should add a note saying that it is optional. > > Fine. > >> >>> Further it states: "In the case of a PUT operation, the DECADE server i= s to >>> store the object from the client..." This sounds like the client making= this >>> PUT I thought this was about server to server communication. >> >> Yes - the server-to-server communication is explicitly controlled by the= client. >> >> Similarly, we should add a note here saying that the upload from the >> client to its own server is optional (the object may already exist at >> one server, and the client may want it replicated to another server). > > Ok. > >> >>> Also should not >>> policies for the object, e.g. ttl, be stored? >> >> Yes. This section states "DECADE re-uses the already-specified >> protocols to support operations directly between servers", and these >> were mentioned in Section 6. =A0Should we explicitly mention that such >> attributes can also be configured on requests involving >> server-to-server communication? > > Would be good for clarity. > >> >>> 8.1 first =A7 >>> It states "A DECADE server may choose to not fully store an object >>> before beginning to serve it." The 'may choose' is not consistent with = the >>> MUST requierment to be able to deliver before fully stored. >> >> Just to be sure, you are referring to this statement? >> >> =A0"A server MUST accept download requests for an object that is still >> being uploaded." > > yes. > >> >> That should indeed be a MAY to be consistent with the requirements >> draft. =A0Objections? > > ok. > > > Thanks again for your detailed reading of the document! Rich From borje.ohlman@ericsson.com Tue Oct 18 10:28:54 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EBF21F8C10 for ; Tue, 18 Oct 2011 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+zCpnZ5gF7G for ; Tue, 18 Oct 2011 10:28:53 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D647921F8BE9 for ; Tue, 18 Oct 2011 10:28:52 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-78-4e9db7530824 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C2.3D.13753.357BD9E4; Tue, 18 Oct 2011 19:28:52 +0200 (CEST) Received: from dhcp-147-214-183-82.ki.sw.ericsson.se (153.88.115.8) by smtps.internal.ericsson.com (153.88.115.84) with Microsoft SMTP Server id 8.3.137.0; Tue, 18 Oct 2011 19:28:50 +0200 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?Q?B=F6rje_Ohlman?= In-Reply-To: Date: Tue, 18 Oct 2011 19:28:53 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <5384B03A-1403-473B-AB94-AEAE58D76427@ericsson.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> To: Richard Alimi X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 17:28:54 -0000 For me your proposals are fine. No more comments. B=F6rje On 18 okt 2011, at 18.14, Richard Alimi wrote: > On Tue, Oct 18, 2011 at 9:02 AM, B=F6rje Ohlman = wrote: >> Comments inline... >>=20 >> On 18 okt 2011, at 08.51, Richard Alimi wrote: >>=20 >>> Hi B=F6rje, >>>=20 >>> Thank you very much for the review. Responses inline... >>>=20 >>> On Mon, Oct 17, 2011 at 8:02 AM, B=F6rje Ohlman = wrote: >>>>=20 >>>> The previous comment that I do not see as addressed is how = overbooking of >>>> resources should be dealt with in DECADE. This is probably to large = extent >>>> an SLA issue, but I think it would raise the issue in this draft. = In my >>>> review of the previous draft I wrote: >>>>=20 >>>> Is it allowed for decade service providers to oversell the = resources of >>>> their servers (both bandwidth and storage), similar to airline = overbooking? >>>> I think overbooking should be allowed to maximize resource = utilization. >>>> Especially regarding bandwidth I think it is unavoidable. It would = be good >>>> if this was addressed in the draft, e.g. in 4.2. >>>=20 >>> My personal feeling is that this is a question of policy and not a >>> question for the protocol or architecture. Do you think that = leaving >>> it out of scope will cause issues in the design or eventual protocol >>> specification? I could see policy, algorithms, and deployments >>> changing based on whether oversubscription is used, but what do you >>> think the protocol ramifications might be? Presumably we will need >>> the architecture/protocol to have all the nice features of any >>> protocol such as overload handling anyways (those are already in the >>> requirements). >>=20 >> Ok, fine. >>=20 >>>=20 >>>> 6.2.1 =A71 >>>> In the first =A7 it is unclear if the client or the server is = naming the >>>> object. If both alternatives are allowed this should be stated = explicitly >>>> and it should be added a comment to the parameter NAME that it can = be >>>> empty. >>>> Then in =A74 it is stated "The application that originates the = objects MUST >>>> generate DECADE object names according to the naming specification = in >>>> Section 5.3." Is it sure that we want this? Sensors might want the = server to >>>> generate the names. >>>=20 >>> The original intent was for the name to be sent by the client, and >>> then validated by the server. That said, I have only two = reservations >>> about having the server compute the name (if the client does not = want >>> to): >>> (1) the server is forced to compute the hash which may be expensive. >>> I might imagine certain cases where servers disable this (knowing = the >>> risks of not validating the hashes), in which case a request from = such >>> a client would be rejected. I don't think this would be common, >>> though. >>> (2) the client must trust the server if this is done (otherwise the >>> server can insert, remove, or completely fabricate the content and = lie >>> about the name). >>>=20 >>> Therefore, I don't have a problem as long as the security >>> consideration is made completely clear. >>>=20 >>> Thoughts? >>=20 >> I think both clients and servers should be allowed to create name it = is not up to the architecture to decide on what is appropriate in = specific network environments. >=20 > That's fine - but the security properties are different and need to be > called out explicitly. Objections from others about allowing the > server to compute the name? >=20 >>=20 >>>=20 >>>> 6.2.1 last =A7 >>>> It states "Specifics regarding error handling, including additional >>>> error conditions, precedence for returned errors and its relation = with >>>> server policy, are deferred to eventual protocol specification." = Should not >>>> lack of resources be mentioned here as well as it is an obvious = issue. This >>>> would be a possible place to add a comment on the issue with = overbookings. >>>=20 >>> Would additionally mentioning "overload conditions" (as it is worded >>> in the requirements draft) suffice? >>=20 >> Fine. >>=20 >>>=20 >>>> 7 =A72 >>>> It states "All data operations are performed on behalf of DECADE = clients via >>>> explicit instruction, ..." >>>> It is unclear from this text if the client has to be using the = DECADE >>>> Protocol to perform this action or if an management or application = protocol >>>> can be used to instruct the remote server. >>>=20 >>> The intent was not to disallow access by administrative/management >>> protocols. Would dropping the word "all" from the beginning of the >>> sentence help to clarify this? >>=20 >> I think I should have included some more of the draft text here: >> "All data operations are performed on behalf of DECADE clients >> via explicit instruction, so additional capabilities are needed in >> the DECADE client-server protocols DECADE clients must be able to >> indicate to a DECADE server the following additional parameters:" >=20 > Well, there is a missing period in there. Noted :) >=20 >>=20 >> I think it is the formulation " additional capabilities are needed in >> the DECADE client-server protocols" that is causing the problem by = explicitly mentioning the DECADE protocols, a more neutral formulation = not mentioning specific protocols I think would help. >>=20 >=20 > We could certainly drop the phrase "additional capabilities are needed > in the DECADE client-server protocols", but I think it would be > understood that we are only talking about DECADE (since thats what the > document is about, and the protocol that would eventually be defined). > Right? >=20 >>>=20 >>>> Should it not also be allowed for >>>> the client to delegate these operations to e.g. a cache managment >>>> application? >>>=20 >>> Can you clarify the use case? Who owns/manages the cache management >>> application? Is it the same person as the DECADE server? Is it the >>> same person as the DECADE client? >>=20 >> One example would be a customer of network (and DECADE server) = provider that just want to put data objects in it's 'local' DECADE = storage and then want the network provider to populate other DECADE = servers to provide a flexible CDN like functionality for the published = objects. >>=20 >=20 > I think this case can be handled by the existing architecture. The > client could give the entity doing the replication (the network > provider in this case) tokens that provide read/write access to its > data objects. >=20 > If you wanted to short-circuit this case by having the client not give > the tokens (since presumably the network provider owns the DECADE > servers and could replicate objects using some mechanism other than > DECADE), then that would be fine too - but that seems a bit too > specialized of a use case for this document. >=20 >>>> 7.1 =A75 >>>> It states "Though explicitly supplying these may provide additional = freedom, >>>> it is not clear what benefit they might provide." >>>> It is unclear what the "they" refers to. I have problems = understanding the >>>> meaning of this sentence. >>>=20 >>> "they" refers to the data object and operation parameters. For >>> example, a typical (normal) use case might be to request to download >>> object 1 from Server A, but indicating that it must fetch object 1 >>> from Server B first. Extending that slightly, I could imagine >>> constructing protocol messages to request to download object 1 from >>> Server A, but indicating it must fetch object 2 from Server B first. >>> There may be interesting use cases for something like that - this >>> sentence was merely trying to point this out. >>>=20 >>> We can drop this sentence if it creates confusion. >>=20 >> Please do. >>=20 >>>=20 >>>> 7.1 last =A7 >>>> It states "In the case of a GET operation, the DECADE server is to = retrieve >>>> the data object from the remote server using the specified = credentials (via >>>> a GET request to the remote server), and then return the object to = the >>>> client." >>>> Why should the object be returned to the client? If this is just = about cache >>>> management there is no reason to return the object to the client. >>>=20 >>> No - it is not only about cache management. The client may not have >>> the object yet. However, that said, I might imagine cases where the >>> last step (downloading to the client itself) is optional, e.g., if = it >>> wishes to delay downloading it over the last mile for later. We >>> should add a note saying that it is optional. >>=20 >> Fine. >>=20 >>>=20 >>>> Further it states: "In the case of a PUT operation, the DECADE = server is to >>>> store the object from the client..." This sounds like the client = making this >>>> PUT I thought this was about server to server communication. >>>=20 >>> Yes - the server-to-server communication is explicitly controlled by = the client. >>>=20 >>> Similarly, we should add a note here saying that the upload from the >>> client to its own server is optional (the object may already exist = at >>> one server, and the client may want it replicated to another = server). >>=20 >> Ok. >>=20 >>>=20 >>>> Also should not >>>> policies for the object, e.g. ttl, be stored? >>>=20 >>> Yes. This section states "DECADE re-uses the already-specified >>> protocols to support operations directly between servers", and these >>> were mentioned in Section 6. Should we explicitly mention that such >>> attributes can also be configured on requests involving >>> server-to-server communication? >>=20 >> Would be good for clarity. >>=20 >>>=20 >>>> 8.1 first =A7 >>>> It states "A DECADE server may choose to not fully store an object >>>> before beginning to serve it." The 'may choose' is not consistent = with the >>>> MUST requierment to be able to deliver before fully stored. >>>=20 >>> Just to be sure, you are referring to this statement? >>>=20 >>> "A server MUST accept download requests for an object that is still >>> being uploaded." >>=20 >> yes. >>=20 >>>=20 >>> That should indeed be a MAY to be consistent with the requirements >>> draft. Objections? >>=20 >> ok. >>=20 >>=20 >>=20 >=20 > Thanks again for your detailed reading of the document! > Rich From haibin.song@huawei.com Thu Oct 20 19:27:13 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E06921F85F2 for ; Thu, 20 Oct 2011 19:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.885 X-Spam-Level: X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFr+HlGL3e-U for ; Thu, 20 Oct 2011 19:27:12 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB1421F85D1 for ; Thu, 20 Oct 2011 19:27:12 -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 <0LTE00EB89G51B@szxga03-in.huawei.com> for decade@ietf.org; Fri, 21 Oct 2011 10:26:29 +0800 (CST) Received: from szxrg02-dlp.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 <0LTE001019G5XF@szxga03-in.huawei.com> for decade@ietf.org; Fri, 21 Oct 2011 10:26:29 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI65205; Fri, 21 Oct 2011 10:26:27 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 10:26:19 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.75]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0270.001; Fri, 21 Oct 2011 10:26:18 +0800 Date: Fri, 21 Oct 2011 02:26:17 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.129] To: Richard Alimi , =?iso-8859-1?Q?B=F6rje_Ohlman?= Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [decade] Start of WGLC for draft-ietf-decade-reqs-04 Thread-index: AQHMfqEvDjbZqaVGCUm/ijxtVozW4pV7QMwAgANzSQCAB3zREA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1437EB69-B337-4B88-80D8-5BF4FEB42C34@ericsson.com> Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 02:27:13 -0000 > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > Richard Alimi > Sent: Sunday, October 16, 2011 11:53 PM > To: B=F6rje Ohlman > Cc: decade ietf > Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 >=20 > On Fri, Oct 14, 2011 at 4:11 AM, B=F6rje Ohlman > wrote: > > Hi, > > I think the draft is in very good shape, thanks to the authors for an > > excellent job. All my previous comments are addressed by this draft. Ho= wever > > looking through it last night I have some additional comments. > > ---------- > > > > 5.1. Immutable Data > > REQUIREMENT(S): DECADE MUST provide the ability to manage data > > objects that are immutable once they are written to storage. > > > > I think this requirement is a bit unclear on what is actually meant. My > > understanding from our discussions is that DECADE MUST *only* store > > immutable data objects. If that is the intention, I think that should b= e > > stated more clearly. I don't think the word "ability" is the best to ex= press > > this requirement. An alternative formulation could be: > > "DECADE MUST only store and manage data=A0objects that are immutable on= ce > they > > are written to storage." > > If I have misunderstood the intention of this requirement and that it s= hould > > also be possible to store mutable data in DECADE servers, then I think = such > > an explicit requirement should be added. >=20 > Your understanding was correct, and I agree with your suggested text. > Any complaints from others with adopting that? >=20 I would agree with the change. > > ------------ > > > > 5.2. Explicit Deletion of Data > > REQUIREMENT(S): DECADE MUST support the ability for a DECADE client > > to explicitly delete data from its own in-network storage. > > > > RATIONALE: A DECADE client may continually be writing data to its > > in-network storage. Since there may be a limit (e.g., imposed by > > the storage provider) to how much total storage can be used, some > > data may need to be removed to make room for additional data. A > > DECADE client should be able to explicitly remove particular > > data. This may be implemented using existing protocols. > > > > When reading the rationale for this requirement I start to thinking tha= t we > > might want to add something about automatic removal of old data accordi= ng to > > some policy, e.g. that DECADE storage servers SHOULD be able to remove = old > > data according to some policy, e.g. LLRU. This should be of interest, e= .g. > > when a quota is being filled up, to avoid having to deny further writin= gs. > > This should be=A0especially=A0relevant in the mentioned case of continu= ous > > writings, =A0e.g.=A0for=A0streaming data. >=20 > This is a very good question. Two comments here: > (1) We already have 4.4.3 which allows objects to be deleted after a > time-to-live, which can help with the streaming case. > (2) I think what you are proposing is a more general mechanism for > cache-replacement. While I think that would be a nice feature to > have, I'm a bit concerned about the complexity. I might imagine > something as complex as designing a new specification language for > custom cache replacement policies, or something as simple as "we > specify LRU and LFU - the rest are extensions". The latter might work > in certain cases, but for cases such as VoD / DVR type stuff, I'm not > sure either is sufficient (I may just not have watched the program > yet). Furthermore, what happens when multiple applications (run by > the same user, accessing the same account) each want to have their own > cache replacement policy and they might be in conflict? >=20 > Thoughts? >=20 I think imposing some intelligent data deletion mechanism will make the des= ign complicated. But TTL should be okay. Shall we leave them to the applica= tions to implement and make DECADE design as simple as possible? BR, -Haibin (as individual) > Thanks, > Rich >=20 > > ----------------- > > B=F6rje > > > > > > > > On 29 sep 2011, at 14.12, Woundy, Richard wrote: > > > > Folks, > > > > Haibin and I are starting the working group last call for > > > draft-ietf-decade-reqs-04,=A0http://datatracker.ietf.org/doc/draft-ietf-d= ecade-req > s/, > > to be completed by Monday October 17. Please send all concerns, suggest= ions > > and comments about this internet-draft to the DECADE mailing > > list,=A0decade@ietf.org. > > > > Authors, please do not make any additional changes to the internet-draf= t > > unless directed by the WG chairs. > > > > Draft reviewers, it would be helpful to get your confirmation that your > > previous review comments have been correctly reflected in this version. > > > > Thanks. > > > > -- Rich and Haibin > > _______________________________________________ > > 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 > > > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From haibin.song@huawei.com Thu Oct 20 20:08:27 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EDD11E808F for ; Thu, 20 Oct 2011 20:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRMTOUSSTnse for ; Thu, 20 Oct 2011 20:08:26 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B1D211F0C3B for ; Thu, 20 Oct 2011 20:08:25 -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 <0LTE00CN4BDOHB@szxga04-in.huawei.com> for decade@ietf.org; Fri, 21 Oct 2011 11:08:12 +0800 (CST) Received: from szxrg01-dlp.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 <0LTE0014ABDN17@szxga04-in.huawei.com> for decade@ietf.org; Fri, 21 Oct 2011 11:08:12 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEP21295; Fri, 21 Oct 2011 11:08:11 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 11:08:04 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.75]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Fri, 21 Oct 2011 11:08:00 +0800 Date: Fri, 21 Oct 2011 03:07:59 +0000 From: Songhaibin In-reply-to: <5384B03A-1403-473B-AB94-AEAE58D76427@ericsson.com> X-Originating-IP: [10.138.41.129] To: =?iso-8859-1?Q?B=F6rje_Ohlman?= , Richard Alimi Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [decade] Start of WGLC for draft-ietf-decade-arch-03 Thread-index: AQHMfqFTeDHHyrbYIEqOVtMSowYBoZWAOEQAgAEJHYCAAJnZgIAAA40AgAAUqoCABEuT4A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> <5384B03A-1403-473B-AB94-AEAE58D76427@ericsson.com> Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 03:08:27 -0000 Hi, >>>> 8.1 first =A7 >>>> It states "A DECADE server may choose to not fully store an object=20 >>>> before beginning to serve it." The 'may choose' is not consistent=20 >>>> with the MUST requierment to be able to deliver before fully stored. >>>=20 >>> Just to be sure, you are referring to this statement? >>>=20 >>> "A server MUST accept download requests for an object that is still=20 >>> being uploaded." >>=20 >> yes. >>=20 >>>=20 >>> That should indeed be a MAY to be consistent with the requirements=20 >>> draft. Objections? Shall we say the server "MUST" have the ability to serve the objects that i= s being uploaded, while the server "MAY" choose to do it? BR, -Haibin > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > B?rje Ohlman > Sent: Wednesday, October 19, 2011 1:29 AM > To: Richard Alimi > Cc: decade ietf > Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 >=20 > For me your proposals are fine. No more comments. >=20 > B=F6rje >=20 > On 18 okt 2011, at 18.14, Richard Alimi wrote: >=20 > > On Tue, Oct 18, 2011 at 9:02 AM, B=F6rje Ohlman > wrote: > >> Comments inline... > >> > >> On 18 okt 2011, at 08.51, Richard Alimi wrote: > >> > >>> Hi B=F6rje, > >>> > >>> Thank you very much for the review. Responses inline... > >>> > >>> On Mon, Oct 17, 2011 at 8:02 AM, B=F6rje Ohlman > wrote: > >>>> > >>>> The previous comment that I do not see as addressed is how overbooki= ng > of > >>>> resources should be dealt with in DECADE. This is probably to large = extent > >>>> an SLA issue, but I think it would raise the issue in this draft. In= my > >>>> review of the previous draft I wrote: > >>>> > >>>> Is it allowed for decade service providers to oversell the resources= of > >>>> their servers (both bandwidth and storage), similar to airline overb= ooking? > >>>> I think overbooking should be allowed to maximize resource utilizati= on. > >>>> Especially regarding bandwidth I think it is unavoidable. It would b= e good > >>>> if this was addressed in the draft, e.g. in 4.2. > >>> > >>> My personal feeling is that this is a question of policy and not a > >>> question for the protocol or architecture. Do you think that leaving > >>> it out of scope will cause issues in the design or eventual protocol > >>> specification? I could see policy, algorithms, and deployments > >>> changing based on whether oversubscription is used, but what do you > >>> think the protocol ramifications might be? Presumably we will need > >>> the architecture/protocol to have all the nice features of any > >>> protocol such as overload handling anyways (those are already in the > >>> requirements). > >> > >> Ok, fine. > >> > >>> > >>>> 6.2.1 =A71 > >>>> In the first =A7 it is unclear if the client or the server is naming= the > >>>> object. If both alternatives are allowed this should be stated expli= citly > >>>> and it should be added a comment to the parameter NAME that it can b= e > >>>> empty. > >>>> Then in =A74 it is stated "The application that originates the objec= ts MUST > >>>> generate DECADE object names according to the naming specification i= n > >>>> Section 5.3." Is it sure that we want this? Sensors might want the s= erver to > >>>> generate the names. > >>> > >>> The original intent was for the name to be sent by the client, and > >>> then validated by the server. That said, I have only two reservations > >>> about having the server compute the name (if the client does not want > >>> to): > >>> (1) the server is forced to compute the hash which may be expensive. > >>> I might imagine certain cases where servers disable this (knowing the > >>> risks of not validating the hashes), in which case a request from suc= h > >>> a client would be rejected. I don't think this would be common, > >>> though. > >>> (2) the client must trust the server if this is done (otherwise the > >>> server can insert, remove, or completely fabricate the content and li= e > >>> about the name). > >>> > >>> Therefore, I don't have a problem as long as the security > >>> consideration is made completely clear. > >>> > >>> Thoughts? > >> > >> I think both clients and servers should be allowed to create name it = is not up > to the architecture to decide on what is appropriate in specific network > environments. > > > > That's fine - but the security properties are different and need to be > > called out explicitly. Objections from others about allowing the > > server to compute the name? > > > >> > >>> > >>>> 6.2.1 last =A7 > >>>> It states "Specifics regarding error handling, including additional > >>>> error conditions, precedence for returned errors and its relation wi= th > >>>> server policy, are deferred to eventual protocol specification." Sho= uld not > >>>> lack of resources be mentioned here as well as it is an obvious issu= e. This > >>>> would be a possible place to add a comment on the issue with > overbookings. > >>> > >>> Would additionally mentioning "overload conditions" (as it is worded > >>> in the requirements draft) suffice? > >> > >> Fine. > >> > >>> > >>>> 7 =A72 > >>>> It states "All data operations are performed on behalf of DECADE cli= ents via > >>>> explicit instruction, ..." > >>>> It is unclear from this text if the client has to be using the DECAD= E > >>>> Protocol to perform this action or if an management or application p= rotocol > >>>> can be used to instruct the remote server. > >>> > >>> The intent was not to disallow access by administrative/management > >>> protocols. Would dropping the word "all" from the beginning of the > >>> sentence help to clarify this? > >> > >> I think I should have included some more of the draft text here: > >> "All data operations are performed on behalf of DECADE clients > >> via explicit instruction, so additional capabilities are needed in > >> the DECADE client-server protocols DECADE clients must be able to > >> indicate to a DECADE server the following additional parameters:" > > > > Well, there is a missing period in there. Noted :) > > > >> > >> I think it is the formulation " additional capabilities are needed in > >> the DECADE client-server protocols" that is causing the problem by exp= licitly > mentioning the DECADE protocols, a more neutral formulation not mentionin= g > specific protocols I think would help. > >> > > > > We could certainly drop the phrase "additional capabilities are needed > > in the DECADE client-server protocols", but I think it would be > > understood that we are only talking about DECADE (since thats what the > > document is about, and the protocol that would eventually be defined). > > Right? > > > >>> > >>>> Should it not also be allowed for > >>>> the client to delegate these operations to e.g. a cache managment > >>>> application? > >>> > >>> Can you clarify the use case? Who owns/manages the cache management > >>> application? Is it the same person as the DECADE server? Is it the > >>> same person as the DECADE client? > >> > >> One example would be a customer of network (and DECADE server) provide= r > that just want to put data objects in it's 'local' DECADE storage and the= n want the > network provider to populate other DECADE servers to provide a flexible C= DN > like functionality for the published objects. > >> > > > > I think this case can be handled by the existing architecture. The > > client could give the entity doing the replication (the network > > provider in this case) tokens that provide read/write access to its > > data objects. > > > > If you wanted to short-circuit this case by having the client not give > > the tokens (since presumably the network provider owns the DECADE > > servers and could replicate objects using some mechanism other than > > DECADE), then that would be fine too - but that seems a bit too > > specialized of a use case for this document. > > > >>>> 7.1 =A75 > >>>> It states "Though explicitly supplying these may provide additional > freedom, > >>>> it is not clear what benefit they might provide." > >>>> It is unclear what the "they" refers to. I have problems understandi= ng the > >>>> meaning of this sentence. > >>> > >>> "they" refers to the data object and operation parameters. For > >>> example, a typical (normal) use case might be to request to download > >>> object 1 from Server A, but indicating that it must fetch object 1 > >>> from Server B first. Extending that slightly, I could imagine > >>> constructing protocol messages to request to download object 1 from > >>> Server A, but indicating it must fetch object 2 from Server B first. > >>> There may be interesting use cases for something like that - this > >>> sentence was merely trying to point this out. > >>> > >>> We can drop this sentence if it creates confusion. > >> > >> Please do. > >> > >>> > >>>> 7.1 last =A7 > >>>> It states "In the case of a GET operation, the DECADE server is to r= etrieve > >>>> the data object from the remote server using the specified credentia= ls (via > >>>> a GET request to the remote server), and then return the object to t= he > >>>> client." > >>>> Why should the object be returned to the client? If this is just abo= ut cache > >>>> management there is no reason to return the object to the client. > >>> > >>> No - it is not only about cache management. The client may not have > >>> the object yet. However, that said, I might imagine cases where the > >>> last step (downloading to the client itself) is optional, e.g., if it > >>> wishes to delay downloading it over the last mile for later. We > >>> should add a note saying that it is optional. > >> > >> Fine. > >> > >>> > >>>> Further it states: "In the case of a PUT operation, the DECADE serve= r is to > >>>> store the object from the client..." This sounds like the client mak= ing this > >>>> PUT I thought this was about server to server communication. > >>> > >>> Yes - the server-to-server communication is explicitly controlled by = the client. > >>> > >>> Similarly, we should add a note here saying that the upload from the > >>> client to its own server is optional (the object may already exist at > >>> one server, and the client may want it replicated to another server). > >> > >> Ok. > >> > >>> > >>>> Also should not > >>>> policies for the object, e.g. ttl, be stored? > >>> > >>> Yes. This section states "DECADE re-uses the already-specified > >>> protocols to support operations directly between servers", and these > >>> were mentioned in Section 6. Should we explicitly mention that such > >>> attributes can also be configured on requests involving > >>> server-to-server communication? > >> > >> Would be good for clarity. > >> > >>> > >>>> 8.1 first =A7 > >>>> It states "A DECADE server may choose to not fully store an object > >>>> before beginning to serve it." The 'may choose' is not consistent wi= th the > >>>> MUST requierment to be able to deliver before fully stored. > >>> > >>> Just to be sure, you are referring to this statement? > >>> > >>> "A server MUST accept download requests for an object that is still > >>> being uploaded." > >> > >> yes. > >> > >>> > >>> That should indeed be a MAY to be consistent with the requirements > >>> draft. Objections? > >> > >> ok. > >> > >> > >> > > > > Thanks again for your detailed reading of the document! > > Rich >=20 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From richard.alimi@gmail.com Thu Oct 20 21:30:54 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB0521F84DC for ; Thu, 20 Oct 2011 21:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7erqFTS9MOGQ for ; Thu, 20 Oct 2011 21:30:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 34CE521F84DB for ; Thu, 20 Oct 2011 21:30:53 -0700 (PDT) Received: by iabn5 with SMTP id n5so4705626iab.31 for ; Thu, 20 Oct 2011 21:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=mjguQ186oycxTiYZxtQp8aMk6IsH4QThg9Pq9JTYqVY=; b=HpWTZ/98HxerwfLsBdsdAzmFVELR8E3ZQKu/AqrH+jgMxKguWPSCD3+9FIElH8vMqC KiJJL2R7v6swLUqvW0f2ZDa8EkcIbxImPgIiBY128S/G14jqsZEIt8QpH3t/7YteMLAI XhHt+dUl6xkaeD0qGpidOCmfGFjn7WKJNl4Tw= Received: by 10.231.28.30 with SMTP id k30mr5307721ibc.25.1319171449111; Thu, 20 Oct 2011 21:30:49 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.152.79 with HTTP; Thu, 20 Oct 2011 21:30:29 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1437EB69-B337-4B88-80D8-5BF4FEB42C34@ericsson.com> From: Richard Alimi Date: Thu, 20 Oct 2011 21:30:29 -0700 X-Google-Sender-Auth: MS2fPOBJAkeEXjvqYtQB1-cr3TA Message-ID: To: Songhaibin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 04:30:54 -0000 On Thu, Oct 20, 2011 at 7:26 PM, Songhaibin wrote: > > >> -----Original Message----- >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf= Of >> Richard Alimi >> Sent: Sunday, October 16, 2011 11:53 PM >> To: B=F6rje Ohlman >> Cc: decade ietf >> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 >> >> On Fri, Oct 14, 2011 at 4:11 AM, B=F6rje Ohlman >> wrote: >> > Hi, >> > I think the draft is in very good shape, thanks to the authors for an >> > excellent job. All my previous comments are addressed by this draft. H= owever >> > looking through it last night I have some additional comments. >> > ---------- >> > >> > 5.1. Immutable Data >> > REQUIREMENT(S): DECADE MUST provide the ability to manage data >> > objects that are immutable once they are written to storage. >> > >> > I think this requirement is a bit unclear on what is actually meant. M= y >> > understanding from our discussions is that DECADE MUST *only* store >> > immutable data objects. If that is the intention, I think that should = be >> > stated more clearly. I don't think the word "ability" is the best to e= xpress >> > this requirement. An alternative formulation could be: >> > "DECADE MUST only store and manage data=A0objects that are immutable o= nce >> they >> > are written to storage." >> > If I have misunderstood the intention of this requirement and that it = should >> > also be possible to store mutable data in DECADE servers, then I think= such >> > an explicit requirement should be added. >> >> Your understanding was correct, and I agree with your suggested text. >> Any complaints from others with adopting that? >> > > I would agree with the change. > >> > ------------ >> > >> > 5.2. Explicit Deletion of Data >> > REQUIREMENT(S): DECADE MUST support the ability for a DECADE client >> > to explicitly delete data from its own in-network storage. >> > >> > RATIONALE: A DECADE client may continually be writing data to its >> > in-network storage. Since there may be a limit (e.g., imposed by >> > the storage provider) to how much total storage can be used, some >> > data may need to be removed to make room for additional data. A >> > DECADE client should be able to explicitly remove particular >> > data. This may be implemented using existing protocols. >> > >> > When reading the rationale for this requirement I start to thinking th= at we >> > might want to add something about automatic removal of old data accord= ing to >> > some policy, e.g. that DECADE storage servers SHOULD be able to remove= old >> > data according to some policy, e.g. LLRU. This should be of interest, = e.g. >> > when a quota is being filled up, to avoid having to deny further writi= ngs. >> > This should be=A0especially=A0relevant in the mentioned case of contin= uous >> > writings, =A0e.g.=A0for=A0streaming data. >> >> This is a very good question. =A0Two comments here: >> (1) We already have 4.4.3 which allows objects to be deleted after a >> time-to-live, which can help with the streaming case. >> (2) I think what you are proposing is a more general mechanism for >> cache-replacement. =A0While I think that would be a nice feature to >> have, I'm a bit concerned about the complexity. =A0I might imagine >> something as complex as designing a new specification language for >> custom cache replacement policies, or something as simple as "we >> specify LRU and LFU - the rest are extensions". =A0The latter might work >> in certain cases, but for cases such as VoD / DVR type stuff, I'm not >> sure either is sufficient (I may just not have watched the program >> yet). =A0Furthermore, what happens when multiple applications (run by >> the same user, accessing the same account) each want to have their own >> cache replacement policy and they might be in conflict? >> >> Thoughts? >> > > I think imposing some intelligent data deletion mechanism will make the d= esign complicated. But TTL should be okay. Shall we leave them to the appli= cations to implement and make DECADE design as simple as possible? > I agree with having only TTL for now. Additional deletion policies might be done as extensions at a later time too. Rich > BR, > -Haibin (as individual) > > >> Thanks, >> Rich >> >> > ----------------- >> > B=F6rje >> > >> > >> > >> > On 29 sep 2011, at 14.12, Woundy, Richard wrote: >> > >> > Folks, >> > >> > Haibin and I are starting the working group last call for >> > >> draft-ietf-decade-reqs-04,=A0http://datatracker.ietf.org/doc/draft-ietf-= decade-req >> s/, >> > to be completed by Monday October 17. Please send all concerns, sugges= tions >> > and comments about this internet-draft to the DECADE mailing >> > list,=A0decade@ietf.org. >> > >> > Authors, please do not make any additional changes to the internet-dra= ft >> > unless directed by the WG chairs. >> > >> > Draft reviewers, it would be helpful to get your confirmation that you= r >> > previous review comments have been correctly reflected in this version= . >> > >> > Thanks. >> > >> > -- Rich and Haibin >> > _______________________________________________ >> > 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 >> > >> > >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade > From borje.ohlman@ericsson.com Thu Oct 20 22:47:46 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D041721F8573 for ; Thu, 20 Oct 2011 22:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.97 X-Spam-Level: X-Spam-Status: No, score=-5.97 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnMsBdmGoehL for ; Thu, 20 Oct 2011 22:47:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9890021F8569 for ; Thu, 20 Oct 2011 22:47:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-89-4ea1077fe84d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 24.AE.13753.F7701AE4; Fri, 21 Oct 2011 07:47:43 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.124]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 21 Oct 2011 07:47:42 +0200 From: =?utf-8?B?QsO2cmplIE9obG1hbg==?= To: Songhaibin Date: Fri, 21 Oct 2011 07:47:41 +0200 Thread-Topic: [decade] Start of WGLC for draft-ietf-decade-arch-03 Thread-Index: AcyPtPMqc2YKr1RRTWSMNSWcNQl9NA== Message-ID: <957B23C6-63FE-4549-9606-C54B36061E30@ericsson.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> <5384B03A-1403-473B-AB94-AEAE58D76427@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 05:47:46 -0000 QmVsb3cuLg0KDQoNCg0KT24gMjEgb2t0IDIwMTEsIGF0IDA1OjA4LCAiU29uZ2hhaWJpbiIgPGhh aWJpbi5zb25nQGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+IEhpLA0KPiANCj4+Pj4+IDguMSBmaXJz dCDCpw0KPj4+Pj4gSXQgc3RhdGVzICJBIERFQ0FERSBzZXJ2ZXIgbWF5IGNob29zZSB0byBub3Qg ZnVsbHkgc3RvcmUgYW4gb2JqZWN0DQo+Pj4+PiBiZWZvcmUgYmVnaW5uaW5nIHRvIHNlcnZlIGl0 LiIgVGhlICdtYXkgY2hvb3NlJyBpcyBub3QgY29uc2lzdGVudA0KPj4+Pj4gd2l0aCB0aGUgTVVT VCByZXF1aWVybWVudCB0byBiZSBhYmxlIHRvIGRlbGl2ZXIgYmVmb3JlIGZ1bGx5IHN0b3JlZC4N Cj4+Pj4gDQo+Pj4+IEp1c3QgdG8gYmUgc3VyZSwgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhpcyBz dGF0ZW1lbnQ/DQo+Pj4+IA0KPj4+PiAiQSBzZXJ2ZXIgTVVTVCBhY2NlcHQgZG93bmxvYWQgcmVx dWVzdHMgZm9yIGFuIG9iamVjdCB0aGF0IGlzIHN0aWxsDQo+Pj4+IGJlaW5nIHVwbG9hZGVkLiIN Cj4+PiANCj4+PiB5ZXMuDQo+Pj4gDQo+Pj4+IA0KPj4+PiBUaGF0IHNob3VsZCBpbmRlZWQgYmUg YSBNQVkgdG8gYmUgY29uc2lzdGVudCB3aXRoIHRoZSByZXF1aXJlbWVudHMNCj4+Pj4gZHJhZnQu ICBPYmplY3Rpb25zPw0KPiANCj4gDQo+IFNoYWxsIHdlIHNheSB0aGUgc2VydmVyICJNVVNUIiBo YXZlIHRoZSBhYmlsaXR5IHRvIHNlcnZlIHRoZSBvYmplY3RzIHRoYXQgaXMgYmVpbmcgdXBsb2Fk ZWQsIHdoaWxlIHRoZSBzZXJ2ZXIgIk1BWSIgY2hvb3NlIHRvIGRvIGl0Pw0KPiANCj4gQlIsDQo+ IC1IYWliaW4NCj4gDQpTb3VuZHMgZ29vZCB0byBtZS4NCg0KICAgIELDtnJqZQ0KDQo+IA0KPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGRlY2FkZS1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4gQj9y amUgT2hsbWFuDQo+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTksIDIwMTEgMToyOSBBTQ0K Pj4gVG86IFJpY2hhcmQgQWxpbWkNCj4+IENjOiBkZWNhZGUgaWV0Zg0KPj4gU3ViamVjdDogUmU6 IFtkZWNhZGVdIFN0YXJ0IG9mIFdHTEMgZm9yIGRyYWZ0LWlldGYtZGVjYWRlLWFyY2gtMDMNCj4+ IA0KPj4gRm9yIG1lIHlvdXIgcHJvcG9zYWxzIGFyZSBmaW5lLiBObyBtb3JlIGNvbW1lbnRzLg0K Pj4gDQo+PiAgICAgIELDtnJqZQ0KPj4gDQo+PiBPbiAxOCBva3QgMjAxMSwgYXQgMTguMTQsIFJp Y2hhcmQgQWxpbWkgd3JvdGU6DQo+PiANCj4+PiBPbiBUdWUsIE9jdCAxOCwgMjAxMSBhdCA5OjAy IEFNLCBCw7ZyamUgT2hsbWFuIDxib3JqZS5vaGxtYW5AZXJpY3Nzb24uY29tPg0KPj4gd3JvdGU6 DQo+Pj4+IENvbW1lbnRzIGlubGluZS4uLg0KPj4+PiANCj4+Pj4gT24gMTggb2t0IDIwMTEsIGF0 IDA4LjUxLCBSaWNoYXJkIEFsaW1pIHdyb3RlOg0KPj4+PiANCj4+Pj4+IEhpIELDtnJqZSwNCj4+ Pj4+IA0KPj4+Pj4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIHJldmlldy4gIFJlc3BvbnNl cyBpbmxpbmUuLi4NCj4+Pj4+IA0KPj4+Pj4gT24gTW9uLCBPY3QgMTcsIDIwMTEgYXQgODowMiBB TSwgQsO2cmplIE9obG1hbg0KPj4gPEJvcmplLk9obG1hbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0K Pj4+Pj4+IA0KPj4+Pj4+IFRoZSBwcmV2aW91cyBjb21tZW50IHRoYXQgSSBkbyBub3Qgc2VlIGFz IGFkZHJlc3NlZCBpcyBob3cgb3ZlcmJvb2tpbmcNCj4+IG9mDQo+Pj4+Pj4gcmVzb3VyY2VzIHNo b3VsZCBiZSBkZWFsdCB3aXRoIGluIERFQ0FERS4gVGhpcyBpcyBwcm9iYWJseSB0byBsYXJnZSBl eHRlbnQNCj4+Pj4+PiBhbiBTTEEgaXNzdWUsIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIHJhaXNlIHRo ZSBpc3N1ZSBpbiB0aGlzIGRyYWZ0LiBJbiBteQ0KPj4+Pj4+IHJldmlldyBvZiB0aGUgcHJldmlv dXMgZHJhZnQgSSB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+PiBJcyBpdCBhbGxvd2VkIGZvciBkZWNh ZGUgc2VydmljZSBwcm92aWRlcnMgdG8gb3ZlcnNlbGwgdGhlIHJlc291cmNlcyBvZg0KPj4+Pj4+ IHRoZWlyIHNlcnZlcnMgKGJvdGggYmFuZHdpZHRoIGFuZCBzdG9yYWdlKSwgc2ltaWxhciB0byBh aXJsaW5lIG92ZXJib29raW5nPw0KPj4+Pj4+IEkgdGhpbmsgb3ZlcmJvb2tpbmcgc2hvdWxkIGJl IGFsbG93ZWQgdG8gbWF4aW1pemUgcmVzb3VyY2UgdXRpbGl6YXRpb24uDQo+Pj4+Pj4gRXNwZWNp YWxseSByZWdhcmRpbmcgYmFuZHdpZHRoIEkgdGhpbmsgaXQgaXMgdW5hdm9pZGFibGUuIEl0IHdv dWxkIGJlIGdvb2QNCj4+Pj4+PiBpZiB0aGlzIHdhcyBhZGRyZXNzZWQgaW4gdGhlIGRyYWZ0LCBl LmcuIGluIDQuMi4NCj4+Pj4+IA0KPj4+Pj4gTXkgcGVyc29uYWwgZmVlbGluZyBpcyB0aGF0IHRo aXMgaXMgYSBxdWVzdGlvbiBvZiBwb2xpY3kgYW5kIG5vdCBhDQo+Pj4+PiBxdWVzdGlvbiBmb3Ig dGhlIHByb3RvY29sIG9yIGFyY2hpdGVjdHVyZS4gIERvIHlvdSB0aGluayB0aGF0IGxlYXZpbmcN Cj4+Pj4+IGl0IG91dCBvZiBzY29wZSB3aWxsIGNhdXNlIGlzc3VlcyBpbiB0aGUgZGVzaWduIG9y IGV2ZW50dWFsIHByb3RvY29sDQo+Pj4+PiBzcGVjaWZpY2F0aW9uPyAgSSBjb3VsZCBzZWUgcG9s aWN5LCBhbGdvcml0aG1zLCBhbmQgZGVwbG95bWVudHMNCj4+Pj4+IGNoYW5naW5nIGJhc2VkIG9u IHdoZXRoZXIgb3ZlcnN1YnNjcmlwdGlvbiBpcyB1c2VkLCBidXQgd2hhdCBkbyB5b3UNCj4+Pj4+ IHRoaW5rIHRoZSBwcm90b2NvbCByYW1pZmljYXRpb25zIG1pZ2h0IGJlPyAgUHJlc3VtYWJseSB3 ZSB3aWxsIG5lZWQNCj4+Pj4+IHRoZSBhcmNoaXRlY3R1cmUvcHJvdG9jb2wgdG8gaGF2ZSBhbGwg dGhlIG5pY2UgZmVhdHVyZXMgb2YgYW55DQo+Pj4+PiBwcm90b2NvbCBzdWNoIGFzIG92ZXJsb2Fk IGhhbmRsaW5nIGFueXdheXMgKHRob3NlIGFyZSBhbHJlYWR5IGluIHRoZQ0KPj4+Pj4gcmVxdWly ZW1lbnRzKS4NCj4+Pj4gDQo+Pj4+IE9rLCBmaW5lLg0KPj4+PiANCj4+Pj4+IA0KPj4+Pj4+IDYu Mi4xIMKnMQ0KPj4+Pj4+IEluIHRoZSBmaXJzdCDCpyBpdCBpcyB1bmNsZWFyIGlmIHRoZSBjbGll bnQgb3IgdGhlIHNlcnZlciBpcyBuYW1pbmcgdGhlDQo+Pj4+Pj4gb2JqZWN0LiBJZiBib3RoIGFs dGVybmF0aXZlcyBhcmUgYWxsb3dlZCB0aGlzIHNob3VsZCBiZSBzdGF0ZWQgZXhwbGljaXRseQ0K Pj4+Pj4+IGFuZCBpdCBzaG91bGQgYmUgYWRkZWQgYSBjb21tZW50IHRvIHRoZSBwYXJhbWV0ZXIg TkFNRSB0aGF0IGl0IGNhbiBiZQ0KPj4+Pj4+IGVtcHR5Lg0KPj4+Pj4+IFRoZW4gaW4gwqc0IGl0 IGlzIHN0YXRlZCAiVGhlIGFwcGxpY2F0aW9uIHRoYXQgb3JpZ2luYXRlcyB0aGUgb2JqZWN0cyBN VVNUDQo+Pj4+Pj4gZ2VuZXJhdGUgREVDQURFIG9iamVjdCBuYW1lcyBhY2NvcmRpbmcgdG8gdGhl IG5hbWluZyBzcGVjaWZpY2F0aW9uIGluDQo+Pj4+Pj4gU2VjdGlvbiA1LjMuIiBJcyBpdCBzdXJl IHRoYXQgd2Ugd2FudCB0aGlzPyBTZW5zb3JzIG1pZ2h0IHdhbnQgdGhlIHNlcnZlciB0bw0KPj4+ Pj4+IGdlbmVyYXRlIHRoZSBuYW1lcy4NCj4+Pj4+IA0KPj4+Pj4gVGhlIG9yaWdpbmFsIGludGVu dCB3YXMgZm9yIHRoZSBuYW1lIHRvIGJlIHNlbnQgYnkgdGhlIGNsaWVudCwgYW5kDQo+Pj4+PiB0 aGVuIHZhbGlkYXRlZCBieSB0aGUgc2VydmVyLiBUaGF0IHNhaWQsIEkgaGF2ZSBvbmx5IHR3byBy ZXNlcnZhdGlvbnMNCj4+Pj4+IGFib3V0IGhhdmluZyB0aGUgc2VydmVyIGNvbXB1dGUgdGhlIG5h bWUgKGlmIHRoZSBjbGllbnQgZG9lcyBub3Qgd2FudA0KPj4+Pj4gdG8pOg0KPj4+Pj4gKDEpIHRo ZSBzZXJ2ZXIgaXMgZm9yY2VkIHRvIGNvbXB1dGUgdGhlIGhhc2ggd2hpY2ggbWF5IGJlIGV4cGVu c2l2ZS4NCj4+Pj4+IEkgbWlnaHQgaW1hZ2luZSBjZXJ0YWluIGNhc2VzIHdoZXJlIHNlcnZlcnMg ZGlzYWJsZSB0aGlzIChrbm93aW5nIHRoZQ0KPj4+Pj4gcmlza3Mgb2Ygbm90IHZhbGlkYXRpbmcg dGhlIGhhc2hlcyksIGluIHdoaWNoIGNhc2UgYSByZXF1ZXN0IGZyb20gc3VjaA0KPj4+Pj4gYSBj bGllbnQgd291bGQgYmUgcmVqZWN0ZWQuICBJIGRvbid0IHRoaW5rIHRoaXMgd291bGQgYmUgY29t bW9uLA0KPj4+Pj4gdGhvdWdoLg0KPj4+Pj4gKDIpIHRoZSBjbGllbnQgbXVzdCB0cnVzdCB0aGUg c2VydmVyIGlmIHRoaXMgaXMgZG9uZSAob3RoZXJ3aXNlIHRoZQ0KPj4+Pj4gc2VydmVyIGNhbiBp bnNlcnQsIHJlbW92ZSwgb3IgY29tcGxldGVseSBmYWJyaWNhdGUgdGhlIGNvbnRlbnQgYW5kIGxp ZQ0KPj4+Pj4gYWJvdXQgdGhlIG5hbWUpLg0KPj4+Pj4gDQo+Pj4+PiBUaGVyZWZvcmUsIEkgZG9u J3QgaGF2ZSBhIHByb2JsZW0gYXMgbG9uZyBhcyB0aGUgc2VjdXJpdHkNCj4+Pj4+IGNvbnNpZGVy YXRpb24gaXMgbWFkZSBjb21wbGV0ZWx5IGNsZWFyLg0KPj4+Pj4gDQo+Pj4+PiBUaG91Z2h0cz8N Cj4+Pj4gDQo+Pj4+IEkgdGhpbmsgYm90aCBjbGllbnRzIGFuZCBzZXJ2ZXJzICBzaG91bGQgYmUg YWxsb3dlZCB0byBjcmVhdGUgbmFtZSBpdCBpcyBub3QgdXANCj4+IHRvIHRoZSBhcmNoaXRlY3R1 cmUgdG8gZGVjaWRlIG9uIHdoYXQgaXMgYXBwcm9wcmlhdGUgaW4gc3BlY2lmaWMgbmV0d29yaw0K Pj4gZW52aXJvbm1lbnRzLg0KPj4+IA0KPj4+IFRoYXQncyBmaW5lIC0gYnV0IHRoZSBzZWN1cml0 eSBwcm9wZXJ0aWVzIGFyZSBkaWZmZXJlbnQgYW5kIG5lZWQgdG8gYmUNCj4+PiBjYWxsZWQgb3V0 IGV4cGxpY2l0bHkuICBPYmplY3Rpb25zIGZyb20gb3RoZXJzIGFib3V0IGFsbG93aW5nIHRoZQ0K Pj4+IHNlcnZlciB0byBjb21wdXRlIHRoZSBuYW1lPw0KPj4+IA0KPj4+PiANCj4+Pj4+IA0KPj4+ Pj4+IDYuMi4xIGxhc3QgwqcNCj4+Pj4+PiBJdCBzdGF0ZXMgIlNwZWNpZmljcyByZWdhcmRpbmcg ZXJyb3IgaGFuZGxpbmcsIGluY2x1ZGluZyBhZGRpdGlvbmFsDQo+Pj4+Pj4gZXJyb3IgY29uZGl0 aW9ucywgcHJlY2VkZW5jZSBmb3IgcmV0dXJuZWQgZXJyb3JzIGFuZCBpdHMgcmVsYXRpb24gd2l0 aA0KPj4+Pj4+IHNlcnZlciBwb2xpY3ksIGFyZSBkZWZlcnJlZCB0byBldmVudHVhbCBwcm90b2Nv bCBzcGVjaWZpY2F0aW9uLiIgU2hvdWxkIG5vdA0KPj4+Pj4+IGxhY2sgb2YgcmVzb3VyY2VzIGJl IG1lbnRpb25lZCBoZXJlIGFzIHdlbGwgYXMgaXQgaXMgYW4gb2J2aW91cyBpc3N1ZS4gVGhpcw0K Pj4+Pj4+IHdvdWxkIGJlIGEgcG9zc2libGUgcGxhY2UgdG8gYWRkIGEgY29tbWVudCBvbiB0aGUg aXNzdWUgd2l0aA0KPj4gb3ZlcmJvb2tpbmdzLg0KPj4+Pj4gDQo+Pj4+PiBXb3VsZCBhZGRpdGlv bmFsbHkgbWVudGlvbmluZyAib3ZlcmxvYWQgY29uZGl0aW9ucyIgKGFzIGl0IGlzIHdvcmRlZA0K Pj4+Pj4gaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCkgc3VmZmljZT8NCj4+Pj4gDQo+Pj4+IEZp bmUuDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gNyDCpzINCj4+Pj4+PiBJdCBzdGF0ZXMgIkFsbCBk YXRhIG9wZXJhdGlvbnMgYXJlIHBlcmZvcm1lZCBvbiBiZWhhbGYgb2YgREVDQURFIGNsaWVudHMg dmlhDQo+Pj4+Pj4gZXhwbGljaXQgaW5zdHJ1Y3Rpb24sIC4uLiINCj4+Pj4+PiBJdCBpcyB1bmNs ZWFyIGZyb20gdGhpcyB0ZXh0IGlmIHRoZSBjbGllbnQgaGFzIHRvIGJlIHVzaW5nIHRoZSBERUNB REUNCj4+Pj4+PiBQcm90b2NvbCB0byBwZXJmb3JtIHRoaXMgYWN0aW9uIG9yIGlmIGFuIG1hbmFn ZW1lbnQgb3IgYXBwbGljYXRpb24gcHJvdG9jb2wNCj4+Pj4+PiBjYW4gYmUgdXNlZCB0byBpbnN0 cnVjdCB0aGUgcmVtb3RlIHNlcnZlci4NCj4+Pj4+IA0KPj4+Pj4gVGhlIGludGVudCB3YXMgbm90 IHRvIGRpc2FsbG93IGFjY2VzcyBieSBhZG1pbmlzdHJhdGl2ZS9tYW5hZ2VtZW50DQo+Pj4+PiBw cm90b2NvbHMuICBXb3VsZCBkcm9wcGluZyB0aGUgd29yZCAiYWxsIiBmcm9tIHRoZSBiZWdpbm5p bmcgb2YgdGhlDQo+Pj4+PiBzZW50ZW5jZSBoZWxwIHRvIGNsYXJpZnkgdGhpcz8NCj4+Pj4gDQo+ Pj4+IEkgdGhpbmsgSSBzaG91bGQgaGF2ZSBpbmNsdWRlZCBzb21lIG1vcmUgb2YgdGhlIGRyYWZ0 IHRleHQgaGVyZToNCj4+Pj4gIkFsbCBkYXRhIG9wZXJhdGlvbnMgYXJlIHBlcmZvcm1lZCBvbiBi ZWhhbGYgb2YgREVDQURFIGNsaWVudHMNCj4+Pj4gdmlhIGV4cGxpY2l0IGluc3RydWN0aW9uLCBz byBhZGRpdGlvbmFsIGNhcGFiaWxpdGllcyBhcmUgbmVlZGVkIGluDQo+Pj4+IHRoZSBERUNBREUg Y2xpZW50LXNlcnZlciBwcm90b2NvbHMgREVDQURFIGNsaWVudHMgbXVzdCBiZSBhYmxlIHRvDQo+ Pj4+IGluZGljYXRlIHRvIGEgREVDQURFIHNlcnZlciB0aGUgZm9sbG93aW5nIGFkZGl0aW9uYWwg cGFyYW1ldGVyczoiDQo+Pj4gDQo+Pj4gV2VsbCwgdGhlcmUgaXMgYSBtaXNzaW5nIHBlcmlvZCBp biB0aGVyZS4gIE5vdGVkIDopDQo+Pj4gDQo+Pj4+IA0KPj4+PiBJIHRoaW5rIGl0IGlzIHRoZSBm b3JtdWxhdGlvbiAiIGFkZGl0aW9uYWwgY2FwYWJpbGl0aWVzIGFyZSBuZWVkZWQgaW4NCj4+Pj4g dGhlIERFQ0FERSBjbGllbnQtc2VydmVyIHByb3RvY29scyIgdGhhdCBpcyBjYXVzaW5nIHRoZSBw cm9ibGVtIGJ5IGV4cGxpY2l0bHkNCj4+IG1lbnRpb25pbmcgdGhlIERFQ0FERSBwcm90b2NvbHMs IGEgbW9yZSBuZXV0cmFsIGZvcm11bGF0aW9uIG5vdCBtZW50aW9uaW5nDQo+PiBzcGVjaWZpYyBw cm90b2NvbHMgSSB0aGluayB3b3VsZCBoZWxwLg0KPj4+PiANCj4+PiANCj4+PiBXZSBjb3VsZCBj ZXJ0YWlubHkgZHJvcCB0aGUgcGhyYXNlICJhZGRpdGlvbmFsIGNhcGFiaWxpdGllcyBhcmUgbmVl ZGVkDQo+Pj4gaW4gdGhlIERFQ0FERSBjbGllbnQtc2VydmVyIHByb3RvY29scyIsIGJ1dCBJIHRo aW5rIGl0IHdvdWxkIGJlDQo+Pj4gdW5kZXJzdG9vZCB0aGF0IHdlIGFyZSBvbmx5IHRhbGtpbmcg YWJvdXQgREVDQURFIChzaW5jZSB0aGF0cyB3aGF0IHRoZQ0KPj4+IGRvY3VtZW50IGlzIGFib3V0 LCBhbmQgdGhlIHByb3RvY29sIHRoYXQgd291bGQgZXZlbnR1YWxseSBiZSBkZWZpbmVkKS4NCj4+ PiBSaWdodD8NCj4+PiANCj4+Pj4+IA0KPj4+Pj4+IFNob3VsZCBpdCBub3QgYWxzbyBiZSBhbGxv d2VkIGZvcg0KPj4+Pj4+IHRoZSBjbGllbnQgdG8gZGVsZWdhdGUgdGhlc2Ugb3BlcmF0aW9ucyB0 byBlLmcuIGEgY2FjaGUgbWFuYWdtZW50DQo+Pj4+Pj4gYXBwbGljYXRpb24/DQo+Pj4+PiANCj4+ Pj4+IENhbiB5b3UgY2xhcmlmeSB0aGUgdXNlIGNhc2U/ICBXaG8gb3ducy9tYW5hZ2VzIHRoZSBj YWNoZSBtYW5hZ2VtZW50DQo+Pj4+PiBhcHBsaWNhdGlvbj8gIElzIGl0IHRoZSBzYW1lIHBlcnNv biBhcyB0aGUgREVDQURFIHNlcnZlcj8gIElzIGl0IHRoZQ0KPj4+Pj4gc2FtZSBwZXJzb24gYXMg dGhlIERFQ0FERSBjbGllbnQ/DQo+Pj4+IA0KPj4+PiBPbmUgZXhhbXBsZSB3b3VsZCBiZSBhIGN1 c3RvbWVyIG9mIG5ldHdvcmsgKGFuZCBERUNBREUgc2VydmVyKSBwcm92aWRlcg0KPj4gdGhhdCBq dXN0IHdhbnQgdG8gcHV0IGRhdGEgb2JqZWN0cyBpbiBpdCdzICdsb2NhbCcgREVDQURFIHN0b3Jh Z2UgYW5kIHRoZW4gd2FudCB0aGUNCj4+IG5ldHdvcmsgcHJvdmlkZXIgdG8gcG9wdWxhdGUgb3Ro ZXIgREVDQURFIHNlcnZlcnMgdG8gcHJvdmlkZSBhIGZsZXhpYmxlIENETg0KPj4gbGlrZSBmdW5j dGlvbmFsaXR5IGZvciB0aGUgcHVibGlzaGVkIG9iamVjdHMuDQo+Pj4+IA0KPj4+IA0KPj4+IEkg dGhpbmsgdGhpcyBjYXNlIGNhbiBiZSBoYW5kbGVkIGJ5IHRoZSBleGlzdGluZyBhcmNoaXRlY3R1 cmUuIFRoZQ0KPj4+IGNsaWVudCBjb3VsZCBnaXZlIHRoZSBlbnRpdHkgZG9pbmcgdGhlIHJlcGxp Y2F0aW9uICh0aGUgbmV0d29yaw0KPj4+IHByb3ZpZGVyIGluIHRoaXMgY2FzZSkgdG9rZW5zIHRo YXQgcHJvdmlkZSByZWFkL3dyaXRlIGFjY2VzcyB0byBpdHMNCj4+PiBkYXRhIG9iamVjdHMuDQo+ Pj4gDQo+Pj4gSWYgeW91IHdhbnRlZCB0byBzaG9ydC1jaXJjdWl0IHRoaXMgY2FzZSBieSBoYXZp bmcgdGhlIGNsaWVudCBub3QgZ2l2ZQ0KPj4+IHRoZSB0b2tlbnMgKHNpbmNlIHByZXN1bWFibHkg dGhlIG5ldHdvcmsgcHJvdmlkZXIgb3ducyB0aGUgREVDQURFDQo+Pj4gc2VydmVycyBhbmQgY291 bGQgcmVwbGljYXRlIG9iamVjdHMgdXNpbmcgc29tZSBtZWNoYW5pc20gb3RoZXIgdGhhbg0KPj4+ IERFQ0FERSksIHRoZW4gdGhhdCB3b3VsZCBiZSBmaW5lIHRvbyAtIGJ1dCB0aGF0IHNlZW1zIGEg Yml0IHRvbw0KPj4+IHNwZWNpYWxpemVkIG9mIGEgdXNlIGNhc2UgZm9yIHRoaXMgZG9jdW1lbnQu DQo+Pj4gDQo+Pj4+Pj4gNy4xIMKnNQ0KPj4+Pj4+IEl0IHN0YXRlcyAiVGhvdWdoIGV4cGxpY2l0 bHkgc3VwcGx5aW5nIHRoZXNlIG1heSBwcm92aWRlIGFkZGl0aW9uYWwNCj4+IGZyZWVkb20sDQo+ Pj4+Pj4gaXQgaXMgbm90IGNsZWFyIHdoYXQgYmVuZWZpdCB0aGV5IG1pZ2h0IHByb3ZpZGUuIg0K Pj4+Pj4+IEl0IGlzIHVuY2xlYXIgd2hhdCB0aGUgInRoZXkiIHJlZmVycyB0by4gSSBoYXZlIHBy b2JsZW1zIHVuZGVyc3RhbmRpbmcgdGhlDQo+Pj4+Pj4gbWVhbmluZyBvZiB0aGlzIHNlbnRlbmNl Lg0KPj4+Pj4gDQo+Pj4+PiAidGhleSIgcmVmZXJzIHRvIHRoZSBkYXRhIG9iamVjdCBhbmQgb3Bl cmF0aW9uIHBhcmFtZXRlcnMuICBGb3INCj4+Pj4+IGV4YW1wbGUsIGEgdHlwaWNhbCAobm9ybWFs KSB1c2UgY2FzZSBtaWdodCBiZSB0byByZXF1ZXN0IHRvIGRvd25sb2FkDQo+Pj4+PiBvYmplY3Qg MSBmcm9tIFNlcnZlciBBLCBidXQgaW5kaWNhdGluZyB0aGF0IGl0IG11c3QgZmV0Y2ggb2JqZWN0 IDENCj4+Pj4+IGZyb20gU2VydmVyIEIgZmlyc3QuICBFeHRlbmRpbmcgdGhhdCBzbGlnaHRseSwg SSBjb3VsZCBpbWFnaW5lDQo+Pj4+PiBjb25zdHJ1Y3RpbmcgcHJvdG9jb2wgbWVzc2FnZXMgdG8g cmVxdWVzdCB0byBkb3dubG9hZCBvYmplY3QgMSBmcm9tDQo+Pj4+PiBTZXJ2ZXIgQSwgYnV0IGlu ZGljYXRpbmcgaXQgbXVzdCBmZXRjaCBvYmplY3QgMiBmcm9tIFNlcnZlciBCIGZpcnN0Lg0KPj4+ Pj4gVGhlcmUgbWF5IGJlIGludGVyZXN0aW5nIHVzZSBjYXNlcyBmb3Igc29tZXRoaW5nIGxpa2Ug dGhhdCAtIHRoaXMNCj4+Pj4+IHNlbnRlbmNlIHdhcyBtZXJlbHkgdHJ5aW5nIHRvIHBvaW50IHRo aXMgb3V0Lg0KPj4+Pj4gDQo+Pj4+PiBXZSBjYW4gZHJvcCB0aGlzIHNlbnRlbmNlIGlmIGl0IGNy ZWF0ZXMgY29uZnVzaW9uLg0KPj4+PiANCj4+Pj4gUGxlYXNlIGRvLg0KPj4+PiANCj4+Pj4+IA0K Pj4+Pj4+IDcuMSBsYXN0IMKnDQo+Pj4+Pj4gSXQgc3RhdGVzICJJbiB0aGUgY2FzZSBvZiBhIEdF VCBvcGVyYXRpb24sIHRoZSBERUNBREUgc2VydmVyIGlzIHRvIHJldHJpZXZlDQo+Pj4+Pj4gdGhl IGRhdGEgb2JqZWN0IGZyb20gdGhlIHJlbW90ZSBzZXJ2ZXIgdXNpbmcgdGhlIHNwZWNpZmllZCBj cmVkZW50aWFscyAodmlhDQo+Pj4+Pj4gYSBHRVQgcmVxdWVzdCB0byB0aGUgcmVtb3RlIHNlcnZl ciksIGFuZCB0aGVuIHJldHVybiB0aGUgb2JqZWN0IHRvIHRoZQ0KPj4+Pj4+IGNsaWVudC4iDQo+ Pj4+Pj4gV2h5IHNob3VsZCB0aGUgb2JqZWN0IGJlIHJldHVybmVkIHRvIHRoZSBjbGllbnQ/IElm IHRoaXMgaXMganVzdCBhYm91dCBjYWNoZQ0KPj4+Pj4+IG1hbmFnZW1lbnQgdGhlcmUgaXMgbm8g cmVhc29uIHRvIHJldHVybiB0aGUgb2JqZWN0IHRvIHRoZSBjbGllbnQuDQo+Pj4+PiANCj4+Pj4+ IE5vIC0gaXQgaXMgbm90IG9ubHkgYWJvdXQgY2FjaGUgbWFuYWdlbWVudC4gVGhlIGNsaWVudCBt YXkgbm90IGhhdmUNCj4+Pj4+IHRoZSBvYmplY3QgeWV0LiBIb3dldmVyLCB0aGF0IHNhaWQsIEkg bWlnaHQgaW1hZ2luZSBjYXNlcyB3aGVyZSB0aGUNCj4+Pj4+IGxhc3Qgc3RlcCAoZG93bmxvYWRp bmcgdG8gdGhlIGNsaWVudCBpdHNlbGYpIGlzIG9wdGlvbmFsLCBlLmcuLCBpZiBpdA0KPj4+Pj4g d2lzaGVzIHRvIGRlbGF5IGRvd25sb2FkaW5nIGl0IG92ZXIgdGhlIGxhc3QgbWlsZSBmb3IgbGF0 ZXIuICBXZQ0KPj4+Pj4gc2hvdWxkIGFkZCBhIG5vdGUgc2F5aW5nIHRoYXQgaXQgaXMgb3B0aW9u YWwuDQo+Pj4+IA0KPj4+PiBGaW5lLg0KPj4+PiANCj4+Pj4+IA0KPj4+Pj4+IEZ1cnRoZXIgaXQg c3RhdGVzOiAiSW4gdGhlIGNhc2Ugb2YgYSBQVVQgb3BlcmF0aW9uLCB0aGUgREVDQURFIHNlcnZl ciBpcyB0bw0KPj4+Pj4+IHN0b3JlIHRoZSBvYmplY3QgZnJvbSB0aGUgY2xpZW50Li4uIiBUaGlz IHNvdW5kcyBsaWtlIHRoZSBjbGllbnQgbWFraW5nIHRoaXMNCj4+Pj4+PiBQVVQgSSB0aG91Z2h0 IHRoaXMgd2FzIGFib3V0IHNlcnZlciB0byBzZXJ2ZXIgY29tbXVuaWNhdGlvbi4NCj4+Pj4+IA0K Pj4+Pj4gWWVzIC0gdGhlIHNlcnZlci10by1zZXJ2ZXIgY29tbXVuaWNhdGlvbiBpcyBleHBsaWNp dGx5IGNvbnRyb2xsZWQgYnkgdGhlIGNsaWVudC4NCj4+Pj4+IA0KPj4+Pj4gU2ltaWxhcmx5LCB3 ZSBzaG91bGQgYWRkIGEgbm90ZSBoZXJlIHNheWluZyB0aGF0IHRoZSB1cGxvYWQgZnJvbSB0aGUN Cj4+Pj4+IGNsaWVudCB0byBpdHMgb3duIHNlcnZlciBpcyBvcHRpb25hbCAodGhlIG9iamVjdCBt YXkgYWxyZWFkeSBleGlzdCBhdA0KPj4+Pj4gb25lIHNlcnZlciwgYW5kIHRoZSBjbGllbnQgbWF5 IHdhbnQgaXQgcmVwbGljYXRlZCB0byBhbm90aGVyIHNlcnZlcikuDQo+Pj4+IA0KPj4+PiBPay4N Cj4+Pj4gDQo+Pj4+PiANCj4+Pj4+PiBBbHNvIHNob3VsZCBub3QNCj4+Pj4+PiBwb2xpY2llcyBm b3IgdGhlIG9iamVjdCwgZS5nLiB0dGwsIGJlIHN0b3JlZD8NCj4+Pj4+IA0KPj4+Pj4gWWVzLiBU aGlzIHNlY3Rpb24gc3RhdGVzICJERUNBREUgcmUtdXNlcyB0aGUgYWxyZWFkeS1zcGVjaWZpZWQN Cj4+Pj4+IHByb3RvY29scyB0byBzdXBwb3J0IG9wZXJhdGlvbnMgZGlyZWN0bHkgYmV0d2VlbiBz ZXJ2ZXJzIiwgYW5kIHRoZXNlDQo+Pj4+PiB3ZXJlIG1lbnRpb25lZCBpbiBTZWN0aW9uIDYuICBT aG91bGQgd2UgZXhwbGljaXRseSBtZW50aW9uIHRoYXQgc3VjaA0KPj4+Pj4gYXR0cmlidXRlcyBj YW4gYWxzbyBiZSBjb25maWd1cmVkIG9uIHJlcXVlc3RzIGludm9sdmluZw0KPj4+Pj4gc2VydmVy LXRvLXNlcnZlciBjb21tdW5pY2F0aW9uPw0KPj4+PiANCj4+Pj4gV291bGQgYmUgZ29vZCBmb3Ig Y2xhcml0eS4NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+PiA4LjEgZmlyc3QgwqcNCj4+Pj4+PiBJdCBz dGF0ZXMgIkEgREVDQURFIHNlcnZlciBtYXkgY2hvb3NlIHRvIG5vdCBmdWxseSBzdG9yZSBhbiBv YmplY3QNCj4+Pj4+PiBiZWZvcmUgYmVnaW5uaW5nIHRvIHNlcnZlIGl0LiIgVGhlICdtYXkgY2hv b3NlJyBpcyBub3QgY29uc2lzdGVudCB3aXRoIHRoZQ0KPj4+Pj4+IE1VU1QgcmVxdWllcm1lbnQg dG8gYmUgYWJsZSB0byBkZWxpdmVyIGJlZm9yZSBmdWxseSBzdG9yZWQuDQo+Pj4+PiANCj4+Pj4+ IEp1c3QgdG8gYmUgc3VyZSwgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhpcyBzdGF0ZW1lbnQ/DQo+ Pj4+PiANCj4+Pj4+ICJBIHNlcnZlciBNVVNUIGFjY2VwdCBkb3dubG9hZCByZXF1ZXN0cyBmb3Ig YW4gb2JqZWN0IHRoYXQgaXMgc3RpbGwNCj4+Pj4+IGJlaW5nIHVwbG9hZGVkLiINCj4+Pj4gDQo+ Pj4+IHllcy4NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFRoYXQgc2hvdWxkIGluZGVlZCBiZSBhIE1B WSB0byBiZSBjb25zaXN0ZW50IHdpdGggdGhlIHJlcXVpcmVtZW50cw0KPj4+Pj4gZHJhZnQuICBP YmplY3Rpb25zPw0KPj4+PiANCj4+Pj4gb2suDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4gDQo+ Pj4gVGhhbmtzIGFnYWluIGZvciB5b3VyIGRldGFpbGVkIHJlYWRpbmcgb2YgdGhlIGRvY3VtZW50 IQ0KPj4+IFJpY2gNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IGRlY2FkZSBtYWlsaW5nIGxpc3QNCj4+IGRlY2FkZUBpZXRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZWNhZGUNCg== From richard.alimi@gmail.com Thu Oct 20 23:04:05 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5EA1F0C63 for ; Thu, 20 Oct 2011 23:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9-3LkOGmu1s for ; Thu, 20 Oct 2011 23:04:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 793BA1F0C60 for ; Thu, 20 Oct 2011 23:04:04 -0700 (PDT) Received: by iabn5 with SMTP id n5so4797916iab.31 for ; Thu, 20 Oct 2011 23:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=DUkxiyaGycb0ml8cRk/TspkiUdyKy+dbRV680mSfOzM=; b=PXCwttS+jQm1Vr2CsSgpN6AgTTYuQ9uA0YyeXLWMP4ZCXpIdf3AxLe+/RUMqK4pXpX LbJat3cCSoRRq96UTVeT420G9Xb4AtwsznCyTAEvWvbrtWU7C3qrErFxlXygE9A175E+ JJ1O3Q2ssT6fKEKskF9mPlOptpUCPNMEYfA+E= Received: by 10.42.154.194 with SMTP id r2mr23106595icw.50.1319177044074; Thu, 20 Oct 2011 23:04:04 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.152.79 with HTTP; Thu, 20 Oct 2011 23:03:44 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> <5384B03A-1403-473B-AB94-AEAE58D76427@ericsson.com> From: Richard Alimi Date: Thu, 20 Oct 2011 23:03:44 -0700 X-Google-Sender-Auth: C_Vog6yoja_2Enz4Ey6c9PH41x8 Message-ID: To: Songhaibin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 06:04:05 -0000 On Thu, Oct 20, 2011 at 8:07 PM, Songhaibin wrote: > Hi, > >>>>> 8.1 first =A7 >>>>> It states "A DECADE server may choose to not fully store an object >>>>> before beginning to serve it." The 'may choose' is not consistent >>>>> with the MUST requierment to be able to deliver before fully stored. >>>> >>>> Just to be sure, you are referring to this statement? >>>> >>>> =A0"A server MUST accept download requests for an object that is still >>>> being uploaded." >>> >>> yes. >>> >>>> >>>> That should indeed be a MAY to be consistent with the requirements >>>> draft. =A0Objections? > > > Shall we say the server "MUST" have the ability to serve the objects that= is being uploaded, while the server "MAY" choose to do it? > >From the standpoint of a DECADE client, is there value in distinguishing between these two cases? (1) a server is able, but not configured to to serve an object that is being uploaded (2) a server is not able to serve an object that is being uploaded Thanks, Rich > BR, > -Haibin > > >> -----Original Message----- >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf= Of >> B?rje Ohlman >> Sent: Wednesday, October 19, 2011 1:29 AM >> To: Richard Alimi >> Cc: decade ietf >> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 >> >> For me your proposals are fine. No more comments. >> >> =A0 =A0 =A0 B=F6rje >> >> On 18 okt 2011, at 18.14, Richard Alimi wrote: >> >> > On Tue, Oct 18, 2011 at 9:02 AM, B=F6rje Ohlman >> wrote: >> >> Comments inline... >> >> >> >> On 18 okt 2011, at 08.51, Richard Alimi wrote: >> >> >> >>> Hi B=F6rje, >> >>> >> >>> Thank you very much for the review. =A0Responses inline... >> >>> >> >>> On Mon, Oct 17, 2011 at 8:02 AM, B=F6rje Ohlman >> wrote: >> >>>> >> >>>> The previous comment that I do not see as addressed is how overbook= ing >> of >> >>>> resources should be dealt with in DECADE. This is probably to large= extent >> >>>> an SLA issue, but I think it would raise the issue in this draft. I= n my >> >>>> review of the previous draft I wrote: >> >>>> >> >>>> Is it allowed for decade service providers to oversell the resource= s of >> >>>> their servers (both bandwidth and storage), similar to airline over= booking? >> >>>> I think overbooking should be allowed to maximize resource utilizat= ion. >> >>>> Especially regarding bandwidth I think it is unavoidable. It would = be good >> >>>> if this was addressed in the draft, e.g. in 4.2. >> >>> >> >>> My personal feeling is that this is a question of policy and not a >> >>> question for the protocol or architecture. =A0Do you think that leav= ing >> >>> it out of scope will cause issues in the design or eventual protocol >> >>> specification? =A0I could see policy, algorithms, and deployments >> >>> changing based on whether oversubscription is used, but what do you >> >>> think the protocol ramifications might be? =A0Presumably we will nee= d >> >>> the architecture/protocol to have all the nice features of any >> >>> protocol such as overload handling anyways (those are already in the >> >>> requirements). >> >> >> >> Ok, fine. >> >> >> >>> >> >>>> 6.2.1 =A71 >> >>>> In the first =A7 it is unclear if the client or the server is namin= g the >> >>>> object. If both alternatives are allowed this should be stated expl= icitly >> >>>> and it should be added a comment to the parameter NAME that it can = be >> >>>> empty. >> >>>> Then in =A74 it is stated "The application that originates the obje= cts MUST >> >>>> generate DECADE object names according to the naming specification = in >> >>>> Section 5.3." Is it sure that we want this? Sensors might want the = server to >> >>>> generate the names. >> >>> >> >>> The original intent was for the name to be sent by the client, and >> >>> then validated by the server. That said, I have only two reservation= s >> >>> about having the server compute the name (if the client does not wan= t >> >>> to): >> >>> (1) the server is forced to compute the hash which may be expensive. >> >>> I might imagine certain cases where servers disable this (knowing th= e >> >>> risks of not validating the hashes), in which case a request from su= ch >> >>> a client would be rejected. =A0I don't think this would be common, >> >>> though. >> >>> (2) the client must trust the server if this is done (otherwise the >> >>> server can insert, remove, or completely fabricate the content and l= ie >> >>> about the name). >> >>> >> >>> Therefore, I don't have a problem as long as the security >> >>> consideration is made completely clear. >> >>> >> >>> Thoughts? >> >> >> >> I think both clients and servers =A0should be allowed to create name = it is not up >> to the architecture to decide on what is appropriate in specific network >> environments. >> > >> > That's fine - but the security properties are different and need to be >> > called out explicitly. =A0Objections from others about allowing the >> > server to compute the name? >> > >> >> >> >>> >> >>>> 6.2.1 last =A7 >> >>>> It states "Specifics regarding error handling, including additional >> >>>> error conditions, precedence for returned errors and its relation w= ith >> >>>> server policy, are deferred to eventual protocol specification." Sh= ould not >> >>>> lack of resources be mentioned here as well as it is an obvious iss= ue. This >> >>>> would be a possible place to add a comment on the issue with >> overbookings. >> >>> >> >>> Would additionally mentioning "overload conditions" (as it is worded >> >>> in the requirements draft) suffice? >> >> >> >> Fine. >> >> >> >>> >> >>>> 7 =A72 >> >>>> It states "All data operations are performed on behalf of DECADE cl= ients via >> >>>> explicit instruction, ..." >> >>>> It is unclear from this text if the client has to be using the DECA= DE >> >>>> Protocol to perform this action or if an management or application = protocol >> >>>> can be used to instruct the remote server. >> >>> >> >>> The intent was not to disallow access by administrative/management >> >>> protocols. =A0Would dropping the word "all" from the beginning of th= e >> >>> sentence help to clarify this? >> >> >> >> I think I should have included some more of the draft text here: >> >> "All data operations are performed on behalf of DECADE clients >> >> via explicit instruction, so additional capabilities are needed in >> >> the DECADE client-server protocols DECADE clients must be able to >> >> indicate to a DECADE server the following additional parameters:" >> > >> > Well, there is a missing period in there. =A0Noted :) >> > >> >> >> >> I think it is the formulation " additional capabilities are needed in >> >> the DECADE client-server protocols" that is causing the problem by ex= plicitly >> mentioning the DECADE protocols, a more neutral formulation not mentioni= ng >> specific protocols I think would help. >> >> >> > >> > We could certainly drop the phrase "additional capabilities are needed >> > in the DECADE client-server protocols", but I think it would be >> > understood that we are only talking about DECADE (since thats what the >> > document is about, and the protocol that would eventually be defined). >> > Right? >> > >> >>> >> >>>> Should it not also be allowed for >> >>>> the client to delegate these operations to e.g. a cache managment >> >>>> application? >> >>> >> >>> Can you clarify the use case? =A0Who owns/manages the cache manageme= nt >> >>> application? =A0Is it the same person as the DECADE server? =A0Is it= the >> >>> same person as the DECADE client? >> >> >> >> One example would be a customer of network (and DECADE server) provid= er >> that just want to put data objects in it's 'local' DECADE storage and th= en want the >> network provider to populate other DECADE servers to provide a flexible = CDN >> like functionality for the published objects. >> >> >> > >> > I think this case can be handled by the existing architecture. The >> > client could give the entity doing the replication (the network >> > provider in this case) tokens that provide read/write access to its >> > data objects. >> > >> > If you wanted to short-circuit this case by having the client not give >> > the tokens (since presumably the network provider owns the DECADE >> > servers and could replicate objects using some mechanism other than >> > DECADE), then that would be fine too - but that seems a bit too >> > specialized of a use case for this document. >> > >> >>>> 7.1 =A75 >> >>>> It states "Though explicitly supplying these may provide additional >> freedom, >> >>>> it is not clear what benefit they might provide." >> >>>> It is unclear what the "they" refers to. I have problems understand= ing the >> >>>> meaning of this sentence. >> >>> >> >>> "they" refers to the data object and operation parameters. =A0For >> >>> example, a typical (normal) use case might be to request to download >> >>> object 1 from Server A, but indicating that it must fetch object 1 >> >>> from Server B first. =A0Extending that slightly, I could imagine >> >>> constructing protocol messages to request to download object 1 from >> >>> Server A, but indicating it must fetch object 2 from Server B first. >> >>> There may be interesting use cases for something like that - this >> >>> sentence was merely trying to point this out. >> >>> >> >>> We can drop this sentence if it creates confusion. >> >> >> >> Please do. >> >> >> >>> >> >>>> 7.1 last =A7 >> >>>> It states "In the case of a GET operation, the DECADE server is to = retrieve >> >>>> the data object from the remote server using the specified credenti= als (via >> >>>> a GET request to the remote server), and then return the object to = the >> >>>> client." >> >>>> Why should the object be returned to the client? If this is just ab= out cache >> >>>> management there is no reason to return the object to the client. >> >>> >> >>> No - it is not only about cache management. The client may not have >> >>> the object yet. However, that said, I might imagine cases where the >> >>> last step (downloading to the client itself) is optional, e.g., if i= t >> >>> wishes to delay downloading it over the last mile for later. =A0We >> >>> should add a note saying that it is optional. >> >> >> >> Fine. >> >> >> >>> >> >>>> Further it states: "In the case of a PUT operation, the DECADE serv= er is to >> >>>> store the object from the client..." This sounds like the client ma= king this >> >>>> PUT I thought this was about server to server communication. >> >>> >> >>> Yes - the server-to-server communication is explicitly controlled by= the client. >> >>> >> >>> Similarly, we should add a note here saying that the upload from the >> >>> client to its own server is optional (the object may already exist a= t >> >>> one server, and the client may want it replicated to another server)= . >> >> >> >> Ok. >> >> >> >>> >> >>>> Also should not >> >>>> policies for the object, e.g. ttl, be stored? >> >>> >> >>> Yes. This section states "DECADE re-uses the already-specified >> >>> protocols to support operations directly between servers", and these >> >>> were mentioned in Section 6. =A0Should we explicitly mention that su= ch >> >>> attributes can also be configured on requests involving >> >>> server-to-server communication? >> >> >> >> Would be good for clarity. >> >> >> >>> >> >>>> 8.1 first =A7 >> >>>> It states "A DECADE server may choose to not fully store an object >> >>>> before beginning to serve it." The 'may choose' is not consistent w= ith the >> >>>> MUST requierment to be able to deliver before fully stored. >> >>> >> >>> Just to be sure, you are referring to this statement? >> >>> >> >>> =A0"A server MUST accept download requests for an object that is sti= ll >> >>> being uploaded." >> >> >> >> yes. >> >> >> >>> >> >>> That should indeed be a MAY to be consistent with the requirements >> >>> draft. =A0Objections? >> >> >> >> ok. >> >> >> >> >> >> >> > >> > Thanks again for your detailed reading of the document! >> > Rich >> >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade > From richard.alimi@gmail.com Thu Oct 20 23:52:09 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBC01F0C60 for ; Thu, 20 Oct 2011 23:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6VQVV4zsq9G for ; Thu, 20 Oct 2011 23:52:08 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72F611F0C59 for ; Thu, 20 Oct 2011 23:52:08 -0700 (PDT) Received: by iabn5 with SMTP id n5so4849290iab.31 for ; Thu, 20 Oct 2011 23:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=CB6gVxyHivw7Y4KMWTRLypBVBmY3m8ZDjW0oMCWNgxI=; b=s/cQCpfL0GHMmzabRAcn5/bxKGG0SYYz2fMi3OuIz3YtWks+i4YpcIwBPQ3eeoL9us HqtVCTAZYpjunwQYQs8jzGDV0GsimZuQJX1SIwtcENxE3xGcRLU8D5AEA1i3ajlcDMaj /stiFlkEqvVrvi81SnnM2gIKcJu1Jw3m7CpQc= Received: by 10.42.135.69 with SMTP id o5mr23277233ict.34.1319179928159; Thu, 20 Oct 2011 23:52:08 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.152.79 with HTTP; Thu, 20 Oct 2011 23:51:48 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> From: Richard Alimi Date: Thu, 20 Oct 2011 23:51:48 -0700 X-Google-Sender-Auth: 21IS_MFBkQv6KiBga5HJp2RBW-M Message-ID: To: Songhaibin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 06:52:09 -0000 On Fri, Sep 30, 2011 at 1:47 AM, Songhaibin wrote: > > > Thanks to the authors for the hard work to give this update. This documen= t > is in good shape. I only have a few comments. > > > > Section 3, Paragraph 2, last sentence, =93=85to be defined within the DEC= ADE > Working Group.=94 > > > > Comment: Please note that a working group is not a long term body. But th= is > document will last. So please do not refer to a working group in the > document. > Good point - we will remove this reference. > > > Section 4.2.1 Paragraph 1, =93DECADE MUST allow clients to specify at lea= st > two classes of services for service: lowest possible latency and latency > non-critical.=94 > > > > Comment: May need to change =93two classes of services for service=94 to = another > description, =A0this sentence seems a little awkward with =93services/ser= vice=94. > Good catch. I think we can just remove the "for service". > > > > > Section 6.1.1 Paragraph 2,=A0 last sentence, =93it may still read/write d= ata a > DECADE Server if authorized by another DECADE Client.=94 > > > > Comment: Need =93from/to=94 before =93a DECADE Server if=85=94. > Yes - noted. Thanks! Rich > > > BR, > > -Haibin > > > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Thursday, September 29, 2011 8:13 PM > To: decade@ietf.org > Cc: Songhaibin; Woundy, Richard > Subject: Start of WGLC for draft-ietf-decade-reqs-04 > > > > Folks, > > > > Haibin and I are starting the working group last call for > draft-ietf-decade-reqs-04, > http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed = by > Monday October 17. Please send all concerns, suggestions and comments abo= ut > this internet-draft to the DECADE mailing list, decade@ietf.org. > > > > Authors, please do not make any additional changes to the internet-draft > unless directed by the WG chairs. > > > > Draft reviewers, it would be helpful to get your confirmation that your > previous review comments have been correctly reflected in this version. > > > > Thanks. > > > > -- Rich and Haibin > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > > From Dirk.Kutscher@neclab.eu Fri Oct 21 08:10:39 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB2E1F0C62 for ; Fri, 21 Oct 2011 08:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyYSl+5evXTB for ; Fri, 21 Oct 2011 08:10:38 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 64CF11F0C67 for ; Fri, 21 Oct 2011 08:10:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C991B28000084; Fri, 21 Oct 2011 17:10:28 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEPouOS+AxFP; Fri, 21 Oct 2011 17:10:28 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id AD26728000080; Fri, 21 Oct 2011 17:10:13 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.12]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 21 Oct 2011 17:09:52 +0200 From: Dirk Kutscher To: Richard Alimi , =?iso-8859-1?Q?B=F6rje_Ohlman?= Thread-Topic: [decade] Start of WGLC for draft-ietf-decade-arch-03 Thread-Index: AQHMfqFcFoaXpHDqDUq1z+uA4+nCYZWAnNkAgAEJHYCAAJnZgIAAA40AgAS8FJA= Date: Fri, 21 Oct 2011 15:09:51 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52491D632BCD@DAPHNIS.office.hd> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.208] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:10:39 -0000 Hi, On this comment: > >>> 6.2.1 =A71 > >>> In the first =A7 it is unclear if the client or the server is naming > >>> the object. If both alternatives are allowed this should be stated > >>> explicitly and it should be added a comment to the parameter NAME > >>> that it can be empty. > >>> Then in =A74 it is stated "The application that originates the object= s > >>> MUST generate DECADE object names according to the naming > >>> specification in Section 5.3." Is it sure that we want this? Sensors > >>> might want the server to generate the names. > >> > >> The original intent was for the name to be sent by the client, and > >> then validated by the server. That said, I have only two reservations > >> about having the server compute the name (if the client does not want > >> to): > >> (1) the server is forced to compute the hash which may be expensive. > >> I might imagine certain cases where servers disable this (knowing the > >> risks of not validating the hashes), in which case a request from > >> such a client would be rejected. =A0I don't think this would be common= , > >> though. > >> (2) the client must trust the server if this is done (otherwise the > >> server can insert, remove, or completely fabricate the content and > >> lie about the name). > >> > >> Therefore, I don't have a problem as long as the security > >> consideration is made completely clear. > >> > >> Thoughts? > > > > I think both clients and servers =A0should be allowed to create name it= is not > up to the architecture to decide on what is appropriate in specific netwo= rk > environments. >=20 > That's fine - but the security properties are different and need to be ca= lled > out explicitly. Objections from others about allowing the server to comp= ute > the name? IMO, in DECADE, we should leave it to the client only, otherwise the fundam= ental use case (application endpoint uploads named object, refers other end= points to the objects using the name and authorization tokens) is not guara= nteed to work in all cases. For example, what if the server uses a hash algorithm that is not useful in= an application context? What about compromised servers that give you a nam= e that is not bound to the object etc? I would prefer a clear separation of concerns: application endpoint create = and name objects, DECADE servers distribute and host named objects. Best regards, Dirk From Dirk.Kutscher@neclab.eu Fri Oct 21 08:11:01 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F42621F84B4 for ; Fri, 21 Oct 2011 08:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8q-W728muMj for ; Fri, 21 Oct 2011 08:11:00 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 66B8021F84B7 for ; Fri, 21 Oct 2011 08:10:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C295C28000084; Fri, 21 Oct 2011 17:10:57 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxwprzRRtica; Fri, 21 Oct 2011 17:10:57 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id A2E5D28000083; Fri, 21 Oct 2011 17:10:42 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.12]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 21 Oct 2011 17:09:48 +0200 From: Dirk Kutscher To: Richard Alimi , Songhaibin Thread-Topic: [decade] Start of WGLC for draft-ietf-decade-arch-03 Thread-Index: AQHMfqFcFoaXpHDqDUq1z+uA4+nCYZWAnNkAgAEJHYCAAJnZgIAAA40AgAAUqoCAA8Z2gIAAMRoAgACs4uA= Date: Fri, 21 Oct 2011 15:09:48 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52491D632BC0@DAPHNIS.office.hd> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> <5384B03A-1403-473B-AB94-AEAE58D76427@ericsson.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.208] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:11:01 -0000 Hi all, First of all, thanks a lot, B=F6rje, for the helpful review -- and thanks, = Rich, for addressing the recent comments. Let me comment on just this specific issue for now: > > Shall we say the server "MUST" have the ability to serve the objects th= at is > being uploaded, while the server "MAY" choose to do it? > > >=20 > From the standpoint of a DECADE client, is there value in distinguishing > between these two cases? > (1) a server is able, but not configured to to serve an object that is be= ing > uploaded > (2) a server is not able to serve an object that is being uploaded Yes, right -- there is no way for the client to negotiate this with or requ= est this from the server, so just requiring the capability will not help. I'd say this could really be an implementation-specific decision. Some serv= ers might be able to do it, others not. If you want to provide DECADE for d= ownload-based services only, you would not really need it. So, "the server MAY...". Best regards, Dirk >=20 > Thanks, > Rich >=20 > > BR, > > -Haibin > > > > > >> -----Original Message----- > >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > >> Behalf Of B?rje Ohlman > >> Sent: Wednesday, October 19, 2011 1:29 AM > >> To: Richard Alimi > >> Cc: decade ietf > >> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 > >> > >> For me your proposals are fine. No more comments. > >> > >> =A0 =A0 =A0 B=F6rje > >> > >> On 18 okt 2011, at 18.14, Richard Alimi wrote: > >> > >> > On Tue, Oct 18, 2011 at 9:02 AM, B=F6rje Ohlman > >> > > >> wrote: > >> >> Comments inline... > >> >> > >> >> On 18 okt 2011, at 08.51, Richard Alimi wrote: > >> >> > >> >>> Hi B=F6rje, > >> >>> > >> >>> Thank you very much for the review. =A0Responses inline... > >> >>> > >> >>> On Mon, Oct 17, 2011 at 8:02 AM, B=F6rje Ohlman > >> wrote: > >> >>>> > >> >>>> The previous comment that I do not see as addressed is how > >> >>>> overbooking > >> of > >> >>>> resources should be dealt with in DECADE. This is probably to > >> >>>> large extent an SLA issue, but I think it would raise the issue > >> >>>> in this draft. In my review of the previous draft I wrote: > >> >>>> > >> >>>> Is it allowed for decade service providers to oversell the > >> >>>> resources of their servers (both bandwidth and storage), similar = to > airline overbooking? > >> >>>> I think overbooking should be allowed to maximize resource > utilization. > >> >>>> Especially regarding bandwidth I think it is unavoidable. It > >> >>>> would be good if this was addressed in the draft, e.g. in 4.2. > >> >>> > >> >>> My personal feeling is that this is a question of policy and not > >> >>> a question for the protocol or architecture. =A0Do you think that > >> >>> leaving it out of scope will cause issues in the design or > >> >>> eventual protocol specification? =A0I could see policy, algorithms= , > >> >>> and deployments changing based on whether oversubscription is > >> >>> used, but what do you think the protocol ramifications might be? > >> >>> Presumably we will need the architecture/protocol to have all the > >> >>> nice features of any protocol such as overload handling anyways > >> >>> (those are already in the requirements). > >> >> > >> >> Ok, fine. > >> >> > >> >>> > >> >>>> 6.2.1 =A71 > >> >>>> In the first =A7 it is unclear if the client or the server is > >> >>>> naming the object. If both alternatives are allowed this should > >> >>>> be stated explicitly and it should be added a comment to the > >> >>>> parameter NAME that it can be empty. > >> >>>> Then in =A74 it is stated "The application that originates the > >> >>>> objects MUST generate DECADE object names according to the > >> >>>> naming specification in Section 5.3." Is it sure that we want > >> >>>> this? Sensors might want the server to generate the names. > >> >>> > >> >>> The original intent was for the name to be sent by the client, > >> >>> and then validated by the server. That said, I have only two > >> >>> reservations about having the server compute the name (if the > >> >>> client does not want > >> >>> to): > >> >>> (1) the server is forced to compute the hash which may be > expensive. > >> >>> I might imagine certain cases where servers disable this (knowing > >> >>> the risks of not validating the hashes), in which case a request > >> >>> from such a client would be rejected. =A0I don't think this would > >> >>> be common, though. > >> >>> (2) the client must trust the server if this is done (otherwise > >> >>> the server can insert, remove, or completely fabricate the > >> >>> content and lie about the name). > >> >>> > >> >>> Therefore, I don't have a problem as long as the security > >> >>> consideration is made completely clear. > >> >>> > >> >>> Thoughts? > >> >> > >> >> I think both clients and servers =A0should be allowed to create nam= e > >> >> it is not up > >> to the architecture to decide on what is appropriate in specific > >> network environments. > >> > > >> > That's fine - but the security properties are different and need to > >> > be called out explicitly. =A0Objections from others about allowing > >> > the server to compute the name? > >> > > >> >> > >> >>> > >> >>>> 6.2.1 last =A7 > >> >>>> It states "Specifics regarding error handling, including > >> >>>> additional error conditions, precedence for returned errors and > >> >>>> its relation with server policy, are deferred to eventual > >> >>>> protocol specification." Should not lack of resources be > >> >>>> mentioned here as well as it is an obvious issue. This would be > >> >>>> a possible place to add a comment on the issue with > >> overbookings. > >> >>> > >> >>> Would additionally mentioning "overload conditions" (as it is > >> >>> worded in the requirements draft) suffice? > >> >> > >> >> Fine. > >> >> > >> >>> > >> >>>> 7 =A72 > >> >>>> It states "All data operations are performed on behalf of DECADE > >> >>>> clients via explicit instruction, ..." > >> >>>> It is unclear from this text if the client has to be using the > >> >>>> DECADE Protocol to perform this action or if an management or > >> >>>> application protocol can be used to instruct the remote server. > >> >>> > >> >>> The intent was not to disallow access by > >> >>> administrative/management protocols. =A0Would dropping the word > >> >>> "all" from the beginning of the sentence help to clarify this? > >> >> > >> >> I think I should have included some more of the draft text here: > >> >> "All data operations are performed on behalf of DECADE clients via > >> >> explicit instruction, so additional capabilities are needed in the > >> >> DECADE client-server protocols DECADE clients must be able to > >> >> indicate to a DECADE server the following additional parameters:" > >> > > >> > Well, there is a missing period in there. =A0Noted :) > >> > > >> >> > >> >> I think it is the formulation " additional capabilities are needed > >> >> in the DECADE client-server protocols" that is causing the problem > >> >> by explicitly > >> mentioning the DECADE protocols, a more neutral formulation not > >> mentioning specific protocols I think would help. > >> >> > >> > > >> > We could certainly drop the phrase "additional capabilities are > >> > needed in the DECADE client-server protocols", but I think it would > >> > be understood that we are only talking about DECADE (since thats > >> > what the document is about, and the protocol that would eventually b= e > defined). > >> > Right? > >> > > >> >>> > >> >>>> Should it not also be allowed for the client to delegate these > >> >>>> operations to e.g. a cache managment application? > >> >>> > >> >>> Can you clarify the use case? =A0Who owns/manages the cache > >> >>> management application? =A0Is it the same person as the DECADE > >> >>> server? =A0Is it the same person as the DECADE client? > >> >> > >> >> One example would be a customer of network (and DECADE server) > >> >> provider > >> that just want to put data objects in it's 'local' DECADE storage and > >> then want the network provider to populate other DECADE servers to > >> provide a flexible CDN like functionality for the published objects. > >> >> > >> > > >> > I think this case can be handled by the existing architecture. The > >> > client could give the entity doing the replication (the network > >> > provider in this case) tokens that provide read/write access to its > >> > data objects. > >> > > >> > If you wanted to short-circuit this case by having the client not > >> > give the tokens (since presumably the network provider owns the > >> > DECADE servers and could replicate objects using some mechanism > >> > other than DECADE), then that would be fine too - but that seems a > >> > bit too specialized of a use case for this document. > >> > > >> >>>> 7.1 =A75 > >> >>>> It states "Though explicitly supplying these may provide > >> >>>> additional > >> freedom, > >> >>>> it is not clear what benefit they might provide." > >> >>>> It is unclear what the "they" refers to. I have problems > >> >>>> understanding the meaning of this sentence. > >> >>> > >> >>> "they" refers to the data object and operation parameters. =A0For > >> >>> example, a typical (normal) use case might be to request to > >> >>> download object 1 from Server A, but indicating that it must > >> >>> fetch object 1 from Server B first. =A0Extending that slightly, I > >> >>> could imagine constructing protocol messages to request to > >> >>> download object 1 from Server A, but indicating it must fetch obje= ct 2 > from Server B first. > >> >>> There may be interesting use cases for something like that - this > >> >>> sentence was merely trying to point this out. > >> >>> > >> >>> We can drop this sentence if it creates confusion. > >> >> > >> >> Please do. > >> >> > >> >>> > >> >>>> 7.1 last =A7 > >> >>>> It states "In the case of a GET operation, the DECADE server is > >> >>>> to retrieve the data object from the remote server using the > >> >>>> specified credentials (via a GET request to the remote server), > >> >>>> and then return the object to the client." > >> >>>> Why should the object be returned to the client? If this is just > >> >>>> about cache management there is no reason to return the object to > the client. > >> >>> > >> >>> No - it is not only about cache management. The client may not > >> >>> have the object yet. However, that said, I might imagine cases > >> >>> where the last step (downloading to the client itself) is > >> >>> optional, e.g., if it wishes to delay downloading it over the > >> >>> last mile for later. =A0We should add a note saying that it is opt= ional. > >> >> > >> >> Fine. > >> >> > >> >>> > >> >>>> Further it states: "In the case of a PUT operation, the DECADE > >> >>>> server is to store the object from the client..." This sounds > >> >>>> like the client making this PUT I thought this was about server t= o > server communication. > >> >>> > >> >>> Yes - the server-to-server communication is explicitly controlled = by > the client. > >> >>> > >> >>> Similarly, we should add a note here saying that the upload from > >> >>> the client to its own server is optional (the object may already > >> >>> exist at one server, and the client may want it replicated to anot= her > server). > >> >> > >> >> Ok. > >> >> > >> >>> > >> >>>> Also should not > >> >>>> policies for the object, e.g. ttl, be stored? > >> >>> > >> >>> Yes. This section states "DECADE re-uses the already-specified > >> >>> protocols to support operations directly between servers", and > >> >>> these were mentioned in Section 6. =A0Should we explicitly mention > >> >>> that such attributes can also be configured on requests involving > >> >>> server-to-server communication? > >> >> > >> >> Would be good for clarity. > >> >> > >> >>> > >> >>>> 8.1 first =A7 > >> >>>> It states "A DECADE server may choose to not fully store an > >> >>>> object before beginning to serve it." The 'may choose' is not > >> >>>> consistent with the MUST requierment to be able to deliver before > fully stored. > >> >>> > >> >>> Just to be sure, you are referring to this statement? > >> >>> > >> >>> =A0"A server MUST accept download requests for an object that is > >> >>> still being uploaded." > >> >> > >> >> yes. > >> >> > >> >>> > >> >>> That should indeed be a MAY to be consistent with the > >> >>> requirements draft. =A0Objections? > >> >> > >> >> ok. > >> >> > >> >> > >> >> > >> > > >> > Thanks again for your detailed reading of the document! > >> > Rich > >> > >> _______________________________________________ > >> 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 Oct 21 08:26:12 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4659121F84A2 for ; Fri, 21 Oct 2011 08:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTStZm88uMtb for ; Fri, 21 Oct 2011 08:26:11 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2CB21F8490 for ; Fri, 21 Oct 2011 08:26:11 -0700 (PDT) Received: by iabn5 with SMTP id n5so5386345iab.31 for ; Fri, 21 Oct 2011 08:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=WWuCFfxiiTmqpHxjSMFptxo1QRUc6RdZUPJrI9BaJSI=; b=YBYvm/y7CbrShhYQTL0otHYpOZKFv41fVTfyJCn0tSmTC1JtotwvleuHLjxjB4WoCf QL6BI/aAuhXdo/EqdxdeFMZdkhOvusCRAlgtMQto8I/+oUc9ioExAEYM2dI2tKA3zOYN 5o5r819aR0EP3KIzy3B3FkRV/yHS5SPyIueNE= Received: by 10.231.45.135 with SMTP id e7mr6047338ibf.12.1319210770162; Fri, 21 Oct 2011 08:26:10 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.152.79 with HTTP; Fri, 21 Oct 2011 08:25:50 -0700 (PDT) In-Reply-To: <82AB329A76E2484D934BBCA77E9F52491D632BCD@DAPHNIS.office.hd> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> <82AB329A76E2484D934BBCA77E9F52491D632BCD@DAPHNIS.office.hd> From: Richard Alimi Date: Fri, 21 Oct 2011 08:25:50 -0700 X-Google-Sender-Auth: k6vWqcabESyc8gnw6NGkQ6OnqS0 Message-ID: To: Dirk Kutscher Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:26:12 -0000 On Fri, Oct 21, 2011 at 8:09 AM, Dirk Kutscher wr= ote: > Hi, > > On this comment: > >> >>> 6.2.1 =A71 >> >>> In the first =A7 it is unclear if the client or the server is naming >> >>> the object. If both alternatives are allowed this should be stated >> >>> explicitly and it should be added a comment to the parameter NAME >> >>> that it can be empty. >> >>> Then in =A74 it is stated "The application that originates the objec= ts >> >>> MUST generate DECADE object names according to the naming >> >>> specification in Section 5.3." Is it sure that we want this? Sensors >> >>> might want the server to generate the names. >> >> >> >> The original intent was for the name to be sent by the client, and >> >> then validated by the server. That said, I have only two reservations >> >> about having the server compute the name (if the client does not want >> >> to): >> >> (1) the server is forced to compute the hash which may be expensive. >> >> I might imagine certain cases where servers disable this (knowing the >> >> risks of not validating the hashes), in which case a request from >> >> such a client would be rejected. =A0I don't think this would be commo= n, >> >> though. >> >> (2) the client must trust the server if this is done (otherwise the >> >> server can insert, remove, or completely fabricate the content and >> >> lie about the name). >> >> >> >> Therefore, I don't have a problem as long as the security >> >> consideration is made completely clear. >> >> >> >> Thoughts? >> > >> > I think both clients and servers =A0should be allowed to create name i= t is not >> up to the architecture to decide on what is appropriate in specific netw= ork >> environments. >> >> That's fine - but the security properties are different and need to be c= alled >> out explicitly. =A0Objections from others about allowing the server to c= ompute >> the name? > > IMO, in DECADE, we should leave it to the client only, otherwise the fund= amental use case (application endpoint uploads named object, refers other e= ndpoints to the objects using the name and authorization tokens) is not gua= ranteed to work in all cases. > The way I read his suggestion was that there is the option of the server generating the name. Put another way, the client still has capability to generate the name (and the server may verify), but the client could also be lazy and accept the security consequences. I completely agree that we don't want to require the server to generate the name. > For example, what if the server uses a hash algorithm that is not useful = in an application context? What about compromised servers that give you a n= ame that is not bound to the object etc? > I agree with your concerns, and those are the ones that would need to be called out if we were to add something for this. > I would prefer a clear separation of concerns: application endpoint creat= e and name objects, DECADE servers distribute and host named objects. > That is a good point. Maybe one possibility is to have the base protocol without this capability, and then have an extension to handle clients that for some-reason can't or don't want to compute a hash? Rich > Best regards, > > Dirk > > > > > > > > > > From Akbar.Rahman@InterDigital.com Fri Oct 21 11:42:52 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0373F21F8B49 for ; Fri, 21 Oct 2011 11:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jym2dt4b7d8X for ; Fri, 21 Oct 2011 11:42:51 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 363BD21F8B4B for ; Fri, 21 Oct 2011 11:42:51 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 14:42:50 -0400 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, 21 Oct 2011 14:42:49 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Start of WGLC for draft-ietf-decade-arch-03 Thread-index: AcyQBc14Xgj5Oc6HRCqQqaBxRGwp6AAGv/RQ References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com><1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com><1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com><6556C646-A675-4E23-A965-C087398371D3@ericsson.com><57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com><82AB329A76E2484D934BBCA77E9F52491D632BCD@DAPHNIS.office.hd> From: "Rahman, Akbar" To: "Richard Alimi" X-OriginalArrivalTime: 21 Oct 2011 18:42:50.0081 (UTC) FILETIME=[3BF00D10:01CC9021] Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 18:42:52 -0000 Hi Rich, The one other point to consider is that in Fig. 1 and in the text we = allow DECADE protocols (DRP/SDT) to run between servers only (without = any clients involved). So in that case do we still want to prohibit the = server from performing the naming? Akbar -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of Richard Alimi Sent: Friday, October 21, 2011 11:26 AM To: Dirk Kutscher Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 On Fri, Oct 21, 2011 at 8:09 AM, Dirk Kutscher = wrote: > Hi, > > On this comment: > >> >>> 6.2.1 =A71 >> >>> In the first =A7 it is unclear if the client or the server is = naming >> >>> the object. If both alternatives are allowed this should be = stated >> >>> explicitly and it should be added a comment to the parameter NAME >> >>> that it can be empty. >> >>> Then in =A74 it is stated "The application that originates the = objects >> >>> MUST generate DECADE object names according to the naming >> >>> specification in Section 5.3." Is it sure that we want this? = Sensors >> >>> might want the server to generate the names. >> >> >> >> The original intent was for the name to be sent by the client, and >> >> then validated by the server. That said, I have only two = reservations >> >> about having the server compute the name (if the client does not = want >> >> to): >> >> (1) the server is forced to compute the hash which may be = expensive. >> >> I might imagine certain cases where servers disable this (knowing = the >> >> risks of not validating the hashes), in which case a request from >> >> such a client would be rejected. =A0I don't think this would be = common, >> >> though. >> >> (2) the client must trust the server if this is done (otherwise = the >> >> server can insert, remove, or completely fabricate the content and >> >> lie about the name). >> >> >> >> Therefore, I don't have a problem as long as the security >> >> consideration is made completely clear. >> >> >> >> Thoughts? >> > >> > I think both clients and servers =A0should be allowed to create = name it is not >> up to the architecture to decide on what is appropriate in specific = network >> environments. >> >> That's fine - but the security properties are different and need to = be called >> out explicitly. =A0Objections from others about allowing the server = to compute >> the name? > > IMO, in DECADE, we should leave it to the client only, otherwise the = fundamental use case (application endpoint uploads named object, refers = other endpoints to the objects using the name and authorization tokens) = is not guaranteed to work in all cases. > The way I read his suggestion was that there is the option of the server generating the name. Put another way, the client still has capability to generate the name (and the server may verify), but the client could also be lazy and accept the security consequences. I completely agree that we don't want to require the server to generate the name. > For example, what if the server uses a hash algorithm that is not = useful in an application context? What about compromised servers that = give you a name that is not bound to the object etc? > I agree with your concerns, and those are the ones that would need to be called out if we were to add something for this. > I would prefer a clear separation of concerns: application endpoint = create and name objects, DECADE servers distribute and host named = objects. > That is a good point. Maybe one possibility is to have the base protocol without this capability, and then have an extension to handle clients that for some-reason can't or don't want to compute a hash? Rich > Best regards, > > Dirk > > > > > > > > > > _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From richard.alimi@gmail.com Fri Oct 21 13:30:00 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803221F0C4B for ; Fri, 21 Oct 2011 13:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55dr7QCqPjZu for ; Fri, 21 Oct 2011 13:29:59 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7D191F0C35 for ; Fri, 21 Oct 2011 13:29:59 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4413244vcb.31 for ; Fri, 21 Oct 2011 13:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=mRS1CzOgNTPCYeBKOO4R0PEeWMKOqle1GR/LMDZ/1/8=; b=hcniV5Q4COA/eZ+T+5lpBu/zR/eRaBcQWdMs4uG/2sqcdIqRIJ2N1EUOWB4nIpms0g V87Es2pzxRlG+PRum1xkOsH9mVIKM7XUt5Gprx+i7I7GPWAifR1fkRw0tKJy9Rx7/Gmj O/jNRFhnU5ie2DL2Umumsh+1VYstX1vXI35eM= Received: by 10.52.184.103 with SMTP id et7mr15716141vdc.35.1319228999043; Fri, 21 Oct 2011 13:29:59 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.52.186.39 with HTTP; Fri, 21 Oct 2011 13:29:39 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> <82AB329A76E2484D934BBCA77E9F52491D632BCD@DAPHNIS.office.hd> From: Richard Alimi Date: Fri, 21 Oct 2011 13:29:39 -0700 X-Google-Sender-Auth: MrrnxMs3NHGAIx-Yh0OdJnWdk6c Message-ID: To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 20:30:00 -0000 On Fri, Oct 21, 2011 at 11:42 AM, Rahman, Akbar wrote: > Hi Rich, > > > The one other point to consider is that in Fig. 1 and in the text we allo= w DECADE protocols (DRP/SDT) to run between servers only (without any clien= ts involved). =A0So in that case do we still want to prohibit the server fr= om performing the naming? > Well, whichever server has the object should already know the name (either because it got it from the client and validated it, or because it generated it). The server receiving the object would then presumably validate what it got. So in short, the one sending an object in the 'write' request should supply the name. I agree that when writing this text, we need to be careful how it is worded so we don't have issues in the server<->server case. Thanks, Rich > > > Akbar > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of Richard Alimi > Sent: Friday, October 21, 2011 11:26 AM > To: Dirk Kutscher > Cc: decade ietf > Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 > > On Fri, Oct 21, 2011 at 8:09 AM, Dirk Kutscher = wrote: >> Hi, >> >> On this comment: >> >>> >>> 6.2.1 =A71 >>> >>> In the first =A7 it is unclear if the client or the server is namin= g >>> >>> the object. If both alternatives are allowed this should be stated >>> >>> explicitly and it should be added a comment to the parameter NAME >>> >>> that it can be empty. >>> >>> Then in =A74 it is stated "The application that originates the obje= cts >>> >>> MUST generate DECADE object names according to the naming >>> >>> specification in Section 5.3." Is it sure that we want this? Sensor= s >>> >>> might want the server to generate the names. >>> >> >>> >> The original intent was for the name to be sent by the client, and >>> >> then validated by the server. That said, I have only two reservation= s >>> >> about having the server compute the name (if the client does not wan= t >>> >> to): >>> >> (1) the server is forced to compute the hash which may be expensive. >>> >> I might imagine certain cases where servers disable this (knowing th= e >>> >> risks of not validating the hashes), in which case a request from >>> >> such a client would be rejected. =A0I don't think this would be comm= on, >>> >> though. >>> >> (2) the client must trust the server if this is done (otherwise the >>> >> server can insert, remove, or completely fabricate the content and >>> >> lie about the name). >>> >> >>> >> Therefore, I don't have a problem as long as the security >>> >> consideration is made completely clear. >>> >> >>> >> Thoughts? >>> > >>> > I think both clients and servers =A0should be allowed to create name = it is not >>> up to the architecture to decide on what is appropriate in specific net= work >>> environments. >>> >>> That's fine - but the security properties are different and need to be = called >>> out explicitly. =A0Objections from others about allowing the server to = compute >>> the name? >> >> IMO, in DECADE, we should leave it to the client only, otherwise the fun= damental use case (application endpoint uploads named object, refers other = endpoints to the objects using the name and authorization tokens) is not gu= aranteed to work in all cases. >> > > The way I read his suggestion was that there is the option of the > server generating the name. =A0Put another way, the client still has > capability to generate the name (and the server may verify), but the > client could also be lazy and accept the security consequences. =A0I > completely agree that we don't want to require the server to generate > the name. > >> For example, what if the server uses a hash algorithm that is not useful= in an application context? What about compromised servers that give you a = name that is not bound to the object etc? >> > > I agree with your concerns, and those are the ones that would need to > be called out if we were to add something for this. > >> I would prefer a clear separation of concerns: application endpoint crea= te and name objects, DECADE servers distribute and host named objects. >> > > That is a good point. =A0Maybe one possibility is to have the base > protocol without this capability, and then have an extension to handle > clients that for some-reason can't or don't want to compute a hash? > > Rich > >> Best regards, >> >> Dirk >> >> >> >> >> >> >> >> >> >> > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From dave.mcdysan@verizon.com Fri Oct 21 13:39:05 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A1421F8AB0 for ; Fri, 21 Oct 2011 13:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PreWrvzqdQc for ; Fri, 21 Oct 2011 13:39:04 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1C57721F889A for ; Fri, 21 Oct 2011 13:39:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 21 Oct 2011 20:39:02 +0000 From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.69,388,1315180800"; d="scan'208,217";a="164319873" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 21 Oct 2011 20:39:01 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.148]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Fri, 21 Oct 2011 16:38:59 -0400 To: "Woundy, Richard" , "decade@ietf.org" Date: Fri, 21 Oct 2011 16:38:59 -0400 Thread-Topic: [decade] Start of WGLC for draft-ietf-decade-arch-03 Thread-Index: AcyQMXXiQxPxPSkUTTamuEP7axHzwA== Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CAC73B4D25C24davemcdysanoneverizoncom_" MIME-Version: 1.0 Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 20:39:05 -0000 --_000_CAC73B4D25C24davemcdysanoneverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I looked over the revised draft and my major review comments were addressed= . Thanks, Dave From: "Woundy, Richard" > Date: Thu, 29 Sep 2011 08:13:56 -0400 To: "decade@ietf.org" > Subject: [decade] Start of WGLC for draft-ietf-decade-arch-03 Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -arch-03, http://datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be co= mpleted by Monday October 17. Please send all concerns, suggestions and com= ments about this internet-draft to the DECADE mailing list, decade@ietf.org= . Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_CAC73B4D25C24davemcdysanoneverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I looked over the revise= d draft and my major review comments were addressed.

Thanks,


From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com&g= t;
Date: Thu, 29 Sep 2011 08:13= :56 -0400
To: "decade@ietf.org" <decade@ietf.org>
Subject: [decade] Start of WGLC for draft-ietf-decade-arch-03

Folks,

 

Haibin and I are starting the working group last = call for draft-ietf-decade-arch-03, http://datatracker.ietf.org/doc/draft-ietf-de= cade-arch/, to be completed by Mon= day October 17. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing l= ist, decade@ietf.org.

 

Authors, please do not make any additional change= s to the internet-draft unless directed by the WG chairs.=

 <= /span>

Draft review= ers, it would be helpful to get your confirmation that your previous review= comments have been correctly reflected in this version.<= /p>

 

Thanks.<= /o:p>

&= nbsp;

= -- Rich and Haibin

--_000_CAC73B4D25C24davemcdysanoneverizoncom_-- From Akbar.Rahman@InterDigital.com Fri Oct 21 14:10:20 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE2A21F8B3A for ; Fri, 21 Oct 2011 14:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfR9fRnaIyQd for ; Fri, 21 Oct 2011 14:10:19 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7005C21F8B35 for ; Fri, 21 Oct 2011 14:10:19 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 17:09:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 21 Oct 2011 20:30:05.0025 (UTC) FILETIME=[37769510:01CC9030] X-Barracuda-Start-Time: 1319229001 X-Barracuda-Connect: mail-vw0-f54.google.com[209.85.212.54] X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.78009Rule breakdown below pts rule name description---- ---------------------- -------------------------------------------------- X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=2.0 KILL_LEVEL=2.8 tests= X-ASG-Orig-Subj: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-ASG-Debug-ID: 1319228999-01e5e50c64b8f10001-r1BGa4 X-Barracuda-URL: http://172.22.1.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Envelope-From: richard.alimi@gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=mRS1CzOgNTPCYeBKOO4R0PEeWMKOqle1GR/LMDZ/1/8=; b=hcniV5Q4COA/eZ+T+5lpBu/zR/eRaBcQWdMs4uG/2sqcdIqRIJ2N1EUOWB4nIpms0g V87Es2pzxRlG+PRum1xkOsH9mVIKM7XUt5Gprx+i7I7GPWAifR1fkRw0tKJy9Rx7/Gmj O/jNRFhnU5ie2DL2Umumsh+1VYstX1vXI35eM= X-Barracuda-Encrypted: RC4-SHA X-Google-Sender-Auth: MrrnxMs3NHGAIx-Yh0OdJnWdk6c X-Barracuda-Apparent-Source-IP: 209.85.212.54 Content-class: urn:content-classes:message Date: Fri, 21 Oct 2011 17:09:37 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Start of WGLC for draft-ietf-decade-arch-03 Thread-index: AcyQMDmn5p7Ma998Q+OQRzbrqngAAwABYOwj References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> <82AB329A76E2484D934BBCA77E9F52491D632BCD@DAPHNIS.office.hd> From: "Rahman, Akbar" To: "Richard Alimi" Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 21:10:20 -0000 SGkgUmljaCwNCg0KRXhhY3RseS4gVGhlIGtleSBwb2ludCBpcyB0aGF0IHRoZSBzZW5kZXIgZ2Vu ZXJhdGVzIHRoZSBuYW1lLiBBbmQgdGhlIHNlbmRlciBjYW4gYmUgZWl0aGVyIGEgY2xpZW50IG9y IGEgc2VydmVyLiBJIHRoaW5rIHRoYXQgaXMgaG93IHdlIHNob3VsZCByZS13b3JkIGl0IHRvIGJl Lg0KDQpBa2Jhcg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJpY2hh cmQgQWxpbWkgW3JpY2hAdmVsdmV0c2VhLm5ldF0NClNlbnQ6IEZyaWRheSwgT2N0b2JlciAyMSwg MjAxMSAwNDozMCBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOiBSYWhtYW4sIEFrYmFyDQpD YzogZGVjYWRlIGlldGY7IERpcmsgS3V0c2NoZXI7IELDtnJqZSBPaGxtYW4NClN1YmplY3Q6IFJl OiBbZGVjYWRlXSBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLWRlY2FkZS1hcmNoLTAzDQoN Cg0KDQpPbiBGcmksIE9jdCAyMSwgMjAxMSBhdCAxMTo0MiBBTSwgUmFobWFuLCBBa2Jhcg0KPEFr YmFyLlJhaG1hbkBpbnRlcmRpZ2l0YWwuY29tPiB3cm90ZToNCj4gSGkgUmljaCwNCj4NCj4NCj4g VGhlIG9uZSBvdGhlciBwb2ludCB0byBjb25zaWRlciBpcyB0aGF0IGluIEZpZy4gMSBhbmQgaW4g dGhlIHRleHQgd2UgYWxsb3cgREVDQURFIHByb3RvY29scyAoRFJQL1NEVCkgdG8gcnVuIGJldHdl ZW4gc2VydmVycyBvbmx5ICh3aXRob3V0IGFueSBjbGllbnRzIGludm9sdmVkKS4gIFNvIGluIHRo YXQgY2FzZSBkbyB3ZSBzdGlsbCB3YW50IHRvIHByb2hpYml0IHRoZSBzZXJ2ZXIgZnJvbSBwZXJm b3JtaW5nIHRoZSBuYW1pbmc/DQo+DQoNCldlbGwsIHdoaWNoZXZlciBzZXJ2ZXIgaGFzIHRoZSBv YmplY3Qgc2hvdWxkIGFscmVhZHkga25vdyB0aGUgbmFtZQ0KKGVpdGhlciBiZWNhdXNlIGl0IGdv dCBpdCBmcm9tIHRoZSBjbGllbnQgYW5kIHZhbGlkYXRlZCBpdCwgb3IgYmVjYXVzZQ0KaXQgZ2Vu ZXJhdGVkIGl0KS4gIFRoZSBzZXJ2ZXIgcmVjZWl2aW5nIHRoZSBvYmplY3Qgd291bGQgdGhlbg0K cHJlc3VtYWJseSB2YWxpZGF0ZSB3aGF0IGl0IGdvdC4gIFNvIGluIHNob3J0LCB0aGUgb25lIHNl bmRpbmcgYW4NCm9iamVjdCBpbiB0aGUgJ3dyaXRlJyByZXF1ZXN0IHNob3VsZCBzdXBwbHkgdGhl IG5hbWUuDQoNCkkgYWdyZWUgdGhhdCB3aGVuIHdyaXRpbmcgdGhpcyB0ZXh0LCB3ZSBuZWVkIHRv IGJlIGNhcmVmdWwgaG93IGl0IGlzDQp3b3JkZWQgc28gd2UgZG9uJ3QgaGF2ZSBpc3N1ZXMgaW4g dGhlIHNlcnZlcjwtPnNlcnZlciBjYXNlLg0KDQpUaGFua3MsDQpSaWNoDQoNCj4NCj4NCj4gQWti YXINCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGVjYWRlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFJpY2hhcmQgQWxpbWkNCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDIxLCAyMDExIDExOjI2IEFN DQo+IFRvOiBEaXJrIEt1dHNjaGVyDQo+IENjOiBkZWNhZGUgaWV0Zg0KPiBTdWJqZWN0OiBSZTog W2RlY2FkZV0gU3RhcnQgb2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1kZWNhZGUtYXJjaC0wMw0KPg0K PiBPbiBGcmksIE9jdCAyMSwgMjAxMSBhdCA4OjA5IEFNLCBEaXJrIEt1dHNjaGVyIDxEaXJrLkt1 dHNjaGVyQG5lY2xhYi5ldT4gd3JvdGU6DQo+PiBIaSwNCj4+DQo+PiBPbiB0aGlzIGNvbW1lbnQ6 DQo+Pg0KPj4+ID4+PiA2LjIuMSDCpzENCj4+PiA+Pj4gSW4gdGhlIGZpcnN0IMKnIGl0IGlzIHVu Y2xlYXIgaWYgdGhlIGNsaWVudCBvciB0aGUgc2VydmVyIGlzIG5hbWluZw0KPj4+ID4+PiB0aGUg b2JqZWN0LiBJZiBib3RoIGFsdGVybmF0aXZlcyBhcmUgYWxsb3dlZCB0aGlzIHNob3VsZCBiZSBz dGF0ZWQNCj4+PiA+Pj4gZXhwbGljaXRseSBhbmQgaXQgc2hvdWxkIGJlIGFkZGVkIGEgY29tbWVu dCB0byB0aGUgcGFyYW1ldGVyIE5BTUUNCj4+PiA+Pj4gdGhhdCBpdCBjYW4gYmUgZW1wdHkuDQo+ Pj4gPj4+IFRoZW4gaW4gwqc0IGl0IGlzIHN0YXRlZCAiVGhlIGFwcGxpY2F0aW9uIHRoYXQgb3Jp Z2luYXRlcyB0aGUgb2JqZWN0cw0KPj4+ID4+PiBNVVNUIGdlbmVyYXRlIERFQ0FERSBvYmplY3Qg bmFtZXMgYWNjb3JkaW5nIHRvIHRoZSBuYW1pbmcNCj4+PiA+Pj4gc3BlY2lmaWNhdGlvbiBpbiBT ZWN0aW9uIDUuMy4iIElzIGl0IHN1cmUgdGhhdCB3ZSB3YW50IHRoaXM/IFNlbnNvcnMNCj4+PiA+ Pj4gbWlnaHQgd2FudCB0aGUgc2VydmVyIHRvIGdlbmVyYXRlIHRoZSBuYW1lcy4NCj4+PiA+Pg0K Pj4+ID4+IFRoZSBvcmlnaW5hbCBpbnRlbnQgd2FzIGZvciB0aGUgbmFtZSB0byBiZSBzZW50IGJ5 IHRoZSBjbGllbnQsIGFuZA0KPj4+ID4+IHRoZW4gdmFsaWRhdGVkIGJ5IHRoZSBzZXJ2ZXIuIFRo YXQgc2FpZCwgSSBoYXZlIG9ubHkgdHdvIHJlc2VydmF0aW9ucw0KPj4+ID4+IGFib3V0IGhhdmlu ZyB0aGUgc2VydmVyIGNvbXB1dGUgdGhlIG5hbWUgKGlmIHRoZSBjbGllbnQgZG9lcyBub3Qgd2Fu dA0KPj4+ID4+IHRvKToNCj4+PiA+PiAoMSkgdGhlIHNlcnZlciBpcyBmb3JjZWQgdG8gY29tcHV0 ZSB0aGUgaGFzaCB3aGljaCBtYXkgYmUgZXhwZW5zaXZlLg0KPj4+ID4+IEkgbWlnaHQgaW1hZ2lu ZSBjZXJ0YWluIGNhc2VzIHdoZXJlIHNlcnZlcnMgZGlzYWJsZSB0aGlzIChrbm93aW5nIHRoZQ0K Pj4+ID4+IHJpc2tzIG9mIG5vdCB2YWxpZGF0aW5nIHRoZSBoYXNoZXMpLCBpbiB3aGljaCBjYXNl IGEgcmVxdWVzdCBmcm9tDQo+Pj4gPj4gc3VjaCBhIGNsaWVudCB3b3VsZCBiZSByZWplY3RlZC4g IEkgZG9uJ3QgdGhpbmsgdGhpcyB3b3VsZCBiZSBjb21tb24sDQo+Pj4gPj4gdGhvdWdoLg0KPj4+ ID4+ICgyKSB0aGUgY2xpZW50IG11c3QgdHJ1c3QgdGhlIHNlcnZlciBpZiB0aGlzIGlzIGRvbmUg KG90aGVyd2lzZSB0aGUNCj4+PiA+PiBzZXJ2ZXIgY2FuIGluc2VydCwgcmVtb3ZlLCBvciBjb21w bGV0ZWx5IGZhYnJpY2F0ZSB0aGUgY29udGVudCBhbmQNCj4+PiA+PiBsaWUgYWJvdXQgdGhlIG5h bWUpLg0KPj4+ID4+DQo+Pj4gPj4gVGhlcmVmb3JlLCBJIGRvbid0IGhhdmUgYSBwcm9ibGVtIGFz IGxvbmcgYXMgdGhlIHNlY3VyaXR5DQo+Pj4gPj4gY29uc2lkZXJhdGlvbiBpcyBtYWRlIGNvbXBs ZXRlbHkgY2xlYXIuDQo+Pj4gPj4NCj4+PiA+PiBUaG91Z2h0cz8NCj4+PiA+DQo+Pj4gPiBJIHRo aW5rIGJvdGggY2xpZW50cyBhbmQgc2VydmVycyAgc2hvdWxkIGJlIGFsbG93ZWQgdG8gY3JlYXRl IG5hbWUgaXQgaXMgbm90DQo+Pj4gdXAgdG8gdGhlIGFyY2hpdGVjdHVyZSB0byBkZWNpZGUgb24g d2hhdCBpcyBhcHByb3ByaWF0ZSBpbiBzcGVjaWZpYyBuZXR3b3JrDQo+Pj4gZW52aXJvbm1lbnRz Lg0KPj4+DQo+Pj4gVGhhdCdzIGZpbmUgLSBidXQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgYXJl IGRpZmZlcmVudCBhbmQgbmVlZCB0byBiZSBjYWxsZWQNCj4+PiBvdXQgZXhwbGljaXRseS4gIE9i amVjdGlvbnMgZnJvbSBvdGhlcnMgYWJvdXQgYWxsb3dpbmcgdGhlIHNlcnZlciB0byBjb21wdXRl DQo+Pj4gdGhlIG5hbWU/DQo+Pg0KPj4gSU1PLCBpbiBERUNBREUsIHdlIHNob3VsZCBsZWF2ZSBp dCB0byB0aGUgY2xpZW50IG9ubHksIG90aGVyd2lzZSB0aGUgZnVuZGFtZW50YWwgdXNlIGNhc2Ug KGFwcGxpY2F0aW9uIGVuZHBvaW50IHVwbG9hZHMgbmFtZWQgb2JqZWN0LCByZWZlcnMgb3RoZXIg ZW5kcG9pbnRzIHRvIHRoZSBvYmplY3RzIHVzaW5nIHRoZSBuYW1lIGFuZCBhdXRob3JpemF0aW9u IHRva2VucykgaXMgbm90IGd1YXJhbnRlZWQgdG8gd29yayBpbiBhbGwgY2FzZXMuDQo+Pg0KPg0K PiBUaGUgd2F5IEkgcmVhZCBoaXMgc3VnZ2VzdGlvbiB3YXMgdGhhdCB0aGVyZSBpcyB0aGUgb3B0 aW9uIG9mIHRoZQ0KPiBzZXJ2ZXIgZ2VuZXJhdGluZyB0aGUgbmFtZS4gIFB1dCBhbm90aGVyIHdh eSwgdGhlIGNsaWVudCBzdGlsbCBoYXMNCj4gY2FwYWJpbGl0eSB0byBnZW5lcmF0ZSB0aGUgbmFt ZSAoYW5kIHRoZSBzZXJ2ZXIgbWF5IHZlcmlmeSksIGJ1dCB0aGUNCj4gY2xpZW50IGNvdWxkIGFs c28gYmUgbGF6eSBhbmQgYWNjZXB0IHRoZSBzZWN1cml0eSBjb25zZXF1ZW5jZXMuICBJDQo+IGNv bXBsZXRlbHkgYWdyZWUgdGhhdCB3ZSBkb24ndCB3YW50IHRvIHJlcXVpcmUgdGhlIHNlcnZlciB0 byBnZW5lcmF0ZQ0KPiB0aGUgbmFtZS4NCj4NCj4+IEZvciBleGFtcGxlLCB3aGF0IGlmIHRoZSBz ZXJ2ZXIgdXNlcyBhIGhhc2ggYWxnb3JpdGhtIHRoYXQgaXMgbm90IHVzZWZ1bCBpbiBhbiBhcHBs aWNhdGlvbiBjb250ZXh0PyBXaGF0IGFib3V0IGNvbXByb21pc2VkIHNlcnZlcnMgdGhhdCBnaXZl IHlvdSBhIG5hbWUgdGhhdCBpcyBub3QgYm91bmQgdG8gdGhlIG9iamVjdCBldGM/DQo+Pg0KPg0K PiBJIGFncmVlIHdpdGggeW91ciBjb25jZXJucywgYW5kIHRob3NlIGFyZSB0aGUgb25lcyB0aGF0 IHdvdWxkIG5lZWQgdG8NCj4gYmUgY2FsbGVkIG91dCBpZiB3ZSB3ZXJlIHRvIGFkZCBzb21ldGhp bmcgZm9yIHRoaXMuDQo+DQo+PiBJIHdvdWxkIHByZWZlciBhIGNsZWFyIHNlcGFyYXRpb24gb2Yg Y29uY2VybnM6IGFwcGxpY2F0aW9uIGVuZHBvaW50IGNyZWF0ZSBhbmQgbmFtZSBvYmplY3RzLCBE RUNBREUgc2VydmVycyBkaXN0cmlidXRlIGFuZCBob3N0IG5hbWVkIG9iamVjdHMuDQo+Pg0KPg0K PiBUaGF0IGlzIGEgZ29vZCBwb2ludC4gIE1heWJlIG9uZSBwb3NzaWJpbGl0eSBpcyB0byBoYXZl IHRoZSBiYXNlDQo+IHByb3RvY29sIHdpdGhvdXQgdGhpcyBjYXBhYmlsaXR5LCBhbmQgdGhlbiBo YXZlIGFuIGV4dGVuc2lvbiB0byBoYW5kbGUNCj4gY2xpZW50cyB0aGF0IGZvciBzb21lLXJlYXNv biBjYW4ndCBvciBkb24ndCB3YW50IHRvIGNvbXB1dGUgYSBoYXNoPw0KPg0KPiBSaWNoDQo+DQo+ PiBCZXN0IHJlZ2FyZHMsDQo+Pg0KPj4gRGlyaw0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4N Cj4+DQo+Pg0KPj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gZGVjYWRlIG1haWxpbmcgbGlzdA0KPiBkZWNhZGVAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZWNhZGUNCj4NCg0KDQo= From borje.ohlman@ericsson.com Fri Oct 21 22:53:08 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9571511E808C for ; Fri, 21 Oct 2011 22:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsdtsLk3aiMA for ; Fri, 21 Oct 2011 22:53:08 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C98DB11E8081 for ; Fri, 21 Oct 2011 22:53:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-2a-4ea25a41c5ca Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 99.87.13753.14A52AE4; Sat, 22 Oct 2011 07:53:05 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.124]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 22 Oct 2011 07:53:05 +0200 From: =?iso-8859-1?Q?B=F6rje_Ohlman?= To: Richard Alimi Date: Sat, 22 Oct 2011 07:53:10 +0200 Thread-Topic: [decade] Start of WGLC for draft-ietf-decade-arch-03 Thread-Index: AcyQft4QKCKl2qLUTEq8gR+tmA8uzQ== Message-ID: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> <82AB329A76E2484D934BBCA77E9F52491D632BCD@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 05:53:08 -0000 I'ld be fine with this. B=F6rje On 21 okt 2011, at 17.25, Richard Alimi wrote: I would prefer a clear separation of concerns: application endpoint create = and name objects, DECADE servers distribute and host named objects. That is a good point. Maybe one possibility is to have the base protocol without this capability, and then have an extension to handle clients that for some-reason can't or don't want to compute a hash? Rich From yry@cs.yale.edu Sat Oct 22 12:30:49 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E98221F8AAA for ; Sat, 22 Oct 2011 12:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S87A3xFsJUe for ; Sat, 22 Oct 2011 12:30:48 -0700 (PDT) Received: from vm-emlprdomr-03.its.yale.edu (vm-emlprdomr-03.its.yale.edu [130.132.50.144]) by ietfa.amsl.com (Postfix) with ESMTP id 76F2821F8AA8 for ; Sat, 22 Oct 2011 12:30:47 -0700 (PDT) Received: from [10.0.0.5] (adsl-71-139-148-18.dsl.mrdnct.sbcglobal.net [71.139.148.18]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (8.14.4/8.14.4) with ESMTP id p9MJUGmq019645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 22 Oct 2011 15:30:16 -0400 References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1437EB69-B337-4B88-80D8-5BF4FEB42C34@ericsson.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8F191) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <1DAC261A-76A4-489E-AF67-ADEB6A4E3AA8@cs.yale.edu> X-Mailer: iPad Mail (8F191) From: YR Yang Date: Sat, 22 Oct 2011 15:36:20 -0400 To: Richard Alimi X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144 Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 19:30:49 -0000 On Oct 21, 2011, at 12:30 AM, Richard Alimi wrote: > On Thu, Oct 20, 2011 at 7:26 PM, Songhaibin wrote= : >>=20 >>=20 >>> -----Original Message----- >>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf= Of >>> Richard Alimi >>> Sent: Sunday, October 16, 2011 11:53 PM >>> To: B=C3=B6rje Ohlman >>> Cc: decade ietf >>> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 >>>=20 >>> On Fri, Oct 14, 2011 at 4:11 AM, B=C3=B6rje Ohlman >>> wrote: >>>> Hi, >>>> I think the draft is in very good shape, thanks to the authors for an >>>> excellent job. All my previous comments are addressed by this draft. Ho= wever >>>> looking through it last night I have some additional comments. >>>> ---------- >>>>=20 >>>> 5.1. Immutable Data >>>> REQUIREMENT(S): DECADE MUST provide the ability to manage data >>>> objects that are immutable once they are written to storage. >>>>=20 >>>> I think this requirement is a bit unclear on what is actually meant. My= >>>> understanding from our discussions is that DECADE MUST *only* store >>>> immutable data objects. If that is the intention, I think that should b= e >>>> stated more clearly. I don't think the word "ability" is the best to ex= press >>>> this requirement. An alternative formulation could be: >>>> "DECADE MUST only store and manage data objects that are immutable once= >>> they >>>> are written to storage." >>>> If I have misunderstood the intention of this requirement and that it s= hould >>>> also be possible to store mutable data in DECADE servers, then I think s= uch >>>> an explicit requirement should be added. >>>=20 >>> Your understanding was correct, and I agree with your suggested text. >>> Any complaints from others with adopting that? >>>=20 >>=20 >> I would agree with the change. >>=20 >>>> ------------ >>>>=20 >>>> 5.2. Explicit Deletion of Data >>>> REQUIREMENT(S): DECADE MUST support the ability for a DECADE client >>>> to explicitly delete data from its own in-network storage. >>>>=20 >>>> RATIONALE: A DECADE client may continually be writing data to its >>>> in-network storage. Since there may be a limit (e.g., imposed by >>>> the storage provider) to how much total storage can be used, some >>>> data may need to be removed to make room for additional data. A >>>> DECADE client should be able to explicitly remove particular >>>> data. This may be implemented using existing protocols. >>>>=20 >>>> When reading the rationale for this requirement I start to thinking tha= t we >>>> might want to add something about automatic removal of old data accordi= ng to >>>> some policy, e.g. that DECADE storage servers SHOULD be able to remove o= ld >>>> data according to some policy, e.g. LLRU. This should be of interest, e= .g. >>>> when a quota is being filled up, to avoid having to deny further writin= gs. >>>> This should be especially relevant in the mentioned case of continuous >>>> writings, e.g. for streaming data. >>>=20 >>> This is a very good question. Two comments here: >>> (1) We already have 4.4.3 which allows objects to be deleted after a >>> time-to-live, which can help with the streaming case. >>> (2) I think what you are proposing is a more general mechanism for >>> cache-replacement. While I think that would be a nice feature to >>> have, I'm a bit concerned about the complexity. I might imagine >>> something as complex as designing a new specification language for >>> custom cache replacement policies, or something as simple as "we >>> specify LRU and LFU - the rest are extensions". The latter might work >>> in certain cases, but for cases such as VoD / DVR type stuff, I'm not >>> sure either is sufficient (I may just not have watched the program >>> yet). Furthermore, what happens when multiple applications (run by >>> the same user, accessing the same account) each want to have their own >>> cache replacement policy and they might be in conflict? >>>=20 >>> Thoughts? >>>=20 >>=20 >> I think imposing some intelligent data deletion mechanism will make the d= esign complicated. But TTL should be okay. Shall we leave them to the applic= ations to implement and make DECADE design as simple as possible? >>=20 >=20 > I agree with having only TTL for now. Additional deletion policies > might be done as extensions at a later time too. The deletion is an interesting discussion. One thing coming to mind is if we= enforce a default TTL, or a maximum TTL. In other words, we make the whole s= torage soft state. Unless refreshed, data will be deleted by default. Otherw= ise, if the TTL is infinity, should the data be always there? Richard=20 >=20 > Rich >=20 >> BR, >> -Haibin (as individual) >>=20 >>=20 >>> Thanks, >>> Rich >>>=20 >>>> ----------------- >>>> B=C3=B6rje >>>>=20 >>>>=20 >>>>=20 >>>> On 29 sep 2011, at 14.12, Woundy, Richard wrote: >>>>=20 >>>> Folks, >>>>=20 >>>> Haibin and I are starting the working group last call for >>>>=20 >>> draft-ietf-decade-reqs-04, http://datatracker.ietf.org/doc/draft-ietf-de= cade-req >>> s/, >>>> to be completed by Monday October 17. Please send all concerns, suggest= ions >>>> and comments about this internet-draft to the DECADE mailing >>>> list, decade@ietf.org. >>>>=20 >>>> Authors, please do not make any additional changes to the internet-draf= t >>>> unless directed by the WG chairs. >>>>=20 >>>> Draft reviewers, it would be helpful to get your confirmation that your= >>>> previous review comments have been correctly reflected in this version.= >>>>=20 >>>> Thanks. >>>>=20 >>>> -- Rich and Haibin >>>> _______________________________________________ >>>> decade mailing list >>>> decade@ietf.org >>>> https://www.ietf.org/mailman/listinfo/decade >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> decade mailing list >>>> decade@ietf.org >>>> https://www.ietf.org/mailman/listinfo/decade >>>>=20 >>>>=20 >>> _______________________________________________ >>> decade mailing list >>> decade@ietf.org >>> https://www.ietf.org/mailman/listinfo/decade >>=20 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From richard.alimi@gmail.com Sat Oct 22 15:46:08 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C9721F84B9 for ; Sat, 22 Oct 2011 15:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPbHwgovdx0X for ; Sat, 22 Oct 2011 15:46:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC9021F8494 for ; Sat, 22 Oct 2011 15:46:07 -0700 (PDT) Received: by iabn5 with SMTP id n5so7045374iab.31 for ; Sat, 22 Oct 2011 15:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=5VbHIFo7boxGo6Fy19LjRCvF7Q39UrmAzOkRw+aDXkc=; b=Ta8pTeyk2pj14FifRpyQ6Sv/xcptHseNhdIuNYZxtXY9qthIwKT5XqTn8/UE+Da/yd FV2SWPnBqI/5vE2PyAm/5VwCDzhhAdHYqd+MERwyVLpuuIiHwe8QZbfmzdoKPODxAWhg krjYOc87wZS3RedRh52YsCmfjnFGQoXxdeMCQ= Received: by 10.42.154.194 with SMTP id r2mr32898364icw.50.1319323564100; Sat, 22 Oct 2011 15:46:04 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.152.69 with HTTP; Sat, 22 Oct 2011 15:45:44 -0700 (PDT) In-Reply-To: <1DAC261A-76A4-489E-AF67-ADEB6A4E3AA8@cs.yale.edu> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1437EB69-B337-4B88-80D8-5BF4FEB42C34@ericsson.com> <1DAC261A-76A4-489E-AF67-ADEB6A4E3AA8@cs.yale.edu> From: Richard Alimi Date: Sat, 22 Oct 2011 15:45:44 -0700 X-Google-Sender-Auth: vOLgbAgdty95F8rqNt5SxhueIjY Message-ID: To: YR Yang Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 22:46:08 -0000 On Sat, Oct 22, 2011 at 12:36 PM, YR Yang wrote: > > > On Oct 21, 2011, at 12:30 AM, Richard Alimi wrote: > >> On Thu, Oct 20, 2011 at 7:26 PM, Songhaibin wro= te: >>> >>> >>>> -----Original Message----- >>>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Beha= lf Of >>>> Richard Alimi >>>> Sent: Sunday, October 16, 2011 11:53 PM >>>> To: B=F6rje Ohlman >>>> Cc: decade ietf >>>> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 >>>> >>>> On Fri, Oct 14, 2011 at 4:11 AM, B=F6rje Ohlman >>>> wrote: >>>>> Hi, >>>>> I think the draft is in very good shape, thanks to the authors for an >>>>> excellent job. All my previous comments are addressed by this draft. = However >>>>> looking through it last night I have some additional comments. >>>>> ---------- >>>>> >>>>> 5.1. Immutable Data >>>>> REQUIREMENT(S): DECADE MUST provide the ability to manage data >>>>> objects that are immutable once they are written to storage. >>>>> >>>>> I think this requirement is a bit unclear on what is actually meant. = My >>>>> understanding from our discussions is that DECADE MUST *only* store >>>>> immutable data objects. If that is the intention, I think that should= be >>>>> stated more clearly. I don't think the word "ability" is the best to = express >>>>> this requirement. An alternative formulation could be: >>>>> "DECADE MUST only store and manage data objects that are immutable on= ce >>>> they >>>>> are written to storage." >>>>> If I have misunderstood the intention of this requirement and that it= should >>>>> also be possible to store mutable data in DECADE servers, then I thin= k such >>>>> an explicit requirement should be added. >>>> >>>> Your understanding was correct, and I agree with your suggested text. >>>> Any complaints from others with adopting that? >>>> >>> >>> I would agree with the change. >>> >>>>> ------------ >>>>> >>>>> 5.2. Explicit Deletion of Data >>>>> REQUIREMENT(S): DECADE MUST support the ability for a DECADE client >>>>> to explicitly delete data from its own in-network storage. >>>>> >>>>> RATIONALE: A DECADE client may continually be writing data to its >>>>> in-network storage. Since there may be a limit (e.g., imposed by >>>>> the storage provider) to how much total storage can be used, some >>>>> data may need to be removed to make room for additional data. A >>>>> DECADE client should be able to explicitly remove particular >>>>> data. This may be implemented using existing protocols. >>>>> >>>>> When reading the rationale for this requirement I start to thinking t= hat we >>>>> might want to add something about automatic removal of old data accor= ding to >>>>> some policy, e.g. that DECADE storage servers SHOULD be able to remov= e old >>>>> data according to some policy, e.g. LLRU. This should be of interest,= e.g. >>>>> when a quota is being filled up, to avoid having to deny further writ= ings. >>>>> This should be especially relevant in the mentioned case of continuou= s >>>>> writings, =A0e.g. for streaming data. >>>> >>>> This is a very good question. =A0Two comments here: >>>> (1) We already have 4.4.3 which allows objects to be deleted after a >>>> time-to-live, which can help with the streaming case. >>>> (2) I think what you are proposing is a more general mechanism for >>>> cache-replacement. =A0While I think that would be a nice feature to >>>> have, I'm a bit concerned about the complexity. =A0I might imagine >>>> something as complex as designing a new specification language for >>>> custom cache replacement policies, or something as simple as "we >>>> specify LRU and LFU - the rest are extensions". =A0The latter might wo= rk >>>> in certain cases, but for cases such as VoD / DVR type stuff, I'm not >>>> sure either is sufficient (I may just not have watched the program >>>> yet). =A0Furthermore, what happens when multiple applications (run by >>>> the same user, accessing the same account) each want to have their own >>>> cache replacement policy and they might be in conflict? >>>> >>>> Thoughts? >>>> >>> >>> I think imposing some intelligent data deletion mechanism will make the= design complicated. But TTL should be okay. Shall we leave them to the app= lications to implement and make DECADE design as simple as possible? >>> >> >> I agree with having only TTL for now. =A0Additional deletion policies >> might be done as extensions at a later time too. > > The deletion is an interesting discussion. One thing coming to mind is if= we enforce a default TTL, or a maximum TTL. In other words, we make the wh= ole storage soft state. Unless refreshed, data will be deleted by default. = Otherwise, if the TTL is infinity, should the data be always there? > If DECADE storage is user-controlled, is there a reason that a default TTL should be used by the server? I would tend to think this would be a client-side decision (maybe an implementation-specific default). I think one concern I would have is that it would limit the application of DECADE to applications that are able to be running often enough to actually refresh data (what if the user/owner goes away on vacation and turns off the computer at home?), or have data that is only short-lived (e.g., live streaming). Thanks, Rich > Richard > >> >> Rich >> >>> BR, >>> -Haibin (as individual) >>> >>> >>>> Thanks, >>>> Rich >>>> >>>>> ----------------- >>>>> B=F6rje >>>>> >>>>> >>>>> >>>>> On 29 sep 2011, at 14.12, Woundy, Richard wrote: >>>>> >>>>> Folks, >>>>> >>>>> Haibin and I are starting the working group last call for >>>>> >>>> draft-ietf-decade-reqs-04, http://datatracker.ietf.org/doc/draft-ietf-= decade-req >>>> s/, >>>>> to be completed by Monday October 17. Please send all concerns, sugge= stions >>>>> and comments about this internet-draft to the DECADE mailing >>>>> list, decade@ietf.org. >>>>> >>>>> Authors, please do not make any additional changes to the internet-dr= aft >>>>> unless directed by the WG chairs. >>>>> >>>>> Draft reviewers, it would be helpful to get your confirmation that yo= ur >>>>> previous review comments have been correctly reflected in this versio= n. >>>>> >>>>> Thanks. >>>>> >>>>> -- Rich and Haibin >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>> _______________________________________________ >>>> 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 yry@cs.yale.edu Sat Oct 22 16:51:56 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E160A21F8ABC for ; Sat, 22 Oct 2011 16:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kPYCrSoEz-Z for ; Sat, 22 Oct 2011 16:51:56 -0700 (PDT) Received: from vm-emlprdomr-03.its.yale.edu (vm-emlprdomr-03.its.yale.edu [130.132.50.144]) by ietfa.amsl.com (Postfix) with ESMTP id C2A5D21F8A4E for ; Sat, 22 Oct 2011 16:51:55 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro.local ([128.36.169.188]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (8.14.4/8.14.4) with ESMTP id p9MNpkxC009251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Oct 2011 19:51:47 -0400 Message-ID: <4EA35712.1040401@cs.yale.edu> Date: Sat, 22 Oct 2011 19:51:46 -0400 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Richard Alimi References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1437EB69-B337-4B88-80D8-5BF4FEB42C34@ericsson.com> <1DAC261A-76A4-489E-AF67-ADEB6A4E3AA8@cs.yale.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144 Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 23:51:57 -0000 On 10/22/11 6:45 PM, Richard Alimi wrote: > On Sat, Oct 22, 2011 at 12:36 PM, YR Yang wrote: >> >> On Oct 21, 2011, at 12:30 AM, Richard Alimi wrote: >> >>> On Thu, Oct 20, 2011 at 7:26 PM, Songhaibin wrote: >>>> >>>>> -----Original Message----- >>>>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of >>>>> Richard Alimi >>>>> Sent: Sunday, October 16, 2011 11:53 PM >>>>> To: Börje Ohlman >>>>> Cc: decade ietf >>>>> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 >>>>> >>>>> On Fri, Oct 14, 2011 at 4:11 AM, Börje Ohlman >>>>> wrote: >>>>>> Hi, >>>>>> I think the draft is in very good shape, thanks to the authors for an >>>>>> excellent job. All my previous comments are addressed by this draft. However >>>>>> looking through it last night I have some additional comments. >>>>>> ---------- >>>>>> >>>>>> 5.1. Immutable Data >>>>>> REQUIREMENT(S): DECADE MUST provide the ability to manage data >>>>>> objects that are immutable once they are written to storage. >>>>>> >>>>>> I think this requirement is a bit unclear on what is actually meant. My >>>>>> understanding from our discussions is that DECADE MUST *only* store >>>>>> immutable data objects. If that is the intention, I think that should be >>>>>> stated more clearly. I don't think the word "ability" is the best to express >>>>>> this requirement. An alternative formulation could be: >>>>>> "DECADE MUST only store and manage data objects that are immutable once >>>>> they >>>>>> are written to storage." >>>>>> If I have misunderstood the intention of this requirement and that it should >>>>>> also be possible to store mutable data in DECADE servers, then I think such >>>>>> an explicit requirement should be added. >>>>> Your understanding was correct, and I agree with your suggested text. >>>>> Any complaints from others with adopting that? >>>>> >>>> I would agree with the change. >>>> >>>>>> ------------ >>>>>> >>>>>> 5.2. Explicit Deletion of Data >>>>>> REQUIREMENT(S): DECADE MUST support the ability for a DECADE client >>>>>> to explicitly delete data from its own in-network storage. >>>>>> >>>>>> RATIONALE: A DECADE client may continually be writing data to its >>>>>> in-network storage. Since there may be a limit (e.g., imposed by >>>>>> the storage provider) to how much total storage can be used, some >>>>>> data may need to be removed to make room for additional data. A >>>>>> DECADE client should be able to explicitly remove particular >>>>>> data. This may be implemented using existing protocols. >>>>>> >>>>>> When reading the rationale for this requirement I start to thinking that we >>>>>> might want to add something about automatic removal of old data according to >>>>>> some policy, e.g. that DECADE storage servers SHOULD be able to remove old >>>>>> data according to some policy, e.g. LLRU. This should be of interest, e.g. >>>>>> when a quota is being filled up, to avoid having to deny further writings. >>>>>> This should be especially relevant in the mentioned case of continuous >>>>>> writings, e.g. for streaming data. >>>>> This is a very good question. Two comments here: >>>>> (1) We already have 4.4.3 which allows objects to be deleted after a >>>>> time-to-live, which can help with the streaming case. >>>>> (2) I think what you are proposing is a more general mechanism for >>>>> cache-replacement. While I think that would be a nice feature to >>>>> have, I'm a bit concerned about the complexity. I might imagine >>>>> something as complex as designing a new specification language for >>>>> custom cache replacement policies, or something as simple as "we >>>>> specify LRU and LFU - the rest are extensions". The latter might work >>>>> in certain cases, but for cases such as VoD / DVR type stuff, I'm not >>>>> sure either is sufficient (I may just not have watched the program >>>>> yet). Furthermore, what happens when multiple applications (run by >>>>> the same user, accessing the same account) each want to have their own >>>>> cache replacement policy and they might be in conflict? >>>>> >>>>> Thoughts? >>>>> >>>> I think imposing some intelligent data deletion mechanism will make the design complicated. But TTL should be okay. Shall we leave them to the applications to implement and make DECADE design as simple as possible? >>>> >>> I agree with having only TTL for now. Additional deletion policies >>> might be done as extensions at a later time too. >> The deletion is an interesting discussion. One thing coming to mind is if we enforce a default TTL, or a maximum TTL. In other words, we make the whole storage soft state. Unless refreshed, data will be deleted by default. Otherwise, if the TTL is infinity, should the data be always there? >> > If DECADE storage is user-controlled, is there a reason that a default > TTL should be used by the server? I would tend to think this would be > a client-side decision (maybe an implementation-specific default). I > think one concern I would have is that it would limit the application > of DECADE to applications that are able to be running often enough to > actually refresh data (what if the user/owner goes away on vacation > and turns off the computer at home?), or have data that is only > short-lived (e.g., live streaming). Default is less an issue, but allowing a very large maximum could be an issue. I like your example of going vacation (say an around-the-globe-one-year one :-). Should the user still anticipate that the data be available after the user is back? If it is a persistent storage system, say S3/Dropbox, I think the user should. But for a content distribution storage system, should it be? We can assume that the user still pays the bill during the vacation. Or maximum TTL is a policy issue that can be discovered... What do you think? Richard > Thanks, > Rich > >> Richard >> >>> Rich >>> >>>> BR, >>>> -Haibin (as individual) >>>> >>>> >>>>> Thanks, >>>>> Rich >>>>> >>>>>> ----------------- >>>>>> Börje >>>>>> >>>>>> >>>>>> >>>>>> On 29 sep 2011, at 14.12, Woundy, Richard wrote: >>>>>> >>>>>> Folks, >>>>>> >>>>>> Haibin and I are starting the working group last call for >>>>>> >>>>> draft-ietf-decade-reqs-04, http://datatracker.ietf.org/doc/draft-ietf-decade-req >>>>> s/, >>>>>> to be completed by Monday October 17. Please send all concerns, suggestions >>>>>> and comments about this internet-draft to the DECADE mailing >>>>>> list, decade@ietf.org. >>>>>> >>>>>> Authors, please do not make any additional changes to the internet-draft >>>>>> unless directed by the WG chairs. >>>>>> >>>>>> Draft reviewers, it would be helpful to get your confirmation that your >>>>>> previous review comments have been correctly reflected in this version. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -- Rich and Haibin >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 haibin.song@huawei.com Sun Oct 23 17:48:43 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4C21F8B79 for ; Sun, 23 Oct 2011 17:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.844 X-Spam-Level: X-Spam-Status: No, score=-4.844 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80pJzK+jPyCq for ; Sun, 23 Oct 2011 17:48:42 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id EC86321F8B4F for ; Sun, 23 Oct 2011 17:48:41 -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 <0LTJ00LSYOWGY6@szxga05-in.huawei.com> for decade@ietf.org; Mon, 24 Oct 2011 08:48:16 +0800 (CST) Received: from szxrg02-dlp.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 <0LTJ0027JOWF7P@szxga05-in.huawei.com> for decade@ietf.org; Mon, 24 Oct 2011 08:48:16 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ34765; Mon, 24 Oct 2011 08:48:14 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Oct 2011 08:48:13 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.75]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Mon, 24 Oct 2011 08:48:04 +0800 Date: Mon, 24 Oct 2011 00:48:03 +0000 From: Songhaibin In-reply-to: <82AB329A76E2484D934BBCA77E9F52491D632BC0@DAPHNIS.office.hd> X-Originating-IP: [10.138.41.129] To: Dirk Kutscher , Richard Alimi Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [decade] Start of WGLC for draft-ietf-decade-arch-03 Thread-index: AQHMfqFTeDHHyrbYIEqOVtMSowYBoZWAOEQAgAEJHYCAAJnZgIAAA40AgAAUqoCABEuT4P//q/0AgACYkgCABEor4A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> <5384B03A-1403-473B-AB94-AEAE58D76427@ericsson.com> <82AB329A76E2484D934BBCA77E9F52491D632BC0@DAPHNIS.office.hd> Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 00:48:43 -0000 > -----Original Message----- > From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu] > Sent: Friday, October 21, 2011 11:10 PM > To: Richard Alimi; Songhaibin > Cc: decade ietf > Subject: RE: [decade] Start of WGLC for draft-ietf-decade-arch-03 >=20 > Hi all, >=20 > First of all, thanks a lot, B=F6rje, for the helpful review -- and thanks= , Rich, for > addressing the recent comments. >=20 > Let me comment on just this specific issue for now: >=20 > > > Shall we say the server "MUST" have the ability to serve the objects = that is > > being uploaded, while the server "MAY" choose to do it? > > > > > > > From the standpoint of a DECADE client, is there value in distinguishin= g > > between these two cases? > > (1) a server is able, but not configured to to serve an object that is = being > > uploaded > > (2) a server is not able to serve an object that is being uploaded >=20 > Yes, right -- there is no way for the client to negotiate this with or re= quest this > from the server, so just requiring the capability will not help. >=20 > I'd say this could really be an implementation-specific decision. Some se= rvers > might be able to do it, others not. If you want to provide DECADE for > download-based services only, you would not really need it. >=20 I would like to give one use case. A streaming application provider (DECADE= client) may explicitly tell the DECADE server to serve its streaming data = to the application clients (with embedded DECADE clients) before the upload= is finished. The server is not configured, but is told to do this trough a= message. Does it make sense? BR, -Haibin (as individual) > So, "the server MAY...". >=20 > Best regards, >=20 > Dirk >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > > > Thanks, > > Rich > > > > > BR, > > > -Haibin > > > > > > > > >> -----Original Message----- > > >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > > >> Behalf Of B?rje Ohlman > > >> Sent: Wednesday, October 19, 2011 1:29 AM > > >> To: Richard Alimi > > >> Cc: decade ietf > > >> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 > > >> > > >> For me your proposals are fine. No more comments. > > >> > > >> =A0 =A0 =A0 B=F6rje > > >> > > >> On 18 okt 2011, at 18.14, Richard Alimi wrote: > > >> > > >> > On Tue, Oct 18, 2011 at 9:02 AM, B=F6rje Ohlman > > >> > > > >> wrote: > > >> >> Comments inline... > > >> >> > > >> >> On 18 okt 2011, at 08.51, Richard Alimi wrote: > > >> >> > > >> >>> Hi B=F6rje, > > >> >>> > > >> >>> Thank you very much for the review. =A0Responses inline... > > >> >>> > > >> >>> On Mon, Oct 17, 2011 at 8:02 AM, B=F6rje Ohlman > > >> wrote: > > >> >>>> > > >> >>>> The previous comment that I do not see as addressed is how > > >> >>>> overbooking > > >> of > > >> >>>> resources should be dealt with in DECADE. This is probably to > > >> >>>> large extent an SLA issue, but I think it would raise the issue > > >> >>>> in this draft. In my review of the previous draft I wrote: > > >> >>>> > > >> >>>> Is it allowed for decade service providers to oversell the > > >> >>>> resources of their servers (both bandwidth and storage), simila= r to > > airline overbooking? > > >> >>>> I think overbooking should be allowed to maximize resource > > utilization. > > >> >>>> Especially regarding bandwidth I think it is unavoidable. It > > >> >>>> would be good if this was addressed in the draft, e.g. in 4.2. > > >> >>> > > >> >>> My personal feeling is that this is a question of policy and not > > >> >>> a question for the protocol or architecture. =A0Do you think tha= t > > >> >>> leaving it out of scope will cause issues in the design or > > >> >>> eventual protocol specification? =A0I could see policy, algorith= ms, > > >> >>> and deployments changing based on whether oversubscription is > > >> >>> used, but what do you think the protocol ramifications might be? > > >> >>> Presumably we will need the architecture/protocol to have all th= e > > >> >>> nice features of any protocol such as overload handling anyways > > >> >>> (those are already in the requirements). > > >> >> > > >> >> Ok, fine. > > >> >> > > >> >>> > > >> >>>> 6.2.1 =A71 > > >> >>>> In the first =A7 it is unclear if the client or the server is > > >> >>>> naming the object. If both alternatives are allowed this should > > >> >>>> be stated explicitly and it should be added a comment to the > > >> >>>> parameter NAME that it can be empty. > > >> >>>> Then in =A74 it is stated "The application that originates the > > >> >>>> objects MUST generate DECADE object names according to the > > >> >>>> naming specification in Section 5.3." Is it sure that we want > > >> >>>> this? Sensors might want the server to generate the names. > > >> >>> > > >> >>> The original intent was for the name to be sent by the client, > > >> >>> and then validated by the server. That said, I have only two > > >> >>> reservations about having the server compute the name (if the > > >> >>> client does not want > > >> >>> to): > > >> >>> (1) the server is forced to compute the hash which may be > > expensive. > > >> >>> I might imagine certain cases where servers disable this (knowin= g > > >> >>> the risks of not validating the hashes), in which case a request > > >> >>> from such a client would be rejected. =A0I don't think this woul= d > > >> >>> be common, though. > > >> >>> (2) the client must trust the server if this is done (otherwise > > >> >>> the server can insert, remove, or completely fabricate the > > >> >>> content and lie about the name). > > >> >>> > > >> >>> Therefore, I don't have a problem as long as the security > > >> >>> consideration is made completely clear. > > >> >>> > > >> >>> Thoughts? > > >> >> > > >> >> I think both clients and servers =A0should be allowed to create n= ame > > >> >> it is not up > > >> to the architecture to decide on what is appropriate in specific > > >> network environments. > > >> > > > >> > That's fine - but the security properties are different and need t= o > > >> > be called out explicitly. =A0Objections from others about allowing > > >> > the server to compute the name? > > >> > > > >> >> > > >> >>> > > >> >>>> 6.2.1 last =A7 > > >> >>>> It states "Specifics regarding error handling, including > > >> >>>> additional error conditions, precedence for returned errors and > > >> >>>> its relation with server policy, are deferred to eventual > > >> >>>> protocol specification." Should not lack of resources be > > >> >>>> mentioned here as well as it is an obvious issue. This would be > > >> >>>> a possible place to add a comment on the issue with > > >> overbookings. > > >> >>> > > >> >>> Would additionally mentioning "overload conditions" (as it is > > >> >>> worded in the requirements draft) suffice? > > >> >> > > >> >> Fine. > > >> >> > > >> >>> > > >> >>>> 7 =A72 > > >> >>>> It states "All data operations are performed on behalf of DECAD= E > > >> >>>> clients via explicit instruction, ..." > > >> >>>> It is unclear from this text if the client has to be using the > > >> >>>> DECADE Protocol to perform this action or if an management or > > >> >>>> application protocol can be used to instruct the remote server. > > >> >>> > > >> >>> The intent was not to disallow access by > > >> >>> administrative/management protocols. =A0Would dropping the word > > >> >>> "all" from the beginning of the sentence help to clarify this? > > >> >> > > >> >> I think I should have included some more of the draft text here: > > >> >> "All data operations are performed on behalf of DECADE clients vi= a > > >> >> explicit instruction, so additional capabilities are needed in th= e > > >> >> DECADE client-server protocols DECADE clients must be able to > > >> >> indicate to a DECADE server the following additional parameters:" > > >> > > > >> > Well, there is a missing period in there. =A0Noted :) > > >> > > > >> >> > > >> >> I think it is the formulation " additional capabilities are neede= d > > >> >> in the DECADE client-server protocols" that is causing the proble= m > > >> >> by explicitly > > >> mentioning the DECADE protocols, a more neutral formulation not > > >> mentioning specific protocols I think would help. > > >> >> > > >> > > > >> > We could certainly drop the phrase "additional capabilities are > > >> > needed in the DECADE client-server protocols", but I think it woul= d > > >> > be understood that we are only talking about DECADE (since thats > > >> > what the document is about, and the protocol that would eventually= be > > defined). > > >> > Right? > > >> > > > >> >>> > > >> >>>> Should it not also be allowed for the client to delegate these > > >> >>>> operations to e.g. a cache managment application? > > >> >>> > > >> >>> Can you clarify the use case? =A0Who owns/manages the cache > > >> >>> management application? =A0Is it the same person as the DECADE > > >> >>> server? =A0Is it the same person as the DECADE client? > > >> >> > > >> >> One example would be a customer of network (and DECADE server) > > >> >> provider > > >> that just want to put data objects in it's 'local' DECADE storage an= d > > >> then want the network provider to populate other DECADE servers to > > >> provide a flexible CDN like functionality for the published objects. > > >> >> > > >> > > > >> > I think this case can be handled by the existing architecture. The > > >> > client could give the entity doing the replication (the network > > >> > provider in this case) tokens that provide read/write access to it= s > > >> > data objects. > > >> > > > >> > If you wanted to short-circuit this case by having the client not > > >> > give the tokens (since presumably the network provider owns the > > >> > DECADE servers and could replicate objects using some mechanism > > >> > other than DECADE), then that would be fine too - but that seems a > > >> > bit too specialized of a use case for this document. > > >> > > > >> >>>> 7.1 =A75 > > >> >>>> It states "Though explicitly supplying these may provide > > >> >>>> additional > > >> freedom, > > >> >>>> it is not clear what benefit they might provide." > > >> >>>> It is unclear what the "they" refers to. I have problems > > >> >>>> understanding the meaning of this sentence. > > >> >>> > > >> >>> "they" refers to the data object and operation parameters. =A0Fo= r > > >> >>> example, a typical (normal) use case might be to request to > > >> >>> download object 1 from Server A, but indicating that it must > > >> >>> fetch object 1 from Server B first. =A0Extending that slightly, = I > > >> >>> could imagine constructing protocol messages to request to > > >> >>> download object 1 from Server A, but indicating it must fetch ob= ject 2 > > from Server B first. > > >> >>> There may be interesting use cases for something like that - thi= s > > >> >>> sentence was merely trying to point this out. > > >> >>> > > >> >>> We can drop this sentence if it creates confusion. > > >> >> > > >> >> Please do. > > >> >> > > >> >>> > > >> >>>> 7.1 last =A7 > > >> >>>> It states "In the case of a GET operation, the DECADE server is > > >> >>>> to retrieve the data object from the remote server using the > > >> >>>> specified credentials (via a GET request to the remote server), > > >> >>>> and then return the object to the client." > > >> >>>> Why should the object be returned to the client? If this is jus= t > > >> >>>> about cache management there is no reason to return the object = to > > the client. > > >> >>> > > >> >>> No - it is not only about cache management. The client may not > > >> >>> have the object yet. However, that said, I might imagine cases > > >> >>> where the last step (downloading to the client itself) is > > >> >>> optional, e.g., if it wishes to delay downloading it over the > > >> >>> last mile for later. =A0We should add a note saying that it is o= ptional. > > >> >> > > >> >> Fine. > > >> >> > > >> >>> > > >> >>>> Further it states: "In the case of a PUT operation, the DECADE > > >> >>>> server is to store the object from the client..." This sounds > > >> >>>> like the client making this PUT I thought this was about server= to > > server communication. > > >> >>> > > >> >>> Yes - the server-to-server communication is explicitly controlle= d by > > the client. > > >> >>> > > >> >>> Similarly, we should add a note here saying that the upload from > > >> >>> the client to its own server is optional (the object may already > > >> >>> exist at one server, and the client may want it replicated to an= other > > server). > > >> >> > > >> >> Ok. > > >> >> > > >> >>> > > >> >>>> Also should not > > >> >>>> policies for the object, e.g. ttl, be stored? > > >> >>> > > >> >>> Yes. This section states "DECADE re-uses the already-specified > > >> >>> protocols to support operations directly between servers", and > > >> >>> these were mentioned in Section 6. =A0Should we explicitly menti= on > > >> >>> that such attributes can also be configured on requests involvin= g > > >> >>> server-to-server communication? > > >> >> > > >> >> Would be good for clarity. > > >> >> > > >> >>> > > >> >>>> 8.1 first =A7 > > >> >>>> It states "A DECADE server may choose to not fully store an > > >> >>>> object before beginning to serve it." The 'may choose' is not > > >> >>>> consistent with the MUST requierment to be able to deliver befo= re > > fully stored. > > >> >>> > > >> >>> Just to be sure, you are referring to this statement? > > >> >>> > > >> >>> =A0"A server MUST accept download requests for an object that is > > >> >>> still being uploaded." > > >> >> > > >> >> yes. > > >> >> > > >> >>> > > >> >>> That should indeed be a MAY to be consistent with the > > >> >>> requirements draft. =A0Objections? > > >> >> > > >> >> ok. > > >> >> > > >> >> > > >> >> > > >> > > > >> > Thanks again for your detailed reading of the document! > > >> > Rich > > >> > > >> _______________________________________________ > > >> 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 haibin.song@huawei.com Sun Oct 23 20:07:07 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C288B21F8BA7 for ; Sun, 23 Oct 2011 20:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.954 X-Spam-Level: X-Spam-Status: No, score=-4.954 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhzzsojNUpnk for ; Sun, 23 Oct 2011 20:07:07 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE2021F8BA2 for ; Sun, 23 Oct 2011 20:07:07 -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 <0LTJ00DV0VBAQ3@szxga04-in.huawei.com> for decade@ietf.org; Mon, 24 Oct 2011 11:06:46 +0800 (CST) Received: from szxrg02-dlp.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 <0LTJ00JXZVBACV@szxga04-in.huawei.com> for decade@ietf.org; Mon, 24 Oct 2011 11:06:46 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ44596; Mon, 24 Oct 2011 11:06:45 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Oct 2011 11:06:43 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.75]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Mon, 24 Oct 2011 11:06:36 +0800 Date: Mon, 24 Oct 2011 03:06:34 +0000 From: Songhaibin X-Originating-IP: [10.138.41.129] To: decade ietf Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Agenda Request for DECADE@IETF 82 Thread-index: AcyR+e+Dv3maqoi8Tte/4mnIe3DG2Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] Agenda Request for DECADE@IETF 82 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 03:07:07 -0000 Dear folks, The IETF 82 meeting is approaching. We would like to prepare for the DECADE meeting. If you have any topic to present at DECADE meeting, please send your request to Rich (Richard_Woundy@cable.comcast.com) and me (haibin.song@huawei.com). Please include the topic title (or draft name), presenter and time length in your request. Please also prepare your slides early, many participants who do not speak English as their first language are anticipated. Thanks, -Haibin and Rich From zongning@huawei.com Sun Oct 23 20:26:07 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8288121F8482 for ; Sun, 23 Oct 2011 20:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.233 X-Spam-Level: X-Spam-Status: No, score=-104.233 tagged_above=-999 required=5 tests=[AWL=-2.365, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_URI_REPLICA=1.634, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhNInpQQ29ET for ; Sun, 23 Oct 2011 20:26:07 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0F50021F84D5 for ; Sun, 23 Oct 2011 20:26:04 -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 <0LTJ009CHW6QFM@szxga05-in.huawei.com> for decade@ietf.org; Mon, 24 Oct 2011 11:25:38 +0800 (CST) Received: from szxrg01-dlp.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 <0LTJ00KDQW6P2D@szxga05-in.huawei.com> for decade@ietf.org; Mon, 24 Oct 2011 11:25:38 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ00693; Mon, 24 Oct 2011 11:25:36 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Oct 2011 11:25:36 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.36]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Mon, 24 Oct 2011 11:25:26 +0800 Date: Mon, 24 Oct 2011 03:25:26 +0000 From: ZongNing X-Originating-IP: [10.138.41.128] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-yry-decade-replication-00.txt Thread-index: AQHMkfqe/o/9Zr44ZUmAH4jWYJic/ZWK0VkQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] FW: New Version Notification for draft-yry-decade-replication-00.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 03:26:07 -0000 Hi, folks, We have submitted a new I-D about DECADE data replication as linked below: http://tools.ietf.org/id/draft-yry-decade-replication-00.txt Comments are welcome. BR, Ning Zong -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, October 24, 2011 11:11 AM To: ZongNing Cc: yry@cs.yale.edu; ZongNing Subject: New Version Notification for draft-yry-decade-replication-00.txt A new version of I-D, draft-yry-decade-replication-00.txt has been successfully submitted by Ning Zong and posted to the IETF repository. Filename: draft-yry-decade-replication Revision: 00 Title: DECADE Content Replication and Access Creation date: 2011-10-23 WG ID: Individual Submission Number of pages: 12 Abstract: The DECADE Working Group at IETF is working on introducing standard- based, application-agnostic in-network storage for content distribution to improve both network efficiency and application performance. In this document, we introduce content replication trees and then discuss approaches on how a replication tree can be constructed in DECADE. In particular, we introduce concepts including core-stateless content pull, and stateful, open content forwarding table. The IETF Secretariat From richard.alimi@gmail.com Mon Oct 24 09:05:33 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161CE21F8E0D for ; Mon, 24 Oct 2011 09:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uczL+RFgTTRC for ; Mon, 24 Oct 2011 09:05:32 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF70B21F8E0C for ; Mon, 24 Oct 2011 09:05:31 -0700 (PDT) Received: by vws5 with SMTP id 5so5548191vws.31 for ; Mon, 24 Oct 2011 09:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=OtX3Y9QuiHD2sFVB4Z/yjLGmLP77yibsP/yg9eZyIJ8=; b=dkY1tUTswAyq35fN+KOTxE2r5q1yn3lkxzRw7C23MamgMkqmDmelSqd6KpOgyfFPzZ VLScR9m1xQxliPbk06wUxjgVH2jfSHhZpE4H1IWVwOpeZ9FXqNqGKbjBDRgOCilCMbCA /psTwzQgdCO6AP5UZeNoz9wp/nAHwdimD0w5w= Received: by 10.52.34.177 with SMTP id a17mr6469885vdj.103.1319472330176; Mon, 24 Oct 2011 09:05:30 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.52.186.39 with HTTP; Mon, 24 Oct 2011 09:05:10 -0700 (PDT) In-Reply-To: <4EA35712.1040401@cs.yale.edu> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1437EB69-B337-4B88-80D8-5BF4FEB42C34@ericsson.com> <1DAC261A-76A4-489E-AF67-ADEB6A4E3AA8@cs.yale.edu> <4EA35712.1040401@cs.yale.edu> From: Richard Alimi Date: Mon, 24 Oct 2011 09:05:10 -0700 X-Google-Sender-Auth: 56PftwQOM1Spv2SnHGRreeU1U7w Message-ID: To: "Y. Richard Yang" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 16:05:33 -0000 On Sat, Oct 22, 2011 at 4:51 PM, Y. Richard Yang wrote: > On 10/22/11 6:45 PM, Richard Alimi wrote: >> >> On Sat, Oct 22, 2011 at 12:36 PM, YR Yang =A0wrote: >>> >>> On Oct 21, 2011, at 12:30 AM, Richard Alimi =A0wrot= e: >>> >>>> On Thu, Oct 20, 2011 at 7:26 PM, Songhaibin >>>> =A0wrote: >>>>> >>>>>> -----Original Message----- >>>>>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >>>>>> Behalf Of >>>>>> Richard Alimi >>>>>> Sent: Sunday, October 16, 2011 11:53 PM >>>>>> To: B=F6rje Ohlman >>>>>> Cc: decade ietf >>>>>> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 >>>>>> >>>>>> On Fri, Oct 14, 2011 at 4:11 AM, B=F6rje >>>>>> Ohlman >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> I think the draft is in very good shape, thanks to the authors for = an >>>>>>> excellent job. All my previous comments are addressed by this draft= . >>>>>>> However >>>>>>> looking through it last night I have some additional comments. >>>>>>> ---------- >>>>>>> >>>>>>> 5.1. Immutable Data >>>>>>> REQUIREMENT(S): DECADE MUST provide the ability to manage data >>>>>>> objects that are immutable once they are written to storage. >>>>>>> >>>>>>> I think this requirement is a bit unclear on what is actually meant= . >>>>>>> My >>>>>>> understanding from our discussions is that DECADE MUST *only* store >>>>>>> immutable data objects. If that is the intention, I think that shou= ld >>>>>>> be >>>>>>> stated more clearly. I don't think the word "ability" is the best t= o >>>>>>> express >>>>>>> this requirement. An alternative formulation could be: >>>>>>> "DECADE MUST only store and manage data objects that are immutable >>>>>>> once >>>>>> >>>>>> they >>>>>>> >>>>>>> are written to storage." >>>>>>> If I have misunderstood the intention of this requirement and that = it >>>>>>> should >>>>>>> also be possible to store mutable data in DECADE servers, then I >>>>>>> think such >>>>>>> an explicit requirement should be added. >>>>>> >>>>>> Your understanding was correct, and I agree with your suggested text= . >>>>>> Any complaints from others with adopting that? >>>>>> >>>>> I would agree with the change. >>>>> >>>>>>> ------------ >>>>>>> >>>>>>> 5.2. Explicit Deletion of Data >>>>>>> REQUIREMENT(S): DECADE MUST support the ability for a DECADE client >>>>>>> to explicitly delete data from its own in-network storage. >>>>>>> >>>>>>> RATIONALE: A DECADE client may continually be writing data to its >>>>>>> in-network storage. Since there may be a limit (e.g., imposed by >>>>>>> the storage provider) to how much total storage can be used, some >>>>>>> data may need to be removed to make room for additional data. A >>>>>>> DECADE client should be able to explicitly remove particular >>>>>>> data. This may be implemented using existing protocols. >>>>>>> >>>>>>> When reading the rationale for this requirement I start to thinking >>>>>>> that we >>>>>>> might want to add something about automatic removal of old data >>>>>>> according to >>>>>>> some policy, e.g. that DECADE storage servers SHOULD be able to >>>>>>> remove old >>>>>>> data according to some policy, e.g. LLRU. This should be of interes= t, >>>>>>> e.g. >>>>>>> when a quota is being filled up, to avoid having to deny further >>>>>>> writings. >>>>>>> This should be especially relevant in the mentioned case of >>>>>>> continuous >>>>>>> writings, =A0e.g. for streaming data. >>>>>> >>>>>> This is a very good question. =A0Two comments here: >>>>>> (1) We already have 4.4.3 which allows objects to be deleted after a >>>>>> time-to-live, which can help with the streaming case. >>>>>> (2) I think what you are proposing is a more general mechanism for >>>>>> cache-replacement. =A0While I think that would be a nice feature to >>>>>> have, I'm a bit concerned about the complexity. =A0I might imagine >>>>>> something as complex as designing a new specification language for >>>>>> custom cache replacement policies, or something as simple as "we >>>>>> specify LRU and LFU - the rest are extensions". =A0The latter might = work >>>>>> in certain cases, but for cases such as VoD / DVR type stuff, I'm no= t >>>>>> sure either is sufficient (I may just not have watched the program >>>>>> yet). =A0Furthermore, what happens when multiple applications (run b= y >>>>>> the same user, accessing the same account) each want to have their o= wn >>>>>> cache replacement policy and they might be in conflict? >>>>>> >>>>>> Thoughts? >>>>>> >>>>> I think imposing some intelligent data deletion mechanism will make t= he >>>>> design complicated. But TTL should be okay. Shall we leave them to th= e >>>>> applications to implement and make DECADE design as simple as possibl= e? >>>>> >>>> I agree with having only TTL for now. =A0Additional deletion policies >>>> might be done as extensions at a later time too. >>> >>> The deletion is an interesting discussion. One thing coming to mind is = if >>> we enforce a default TTL, or a maximum TTL. In other words, we make the >>> whole storage soft state. Unless refreshed, data will be deleted by def= ault. >>> Otherwise, if the TTL is infinity, should the data be always there? >>> >> If DECADE storage is user-controlled, is there a reason that a default >> TTL should be used by the server? =A0I would tend to think this would be >> a client-side decision (maybe an implementation-specific default). =A0I >> think one concern I would have is that it would limit the application >> of DECADE to applications that are able to be running often enough to >> actually refresh data (what if the user/owner goes away on vacation >> and turns off the computer at home?), or have data that is only >> short-lived (e.g., live streaming). > > Default is less an issue, but allowing a very large maximum could be an > issue. I like > your example of going vacation (say an around-the-globe-one-year one :-). > Should the user still anticipate that the data be available after the use= r > is > back? If it is a persistent storage system, say S3/Dropbox, I think the u= ser > should. > But for a content distribution storage system, should it be? Well, one thing that comes to mind is a DVR-type usage pattern. I have programs on my DVR from April that I still haven't watched yet, but still would like to (as long as I'm still paying my cable bill) :) In the DECADE use case, I might be storing some content at the server so I could view it while I'm traveling without requiring a computer at home to be on. > We can assume > that > the user still pays the bill during the vacation. Or maximum TTL is a pol= icy > issue > that can be discovered... What do you think? Having it as a policy that can be discovered I think would be a good idea (with one of the possible settings being infinity :) ). Bringing this back to the architecture document, would it be fair to say that we a DECADE server should be able to communicate storage policies to clients (e.g., maximum TTL)? Objections from anyone? Thanks, Rich > > Richard >> >> Thanks, >> Rich >> >>> Richard >>> >>>> Rich >>>> >>>>> BR, >>>>> -Haibin (as individual) >>>>> >>>>> >>>>>> Thanks, >>>>>> Rich >>>>>> >>>>>>> ----------------- >>>>>>> B=F6rje >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 29 sep 2011, at 14.12, Woundy, Richard wrote: >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> Haibin and I are starting the working group last call for >>>>>>> >>>>>> draft-ietf-decade-reqs-04, >>>>>> http://datatracker.ietf.org/doc/draft-ietf-decade-req >>>>>> s/, >>>>>>> >>>>>>> to be completed by Monday October 17. Please send all concerns, >>>>>>> suggestions >>>>>>> and comments about this internet-draft to the DECADE mailing >>>>>>> list, decade@ietf.org. >>>>>>> >>>>>>> Authors, please do not make any additional changes to the >>>>>>> internet-draft >>>>>>> unless directed by the WG chairs. >>>>>>> >>>>>>> Draft reviewers, it would be helpful to get your confirmation that >>>>>>> your >>>>>>> previous review comments have been correctly reflected in this >>>>>>> version. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> -- Rich and Haibin >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 Mon Oct 24 09:10:32 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134C721F8D1E for ; Mon, 24 Oct 2011 09:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuJQBkXk6TFm for ; Mon, 24 Oct 2011 09:10:04 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDBE121F8CA4 for ; Mon, 24 Oct 2011 09:09:57 -0700 (PDT) Received: by vws5 with SMTP id 5so5553327vws.31 for ; Mon, 24 Oct 2011 09:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=yaqchdqBBd+/r4PMTJ+suRtdiBUaQeDQC4B8FimUw3M=; b=T6QoOSbOu0kIsWiN4NGg5fOo3Y5w1OXKURqOoWLrtCnga6DrlivsNm7yN9gplmFsVe xEqhVSZlV3OeSRPBVJYK34K1zGHKM6QvjzVgD3nQ5ydaVVffjzO+60RrS4CCMavc0Alv +CmpKwd39C9fIArxnEOyxqKC5w3aPDQ04QPmI= Received: by 10.52.73.166 with SMTP id m6mr23408282vdv.18.1319472597194; Mon, 24 Oct 2011 09:09:57 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.52.186.39 with HTTP; Mon, 24 Oct 2011 09:09:37 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <6556C646-A675-4E23-A965-C087398371D3@ericsson.com> <57350D9F-4A21-48CC-BFFA-7598C8FAD1B4@ericsson.com> <5384B03A-1403-473B-AB94-AEAE58D76427@ericsson.com> <82AB329A76E2484D934BBCA77E9F52491D632BC0@DAPHNIS.office.hd> From: Richard Alimi Date: Mon, 24 Oct 2011 09:09:37 -0700 X-Google-Sender-Auth: yD9D7ykbnu3UoUPhQlv6KdmI1e4 Message-ID: To: Songhaibin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade ietf Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 16:10:34 -0000 On Sun, Oct 23, 2011 at 5:48 PM, Songhaibin wrote: > > >> -----Original Message----- >> From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu] >> Sent: Friday, October 21, 2011 11:10 PM >> To: Richard Alimi; Songhaibin >> Cc: decade ietf >> Subject: RE: [decade] Start of WGLC for draft-ietf-decade-arch-03 >> >> Hi all, >> >> First of all, thanks a lot, B=F6rje, for the helpful review -- and thank= s, Rich, for >> addressing the recent comments. >> >> Let me comment on just this specific issue for now: >> >> > > Shall we say the server "MUST" have the ability to serve the objects= that is >> > being uploaded, while the server "MAY" choose to do it? >> > > >> > >> > From the standpoint of a DECADE client, is there value in distinguishi= ng >> > between these two cases? >> > (1) a server is able, but not configured to to serve an object that is= being >> > uploaded >> > (2) a server is not able to serve an object that is being uploaded >> >> Yes, right -- there is no way for the client to negotiate this with or r= equest this >> from the server, so just requiring the capability will not help. >> >> I'd say this could really be an implementation-specific decision. Some s= ervers >> might be able to do it, others not. If you want to provide DECADE for >> download-based services only, you would not really need it. >> > > I would like to give one use case. A streaming application provider (DECA= DE client) may explicitly tell the DECADE server to serve its streaming dat= a to the application clients (with embedded DECADE clients) before the uplo= ad is finished. The server is not configured, but is told to do this trough= a message. Does it make sense? > Well, a couple of things here: (1) How does the client tell the server to enable this capability? Are you proposing a new client->server configuration service within DECADE? (2) Even if we had (1), I would think a simpler design would be for the client to just tell the server what it needs when it opens a session (in this case it would include the option saying "please allow downloading before the upload is finished"). The server then has the option to say "sorry, I can't do that" or "sure, go right ahead". (This is much more similar to the typical negotiation we see in HTTP, and we still don't have to distinguish between the case of the server not supporting it, and the server supporting it and it not being enabled). Thanks, Rich > BR, > -Haibin (as individual) > >> So, "the server MAY...". >> >> Best regards, >> >> Dirk >> >> >> >> >> >> >> >> >> > >> > Thanks, >> > Rich >> > >> > > BR, >> > > -Haibin >> > > >> > > >> > >> -----Original Message----- >> > >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >> > >> Behalf Of B?rje Ohlman >> > >> Sent: Wednesday, October 19, 2011 1:29 AM >> > >> To: Richard Alimi >> > >> Cc: decade ietf >> > >> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 >> > >> >> > >> For me your proposals are fine. No more comments. >> > >> >> > >> =A0 =A0 =A0 B=F6rje >> > >> >> > >> On 18 okt 2011, at 18.14, Richard Alimi wrote: >> > >> >> > >> > On Tue, Oct 18, 2011 at 9:02 AM, B=F6rje Ohlman >> > >> > >> > >> wrote: >> > >> >> Comments inline... >> > >> >> >> > >> >> On 18 okt 2011, at 08.51, Richard Alimi wrote: >> > >> >> >> > >> >>> Hi B=F6rje, >> > >> >>> >> > >> >>> Thank you very much for the review. =A0Responses inline... >> > >> >>> >> > >> >>> On Mon, Oct 17, 2011 at 8:02 AM, B=F6rje Ohlman >> > >> wrote: >> > >> >>>> >> > >> >>>> The previous comment that I do not see as addressed is how >> > >> >>>> overbooking >> > >> of >> > >> >>>> resources should be dealt with in DECADE. This is probably to >> > >> >>>> large extent an SLA issue, but I think it would raise the issu= e >> > >> >>>> in this draft. In my review of the previous draft I wrote: >> > >> >>>> >> > >> >>>> Is it allowed for decade service providers to oversell the >> > >> >>>> resources of their servers (both bandwidth and storage), simil= ar to >> > airline overbooking? >> > >> >>>> I think overbooking should be allowed to maximize resource >> > utilization. >> > >> >>>> Especially regarding bandwidth I think it is unavoidable. It >> > >> >>>> would be good if this was addressed in the draft, e.g. in 4.2. >> > >> >>> >> > >> >>> My personal feeling is that this is a question of policy and no= t >> > >> >>> a question for the protocol or architecture. =A0Do you think th= at >> > >> >>> leaving it out of scope will cause issues in the design or >> > >> >>> eventual protocol specification? =A0I could see policy, algorit= hms, >> > >> >>> and deployments changing based on whether oversubscription is >> > >> >>> used, but what do you think the protocol ramifications might be= ? >> > >> >>> Presumably we will need the architecture/protocol to have all t= he >> > >> >>> nice features of any protocol such as overload handling anyways >> > >> >>> (those are already in the requirements). >> > >> >> >> > >> >> Ok, fine. >> > >> >> >> > >> >>> >> > >> >>>> 6.2.1 =A71 >> > >> >>>> In the first =A7 it is unclear if the client or the server is >> > >> >>>> naming the object. If both alternatives are allowed this shoul= d >> > >> >>>> be stated explicitly and it should be added a comment to the >> > >> >>>> parameter NAME that it can be empty. >> > >> >>>> Then in =A74 it is stated "The application that originates the >> > >> >>>> objects MUST generate DECADE object names according to the >> > >> >>>> naming specification in Section 5.3." Is it sure that we want >> > >> >>>> this? Sensors might want the server to generate the names. >> > >> >>> >> > >> >>> The original intent was for the name to be sent by the client, >> > >> >>> and then validated by the server. That said, I have only two >> > >> >>> reservations about having the server compute the name (if the >> > >> >>> client does not want >> > >> >>> to): >> > >> >>> (1) the server is forced to compute the hash which may be >> > expensive. >> > >> >>> I might imagine certain cases where servers disable this (knowi= ng >> > >> >>> the risks of not validating the hashes), in which case a reques= t >> > >> >>> from such a client would be rejected. =A0I don't think this wou= ld >> > >> >>> be common, though. >> > >> >>> (2) the client must trust the server if this is done (otherwise >> > >> >>> the server can insert, remove, or completely fabricate the >> > >> >>> content and lie about the name). >> > >> >>> >> > >> >>> Therefore, I don't have a problem as long as the security >> > >> >>> consideration is made completely clear. >> > >> >>> >> > >> >>> Thoughts? >> > >> >> >> > >> >> I think both clients and servers =A0should be allowed to create = name >> > >> >> it is not up >> > >> to the architecture to decide on what is appropriate in specific >> > >> network environments. >> > >> > >> > >> > That's fine - but the security properties are different and need = to >> > >> > be called out explicitly. =A0Objections from others about allowin= g >> > >> > the server to compute the name? >> > >> > >> > >> >> >> > >> >>> >> > >> >>>> 6.2.1 last =A7 >> > >> >>>> It states "Specifics regarding error handling, including >> > >> >>>> additional error conditions, precedence for returned errors an= d >> > >> >>>> its relation with server policy, are deferred to eventual >> > >> >>>> protocol specification." Should not lack of resources be >> > >> >>>> mentioned here as well as it is an obvious issue. This would b= e >> > >> >>>> a possible place to add a comment on the issue with >> > >> overbookings. >> > >> >>> >> > >> >>> Would additionally mentioning "overload conditions" (as it is >> > >> >>> worded in the requirements draft) suffice? >> > >> >> >> > >> >> Fine. >> > >> >> >> > >> >>> >> > >> >>>> 7 =A72 >> > >> >>>> It states "All data operations are performed on behalf of DECA= DE >> > >> >>>> clients via explicit instruction, ..." >> > >> >>>> It is unclear from this text if the client has to be using the >> > >> >>>> DECADE Protocol to perform this action or if an management or >> > >> >>>> application protocol can be used to instruct the remote server= . >> > >> >>> >> > >> >>> The intent was not to disallow access by >> > >> >>> administrative/management protocols. =A0Would dropping the word >> > >> >>> "all" from the beginning of the sentence help to clarify this? >> > >> >> >> > >> >> I think I should have included some more of the draft text here: >> > >> >> "All data operations are performed on behalf of DECADE clients v= ia >> > >> >> explicit instruction, so additional capabilities are needed in t= he >> > >> >> DECADE client-server protocols DECADE clients must be able to >> > >> >> indicate to a DECADE server the following additional parameters:= " >> > >> > >> > >> > Well, there is a missing period in there. =A0Noted :) >> > >> > >> > >> >> >> > >> >> I think it is the formulation " additional capabilities are need= ed >> > >> >> in the DECADE client-server protocols" that is causing the probl= em >> > >> >> by explicitly >> > >> mentioning the DECADE protocols, a more neutral formulation not >> > >> mentioning specific protocols I think would help. >> > >> >> >> > >> > >> > >> > We could certainly drop the phrase "additional capabilities are >> > >> > needed in the DECADE client-server protocols", but I think it wou= ld >> > >> > be understood that we are only talking about DECADE (since thats >> > >> > what the document is about, and the protocol that would eventuall= y be >> > defined). >> > >> > Right? >> > >> > >> > >> >>> >> > >> >>>> Should it not also be allowed for the client to delegate these >> > >> >>>> operations to e.g. a cache managment application? >> > >> >>> >> > >> >>> Can you clarify the use case? =A0Who owns/manages the cache >> > >> >>> management application? =A0Is it the same person as the DECADE >> > >> >>> server? =A0Is it the same person as the DECADE client? >> > >> >> >> > >> >> One example would be a customer of network (and DECADE server) >> > >> >> provider >> > >> that just want to put data objects in it's 'local' DECADE storage a= nd >> > >> then want the network provider to populate other DECADE servers to >> > >> provide a flexible CDN like functionality for the published objects= . >> > >> >> >> > >> > >> > >> > I think this case can be handled by the existing architecture. Th= e >> > >> > client could give the entity doing the replication (the network >> > >> > provider in this case) tokens that provide read/write access to i= ts >> > >> > data objects. >> > >> > >> > >> > If you wanted to short-circuit this case by having the client not >> > >> > give the tokens (since presumably the network provider owns the >> > >> > DECADE servers and could replicate objects using some mechanism >> > >> > other than DECADE), then that would be fine too - but that seems = a >> > >> > bit too specialized of a use case for this document. >> > >> > >> > >> >>>> 7.1 =A75 >> > >> >>>> It states "Though explicitly supplying these may provide >> > >> >>>> additional >> > >> freedom, >> > >> >>>> it is not clear what benefit they might provide." >> > >> >>>> It is unclear what the "they" refers to. I have problems >> > >> >>>> understanding the meaning of this sentence. >> > >> >>> >> > >> >>> "they" refers to the data object and operation parameters. =A0F= or >> > >> >>> example, a typical (normal) use case might be to request to >> > >> >>> download object 1 from Server A, but indicating that it must >> > >> >>> fetch object 1 from Server B first. =A0Extending that slightly,= I >> > >> >>> could imagine constructing protocol messages to request to >> > >> >>> download object 1 from Server A, but indicating it must fetch o= bject 2 >> > from Server B first. >> > >> >>> There may be interesting use cases for something like that - th= is >> > >> >>> sentence was merely trying to point this out. >> > >> >>> >> > >> >>> We can drop this sentence if it creates confusion. >> > >> >> >> > >> >> Please do. >> > >> >> >> > >> >>> >> > >> >>>> 7.1 last =A7 >> > >> >>>> It states "In the case of a GET operation, the DECADE server i= s >> > >> >>>> to retrieve the data object from the remote server using the >> > >> >>>> specified credentials (via a GET request to the remote server)= , >> > >> >>>> and then return the object to the client." >> > >> >>>> Why should the object be returned to the client? If this is ju= st >> > >> >>>> about cache management there is no reason to return the object= to >> > the client. >> > >> >>> >> > >> >>> No - it is not only about cache management. The client may not >> > >> >>> have the object yet. However, that said, I might imagine cases >> > >> >>> where the last step (downloading to the client itself) is >> > >> >>> optional, e.g., if it wishes to delay downloading it over the >> > >> >>> last mile for later. =A0We should add a note saying that it is = optional. >> > >> >> >> > >> >> Fine. >> > >> >> >> > >> >>> >> > >> >>>> Further it states: "In the case of a PUT operation, the DECADE >> > >> >>>> server is to store the object from the client..." This sounds >> > >> >>>> like the client making this PUT I thought this was about serve= r to >> > server communication. >> > >> >>> >> > >> >>> Yes - the server-to-server communication is explicitly controll= ed by >> > the client. >> > >> >>> >> > >> >>> Similarly, we should add a note here saying that the upload fro= m >> > >> >>> the client to its own server is optional (the object may alread= y >> > >> >>> exist at one server, and the client may want it replicated to a= nother >> > server). >> > >> >> >> > >> >> Ok. >> > >> >> >> > >> >>> >> > >> >>>> Also should not >> > >> >>>> policies for the object, e.g. ttl, be stored? >> > >> >>> >> > >> >>> Yes. This section states "DECADE re-uses the already-specified >> > >> >>> protocols to support operations directly between servers", and >> > >> >>> these were mentioned in Section 6. =A0Should we explicitly ment= ion >> > >> >>> that such attributes can also be configured on requests involvi= ng >> > >> >>> server-to-server communication? >> > >> >> >> > >> >> Would be good for clarity. >> > >> >> >> > >> >>> >> > >> >>>> 8.1 first =A7 >> > >> >>>> It states "A DECADE server may choose to not fully store an >> > >> >>>> object before beginning to serve it." The 'may choose' is not >> > >> >>>> consistent with the MUST requierment to be able to deliver bef= ore >> > fully stored. >> > >> >>> >> > >> >>> Just to be sure, you are referring to this statement? >> > >> >>> >> > >> >>> =A0"A server MUST accept download requests for an object that i= s >> > >> >>> still being uploaded." >> > >> >> >> > >> >> yes. >> > >> >> >> > >> >>> >> > >> >>> That should indeed be a MAY to be consistent with the >> > >> >>> requirements draft. =A0Objections? >> > >> >> >> > >> >> ok. >> > >> >> >> > >> >> >> > >> >> >> > >> > >> > >> > Thanks again for your detailed reading of the document! >> > >> > Rich >> > >> >> > >> _______________________________________________ >> > >> 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 guyingjie@huawei.com Mon Oct 24 18:34:29 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E9F21F8CF0 for ; Mon, 24 Oct 2011 18:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.645 X-Spam-Level: X-Spam-Status: No, score=-104.645 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hxX3N8Vyy6F for ; Mon, 24 Oct 2011 18:34:28 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 366A421F8CEB for ; Mon, 24 Oct 2011 18:34:28 -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 <0LTL00BABLPCRM@szxga03-in.huawei.com> for decade@ietf.org; Tue, 25 Oct 2011 09:34:24 +0800 (CST) Received: from szxrg01-dlp.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 <0LTL006A9LPCTU@szxga03-in.huawei.com> for decade@ietf.org; Tue, 25 Oct 2011 09:34:24 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ52910; Tue, 25 Oct 2011 09:34:23 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 09:34:21 +0800 Received: from g00107907 (10.138.41.134) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 09:34:16 +0800 Date: Tue, 25 Oct 2011 09:37:14 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: X-Originating-IP: [10.138.41.134] To: 'Richard Alimi' , "'Y. Richard Yang'" Message-id: <00a301cc92b6$9fef6030$dfce2090$@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: quoted-printable Thread-index: AcySZuAKEFx3ZQHgQGmlYntkygoDdgATsIjA X-CFilter-Loop: Reflected References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1437EB69-B337-4B88-80D8-5BF4FEB42C34@ericsson.com> <1DAC261A-76A4-489E-AF67-ADEB6A4E3AA8@cs.yale.edu> <4EA35712.1040401@cs.yale.edu> Cc: 'decade ietf' Subject: [decade] =?utf-8?b?562U5aSNOiAgU3RhcnQgb2YgV0dMQyBmb3IgZHJhZnQt?= =?utf-8?q?ietf-decade-reqs-04?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:34:29 -0000 Let me try to follow this discussion. So, for now, we tend to allow the DECADE server deploy a default TTL for = each application from a client(the client can have more than one = applications running at the same time). And DECADE server can = communicate with DECADE client to decide the TTL value(i.e. the storage = policies in your emails).=20 Well, as far as I am concerned, I would say this is a good feature to = have. The DECADE server can communicate with DECADE client to decide the = access policies(i.e. access control in the draft) and resource = policies(i.e. resource control in the draft) already.=20 Best Regards Gu Yingjie -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: decade-bounces@ietf.org = [mailto:decade-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Richard Alimi =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2011=E5=B9=B410=E6=9C=8825=E6=97=A5 =E4=B9=90=E4=B9=900:05 =E6=94=B6=E4=BB=B6=E4=BA=BA: Y. Richard Yang =E6=8A=84=E9=80=81: decade ietf =E4=B8=BB=E9=A2=98: Re: [decade] Start of WGLC for = draft-ietf-decade-reqs-04 On Sat, Oct 22, 2011 at 4:51 PM, Y. Richard Yang = wrote: > On 10/22/11 6:45 PM, Richard Alimi wrote: >> >> On Sat, Oct 22, 2011 at 12:36 PM, YR Yang wrote: >>> >>> On Oct 21, 2011, at 12:30 AM, Richard Alimi = wrote: >>> >>>> On Thu, Oct 20, 2011 at 7:26 PM, Songhaibin >>>> wrote: >>>>> >>>>>> -----Original Message----- >>>>>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >>>>>> Behalf Of >>>>>> Richard Alimi >>>>>> Sent: Sunday, October 16, 2011 11:53 PM >>>>>> To: B=C3=B6rje Ohlman >>>>>> Cc: decade ietf >>>>>> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 >>>>>> >>>>>> On Fri, Oct 14, 2011 at 4:11 AM, B=C3=B6rje >>>>>> Ohlman >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> I think the draft is in very good shape, thanks to the authors = for an >>>>>>> excellent job. All my previous comments are addressed by this = draft. >>>>>>> However >>>>>>> looking through it last night I have some additional comments. >>>>>>> ---------- >>>>>>> >>>>>>> 5.1. Immutable Data >>>>>>> REQUIREMENT(S): DECADE MUST provide the ability to manage data >>>>>>> objects that are immutable once they are written to storage. >>>>>>> >>>>>>> I think this requirement is a bit unclear on what is actually = meant. >>>>>>> My >>>>>>> understanding from our discussions is that DECADE MUST *only* = store >>>>>>> immutable data objects. If that is the intention, I think that = should >>>>>>> be >>>>>>> stated more clearly. I don't think the word "ability" is the = best to >>>>>>> express >>>>>>> this requirement. An alternative formulation could be: >>>>>>> "DECADE MUST only store and manage data objects that are = immutable >>>>>>> once >>>>>> >>>>>> they >>>>>>> >>>>>>> are written to storage." >>>>>>> If I have misunderstood the intention of this requirement and = that it >>>>>>> should >>>>>>> also be possible to store mutable data in DECADE servers, then I >>>>>>> think such >>>>>>> an explicit requirement should be added. >>>>>> >>>>>> Your understanding was correct, and I agree with your suggested = text. >>>>>> Any complaints from others with adopting that? >>>>>> >>>>> I would agree with the change. >>>>> >>>>>>> ------------ >>>>>>> >>>>>>> 5.2. Explicit Deletion of Data >>>>>>> REQUIREMENT(S): DECADE MUST support the ability for a DECADE = client >>>>>>> to explicitly delete data from its own in-network storage. >>>>>>> >>>>>>> RATIONALE: A DECADE client may continually be writing data to = its >>>>>>> in-network storage. Since there may be a limit (e.g., imposed by >>>>>>> the storage provider) to how much total storage can be used, = some >>>>>>> data may need to be removed to make room for additional data. A >>>>>>> DECADE client should be able to explicitly remove particular >>>>>>> data. This may be implemented using existing protocols. >>>>>>> >>>>>>> When reading the rationale for this requirement I start to = thinking >>>>>>> that we >>>>>>> might want to add something about automatic removal of old data >>>>>>> according to >>>>>>> some policy, e.g. that DECADE storage servers SHOULD be able to >>>>>>> remove old >>>>>>> data according to some policy, e.g. LLRU. This should be of = interest, >>>>>>> e.g. >>>>>>> when a quota is being filled up, to avoid having to deny further >>>>>>> writings. >>>>>>> This should be especially relevant in the mentioned case of >>>>>>> continuous >>>>>>> writings, e.g. for streaming data. >>>>>> >>>>>> This is a very good question. Two comments here: >>>>>> (1) We already have 4.4.3 which allows objects to be deleted = after a >>>>>> time-to-live, which can help with the streaming case. >>>>>> (2) I think what you are proposing is a more general mechanism = for >>>>>> cache-replacement. While I think that would be a nice feature to >>>>>> have, I'm a bit concerned about the complexity. I might imagine >>>>>> something as complex as designing a new specification language = for >>>>>> custom cache replacement policies, or something as simple as "we >>>>>> specify LRU and LFU - the rest are extensions". The latter might = work >>>>>> in certain cases, but for cases such as VoD / DVR type stuff, I'm = not >>>>>> sure either is sufficient (I may just not have watched the = program >>>>>> yet). Furthermore, what happens when multiple applications (run = by >>>>>> the same user, accessing the same account) each want to have = their own >>>>>> cache replacement policy and they might be in conflict? >>>>>> >>>>>> Thoughts? >>>>>> >>>>> I think imposing some intelligent data deletion mechanism will = make the >>>>> design complicated. But TTL should be okay. Shall we leave them to = the >>>>> applications to implement and make DECADE design as simple as = possible? >>>>> >>>> I agree with having only TTL for now. Additional deletion policies >>>> might be done as extensions at a later time too. >>> >>> The deletion is an interesting discussion. One thing coming to mind = is if >>> we enforce a default TTL, or a maximum TTL. In other words, we make = the >>> whole storage soft state. Unless refreshed, data will be deleted by = default. >>> Otherwise, if the TTL is infinity, should the data be always there? >>> >> If DECADE storage is user-controlled, is there a reason that a = default >> TTL should be used by the server? I would tend to think this would = be >> a client-side decision (maybe an implementation-specific default). I >> think one concern I would have is that it would limit the application >> of DECADE to applications that are able to be running often enough to >> actually refresh data (what if the user/owner goes away on vacation >> and turns off the computer at home?), or have data that is only >> short-lived (e.g., live streaming). > > Default is less an issue, but allowing a very large maximum could be = an > issue. I like > your example of going vacation (say an around-the-globe-one-year one = :-). > Should the user still anticipate that the data be available after the = user > is > back? If it is a persistent storage system, say S3/Dropbox, I think = the user > should. > But for a content distribution storage system, should it be? Well, one thing that comes to mind is a DVR-type usage pattern. I have programs on my DVR from April that I still haven't watched yet, but still would like to (as long as I'm still paying my cable bill) :) In the DECADE use case, I might be storing some content at the server so I could view it while I'm traveling without requiring a computer at home to be on. > We can assume > that > the user still pays the bill during the vacation. Or maximum TTL is a = policy > issue > that can be discovered... What do you think? Having it as a policy that can be discovered I think would be a good idea (with one of the possible settings being infinity :) ). Bringing this back to the architecture document, would it be fair to say that we a DECADE server should be able to communicate storage policies to clients (e.g., maximum TTL)? Objections from anyone? Thanks, Rich > > Richard >> >> Thanks, >> Rich >> >>> Richard >>> >>>> Rich >>>> >>>>> BR, >>>>> -Haibin (as individual) >>>>> >>>>> >>>>>> Thanks, >>>>>> Rich >>>>>> >>>>>>> ----------------- >>>>>>> B=C3=B6rje >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 29 sep 2011, at 14.12, Woundy, Richard wrote: >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> Haibin and I are starting the working group last call for >>>>>>> >>>>>> draft-ietf-decade-reqs-04, >>>>>> http://datatracker.ietf.org/doc/draft-ietf-decade-req >>>>>> s/, >>>>>>> >>>>>>> to be completed by Monday October 17. Please send all concerns, >>>>>>> suggestions >>>>>>> and comments about this internet-draft to the DECADE mailing >>>>>>> list, decade@ietf.org. >>>>>>> >>>>>>> Authors, please do not make any additional changes to the >>>>>>> internet-draft >>>>>>> unless directed by the WG chairs. >>>>>>> >>>>>>> Draft reviewers, it would be helpful to get your confirmation = that >>>>>>> your >>>>>>> previous review comments have been correctly reflected in this >>>>>>> version. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> -- Rich and Haibin >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 > > _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From wwwrun@rfc-editor.org Mon Oct 24 21:56:01 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B6C1F0C79; Mon, 24 Oct 2011 21:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.287 X-Spam-Level: X-Spam-Status: No, score=-102.287 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60uJ+n43Dkkp; Mon, 24 Oct 2011 21:56:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D76501F0C76; Mon, 24 Oct 2011 21:56:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7E00598C294; Mon, 24 Oct 2011 21:55:59 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111025045600.7E00598C294@rfc-editor.org> Date: Mon, 24 Oct 2011 21:55:59 -0700 (PDT) Cc: decade@ietf.org, rfc-editor@rfc-editor.org Subject: [decade] RFC 6392 on A Survey of In-Network Storage Systems X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 04:56:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6392 Title: A Survey of In-Network Storage Systems Author: R. Alimi, Ed., A. Rahman, Ed., Y. Yang, Ed. Status: Informational Stream: IETF Date: October 2011 Mailbox: ralimi@google.com, Akbar.Rahman@InterDigital.com, yry@cs.yale.edu Pages: 44 Characters: 90978 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-decade-survey-06.txt URL: http://www.rfc-editor.org/rfc/rfc6392.txt This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupled Application Data Enroute) architecture. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Decoupled Application Data Enroute Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Oct 26 00:43:49 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8751421F8B07 for ; Wed, 26 Oct 2011 00:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.341 X-Spam-Level: X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57e8Mbr3pU+Y for ; Wed, 26 Oct 2011 00:43:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2260321F8B06 for ; Wed, 26 Oct 2011 00:43:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0F64198C245; Wed, 26 Oct 2011 00:43:49 -0700 (PDT) To: ralimi@google.com, Akbar.Rahman@InterDigital.com, yry@cs.yale.edu, ietfdbh@comcast.net, wes@mti-systems.com, Richard_Woundy@cable.comcast.com, haibin.song@huawei.com From: RFC Errata System Message-Id: <20111026074349.0F64198C245@rfc-editor.org> Date: Wed, 26 Oct 2011 00:43:49 -0700 (PDT) X-Mailman-Approved-At: Wed, 26 Oct 2011 00:51:35 -0700 Cc: bortzmeyer+rfceditor@nic.fr, decade@ietf.org, rfc-editor@rfc-editor.org Subject: [decade] [Technical Errata Reported] RFC6392 (3006) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 07:43:49 -0000 The following errata report has been submitted for RFC6392, "A Survey of In-Network Storage Systems". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6392&eid=3006 -------------------------------------- Type: Technical Reported by: Stéphane Bortzmeyer Section: 5.1.2 Original Text ------------- Not provided. Corrected Text -------------- Basic deletion of resources is provided with the DELETE method. Notes ----- The typical "data management operation" mentioned for other protocols is the deletion of data. HTTP has it from the beginning (Section 9.7 of RFC 2616). Apache does not support it directly, you apparently have to provide a module which does it (mod_dav does it, even if DELETE is not a WebDAV method). Anyway, this section is about the abilities of the protocol, not of implementations. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6392 (draft-ietf-decade-survey-06) -------------------------------------- Title : A Survey of In-Network Storage Systems Publication Date : October 2011 Author(s) : R. Alimi, Ed., A. Rahman, Ed., Y. Yang, Ed. Category : INFORMATIONAL Source : Decoupled Application Data Enroute Area : Transport Stream : IETF Verifying Party : IESG From Dirk.Kutscher@neclab.eu Wed Oct 26 06:06:49 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4452C21F89B8 for ; Wed, 26 Oct 2011 06:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBiaIicFZRKF for ; Wed, 26 Oct 2011 06:06:48 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3226C21F899F for ; Wed, 26 Oct 2011 06:06:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0796B280000FA; Wed, 26 Oct 2011 15:07:12 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6e+K0hMCBY2; Wed, 26 Oct 2011 15:07:11 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id DC16728000080; Wed, 26 Oct 2011 15:06:41 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.17]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 26 Oct 2011 15:06:17 +0200 From: Dirk Kutscher To: decade ietf Thread-Topic: URIs for DECADE -- Named Information URI Scheme Thread-Index: AcyT3Q1fSKP8TWxrSb+hOZRj/UgXMw== Date: Wed, 26 Oct 2011 13:06:16 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524924B74297@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.209] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Christian Dannewitz \(cdannewitz@uni-paderborn.de\)" , "Rob Stradling \(rob.stradling@comodo.com\)" , "philliph@comodo.com" Subject: [decade] URIs for DECADE -- Named Information URI Scheme X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 13:06:49 -0000 Dear all, We have updated the Named Information URI scheme that we presented at IETF-= 81. It turned out that the WEBSEC folks (Phillip Hallam-Baker and colleagues) h= ad started a parallel effort on a very similar approach, and -- fortunately= -- we have been able to combine our efforts and have advanced the spec so = that it would be useful for DECADE, WEBSEC and potentially other applicatio= ns. We still think that DECADE could benefit most at this time, so we submitted= this (as an individual submission) to DECADE now. We found a, IMO, nice way to have a concise base specification without excl= uding extensions for future application requirements. Basically, there is a= n extension mechanism that allows applications to specify additional parame= ters. To make this manageable, we have split the specification into two pieces: The base spec: http://tools.ietf.org/html/draft-farrell-decade-ni-00 This document defines a URI-based name form that identifies a named object via hash-based binding. The URI name form defined is intended for use in applications that need to uniquely identify resources in a location-independent way such as accessing in-network storage (DECADE), information-centric networking and more generally. The format is designed to support a strong link to the referenced object such that the referenced object may be authenticated to the same degree as the reference to it. The base spec has a set of useful general features (in addition to the actu= al syntax definition), such as processing rules (testing for equality), and= an algorithm that can be used to map NI URIs to HTTP(S) automatically -- w= hich I believe could be useful for DECADE, too. The base spec also defines = the fundamentals of the extension mechanism. A spec that defines a set of extension parameters and their semantics: http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 This document specifies some optional algorithms and parameters that may be used in the query string of ni URIs. One of the parameters that we have introduced here would allow you to speci= fy additional locators for resources -- again, that is expected to be usefu= l for DECADE. Looking forward, we envision that DECADE protocols may need additional para= meters. Investigating this and specifying the parameters could be done in D= ECADE (should we decide to re-charter for that). Please note that these two are individual submissions only -- i.e., merely = proposals that the group of authors are offering at this point. Nevertheless, we would be happy for any feedback. Best regards, Dirk From richard_woundy@cable.comcast.com Wed Oct 26 06:22:43 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A378F21F8A56 for ; Wed, 26 Oct 2011 06:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.835 X-Spam-Level: X-Spam-Status: No, score=-100.835 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B4MzB2x0h8M for ; Wed, 26 Oct 2011 06:22:40 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 77ADF21F899F for ; Wed, 26 Oct 2011 06:22:40 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.58726260; Wed, 26 Oct 2011 07:30:03 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Wed, 26 Oct 2011 09:22:20 -0400 From: "Woundy, Richard" To: "'Dirk.Kutscher@neclab.eu'" , "'decade@ietf.org'" Thread-Topic: [decade] URIs for DECADE -- Named Information URI Scheme Thread-Index: AcyT3Q1fSKP8TWxrSb+hOZRj/UgXMwABTywU Date: Wed, 26 Oct 2011 13:22:20 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136C0EEC@PACDCEXMB05.cable.comcast.com> In-Reply-To: <82AB329A76E2484D934BBCA77E9F524924B74297@PALLENE.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.50.241] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'rob.stradling@comodo.com'" , "'cdannewitz@uni-paderborn.de'" , "'philliph@comodo.com'" Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 13:22:43 -0000 Now that we have established that websec and decade are at least interested= in the named information uri scheme, do we know what group is expected to = own the base specification? That might be a good topic to discuss with the = relevant ADs in email now and at IETF 82 in person (app and tsv at least).= =20 ----- Original Message ----- From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu] Sent: Wednesday, October 26, 2011 09:06 AM=0A= To: decade ietf Cc: Christian Dannewitz (cdannewitz@uni-paderborn.de) ; Rob Stradling (rob.stradling@comodo.com) ; philliph@comodo.com Subject: [decade] URIs for DECADE -- Named Information URI Scheme Dear all, We have updated the Named Information URI scheme that we presented at IETF-= 81. It turned out that the WEBSEC folks (Phillip Hallam-Baker and colleagues) h= ad started a parallel effort on a very similar approach, and -- fortunately= -- we have been able to combine our efforts and have advanced the spec so = that it would be useful for DECADE, WEBSEC and potentially other applicatio= ns. We still think that DECADE could benefit most at this time, so we submitted= this (as an individual submission) to DECADE now. We found a, IMO, nice way to have a concise base specification without excl= uding extensions for future application requirements. Basically, there is a= n extension mechanism that allows applications to specify additional parame= ters. To make this manageable, we have split the specification into two pieces: The base spec: http://tools.ietf.org/html/draft-farrell-decade-ni-00 This document defines a URI-based name form that identifies a named object via hash-based binding. The URI name form defined is intended for use in applications that need to uniquely identify resources in a location-independent way such as accessing in-network storage (DECADE), information-centric networking and more generally. The format is designed to support a strong link to the referenced object such that the referenced object may be authenticated to the same degree as the reference to it. The base spec has a set of useful general features (in addition to the actu= al syntax definition), such as processing rules (testing for equality), and= an algorithm that can be used to map NI URIs to HTTP(S) automatically -- w= hich I believe could be useful for DECADE, too. The base spec also defines = the fundamentals of the extension mechanism. A spec that defines a set of extension parameters and their semantics: http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 This document specifies some optional algorithms and parameters that may be used in the query string of ni URIs. One of the parameters that we have introduced here would allow you to speci= fy additional locators for resources -- again, that is expected to be usefu= l for DECADE. Looking forward, we envision that DECADE protocols may need additional para= meters. Investigating this and specifying the parameters could be done in D= ECADE (should we decide to re-charter for that). Please note that these two are individual submissions only -- i.e., merely = proposals that the group of authors are offering at this point. Nevertheless, we would be happy for any feedback. Best regards, Dirk _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From Dirk.Kutscher@neclab.eu Wed Oct 26 06:27:16 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2908921F87E2 for ; Wed, 26 Oct 2011 06:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQwh2wUqkvSq for ; Wed, 26 Oct 2011 06:27:15 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7E27321F87D3 for ; Wed, 26 Oct 2011 06:27:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 66C03280000FA for ; Wed, 26 Oct 2011 15:27:39 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiEpp9-7Brwr for ; Wed, 26 Oct 2011 15:27:39 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 4CA2928000082 for ; Wed, 26 Oct 2011 15:27:34 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.17]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 26 Oct 2011 15:27:09 +0200 From: Dirk Kutscher To: "decade@ietf.org" Thread-Topic: DECADE Protocol Design Considerations Thread-Index: AcyT4peGeT3+T0UbSl+lkmlBZIgUHw== Date: Wed, 26 Oct 2011 13:27:09 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524924B743B9@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [decade] DECADE Protocol Design Considerations X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 13:27:16 -0000 Hi all, We have written up some design considerations for a DECADE protocol -- pro= viding some ideas on naming and a possible CDMI-based SDT. http://tools.ietf.org/html/draft-kutscher-decade-protocol-00 Hope this is useful -- any feedback would be appreciated. Thanks, Dirk From Dirk.Kutscher@neclab.eu Wed Oct 26 06:35:22 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A37B21F8B0C for ; Wed, 26 Oct 2011 06:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+xvBIX7l5o5 for ; Wed, 26 Oct 2011 06:35:21 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0A15A21F88AB for ; Wed, 26 Oct 2011 06:35:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E48BC280000FC; Wed, 26 Oct 2011 15:35:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzCw07aTEKg5; Wed, 26 Oct 2011 15:35:44 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id C6A7028000082; Wed, 26 Oct 2011 15:35:19 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.17]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 26 Oct 2011 15:34:55 +0200 From: Dirk Kutscher To: "Woundy, Richard" , "'decade@ietf.org'" Thread-Topic: [decade] URIs for DECADE -- Named Information URI Scheme Thread-Index: AcyT3Q1fSKP8TWxrSb+hOZRj/UgXMwABTywUAABQgHA= Date: Wed, 26 Oct 2011 13:34:55 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524924B74434@PALLENE.office.hd> References: <82AB329A76E2484D934BBCA77E9F524924B74297@PALLENE.office.hd> <1CA25301D2219F40B3AA37201F0EACD1136C0EEC@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136C0EEC@PACDCEXMB05.cable.comcast.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'rob.stradling@comodo.com'" , "'cdannewitz@uni-paderborn.de'" , "'philliph@comodo.com'" Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 13:35:22 -0000 Rich, yes, I agree that we should decide that. Our recommendation would be to do the base spec in DECADE. Best regards, Dirk > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Mittwoch, 26. Oktober 2011 15:22 > To: Dirk Kutscher; 'decade@ietf.org' > Cc: 'cdannewitz@uni-paderborn.de'; 'rob.stradling@comodo.com'; > 'philliph@comodo.com'; Woundy, Richard > Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme >=20 > Now that we have established that websec and decade are at least > interested in the named information uri scheme, do we know what group is > expected to own the base specification? That might be a good topic to > discuss with the relevant ADs in email now and at IETF 82 in person (app = and > tsv at least). >=20 > ----- Original Message ----- > From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu] > Sent: Wednesday, October 26, 2011 09:06 AM > To: decade ietf > Cc: Christian Dannewitz (cdannewitz@uni-paderborn.de) paderborn.de>; Rob Stradling (rob.stradling@comodo.com) > ; philliph@comodo.com > > Subject: [decade] URIs for DECADE -- Named Information URI Scheme >=20 > Dear all, >=20 > We have updated the Named Information URI scheme that we presented at > IETF-81. >=20 > It turned out that the WEBSEC folks (Phillip Hallam-Baker and colleagues)= had > started a parallel effort on a very similar approach, and -- fortunately = -- we > have been able to combine our efforts and have advanced the spec so that = it > would be useful for DECADE, WEBSEC and potentially other applications. >=20 > We still think that DECADE could benefit most at this time, so we submitt= ed > this (as an individual submission) to DECADE now. >=20 > We found a, IMO, nice way to have a concise base specification without > excluding extensions for future application requirements. Basically, ther= e is > an extension mechanism that allows applications to specify additional > parameters. >=20 > To make this manageable, we have split the specification into two pieces: >=20 > The base spec: >=20 > http://tools.ietf.org/html/draft-farrell-decade-ni-00 >=20 > This document defines a URI-based name form that identifies a named > object via hash-based binding. The URI name form defined is intended fo= r > use in applications that need to uniquely identify resources in a locati= on- > independent way such as accessing in-network storage (DECADE), > information-centric networking and more generally. The format is designe= d > to support a strong link to the referenced object such that the referenc= ed > object may be authenticated to the same degree as the reference to it. >=20 > The base spec has a set of useful general features (in addition to the ac= tual > syntax definition), such as processing rules (testing for equality), and = an > algorithm that can be used to map NI URIs to HTTP(S) automatically -- whi= ch I > believe could be useful for DECADE, too. The base spec also defines the > fundamentals of the extension mechanism. >=20 >=20 > A spec that defines a set of extension parameters and their semantics: >=20 > http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 > This document specifies some optional algorithms and parameters that may > be used in the query string of ni URIs. >=20 > One of the parameters that we have introduced here would allow you to > specify additional locators for resources -- again, that is expected to b= e useful > for DECADE. >=20 > Looking forward, we envision that DECADE protocols may need additional > parameters. Investigating this and specifying the parameters could be don= e > in DECADE (should we decide to re-charter for that). >=20 > Please note that these two are individual submissions only -- i.e., merel= y > proposals that the group of authors are offering at this point. >=20 > Nevertheless, we would be happy for any feedback. >=20 > Best regards, >=20 > Dirk >=20 >=20 >=20 >=20 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From hallam@gmail.com Wed Oct 26 07:03:49 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A4121F8906; Wed, 26 Oct 2011 07:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kh43hGJ45nOz; Wed, 26 Oct 2011 07:03:48 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55EDA21F87C2; Wed, 26 Oct 2011 07:03:48 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1743810vcb.31 for ; Wed, 26 Oct 2011 07:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JHSSZAjJ7eHZuvjMs+p5uRopCY2J9Rc0Oa41oPS18dU=; b=ZPSijw12Z6PsckxvlbI/0XD1yeq64K+3DGJ8InXB8U8Wx1iONvWrzkXOSLcHkL+w0x cUNybyHAKwn4T7RrtoaMmWeDL2kD4r2G0eUzRwnHGsd3SRiUy5EN0sZrwhakw9o+YIrf 92KKZuyMI7csZFzlJQscx72van0mjyRgD6MkU= MIME-Version: 1.0 Received: by 10.182.49.1 with SMTP id q1mr1083603obn.48.1319637827478; Wed, 26 Oct 2011 07:03:47 -0700 (PDT) Received: by 10.182.42.99 with HTTP; Wed, 26 Oct 2011 07:03:47 -0700 (PDT) In-Reply-To: <82AB329A76E2484D934BBCA77E9F524924B74434@PALLENE.office.hd> References: <82AB329A76E2484D934BBCA77E9F524924B74297@PALLENE.office.hd> <1CA25301D2219F40B3AA37201F0EACD1136C0EEC@PACDCEXMB05.cable.comcast.com> <82AB329A76E2484D934BBCA77E9F524924B74434@PALLENE.office.hd> Date: Wed, 26 Oct 2011 10:03:47 -0400 Message-ID: From: Phillip Hallam-Baker To: Dirk Kutscher , websec Content-Type: multipart/alternative; boundary=f46d0447850bf0640504b0341f82 Cc: "decade@ietf.org" , "cdannewitz@uni-paderborn.de" , "rob.stradling@comodo.com" , "philliph@comodo.com" Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 14:03:50 -0000 --f46d0447850bf0640504b0341f82 Content-Type: text/plain; charset=ISO-8859-1 I think that is the best approach as well. The WebSec use is purely to create a strong reference. I think that if we can get convergence on the core spec quickly, the WebSec use should be orthogonal. The aim here is merely to ensure that we end up with one mechanism for specifying digests of referenced objects rather than having slightly different versions in different groups. There are many interesting things that can be done with digest URIs. Some of which will probably solve problems WebSEC faces. But DECADE is clearly the best place to discuss those at the moment. All that WebSEC will be using for the time being is the ability to refer to securely a blob of security policy related data in a fashion that packages all the crypto gubbins into one string of text. DECADE is rather different because it is in effect describing a new and very different form of URL. A traditional URL is a procedural content link, the content is defined by the means of retrieval. An ni URI is also a locator in that it MAY give one (or more) means of locating the data. But the data itself is specified in a functional style. Any method of function evaluation that produces the expected result is equally valid (but not necessarily equally efficient). I do have some proposals for using the digest URI that maybe fall outside both WG charters. This is a notary technology that I think we need. But this is something that simply has to be built on top of DECADE so that it can have the acronym DECADE-Notary Technology, or DECADENT. On Wed, Oct 26, 2011 at 9:34 AM, Dirk Kutscher wrote: > Rich, > > yes, I agree that we should decide that. > > Our recommendation would be to do the base spec in DECADE. > > Best regards, > > Dirk > > > > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Mittwoch, 26. Oktober 2011 15:22 > > To: Dirk Kutscher; 'decade@ietf.org' > > Cc: 'cdannewitz@uni-paderborn.de'; 'rob.stradling@comodo.com'; > > 'philliph@comodo.com'; Woundy, Richard > > Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme > > > > Now that we have established that websec and decade are at least > > interested in the named information uri scheme, do we know what group is > > expected to own the base specification? That might be a good topic to > > discuss with the relevant ADs in email now and at IETF 82 in person (app > and > > tsv at least). > > > > ----- Original Message ----- > > From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu] > > Sent: Wednesday, October 26, 2011 09:06 AM > > To: decade ietf > > Cc: Christian Dannewitz (cdannewitz@uni-paderborn.de) > > paderborn.de>; Rob Stradling (rob.stradling@comodo.com) > > ; philliph@comodo.com > > > > Subject: [decade] URIs for DECADE -- Named Information URI Scheme > > > > Dear all, > > > > We have updated the Named Information URI scheme that we presented at > > IETF-81. > > > > It turned out that the WEBSEC folks (Phillip Hallam-Baker and colleagues) > had > > started a parallel effort on a very similar approach, and -- fortunately > -- we > > have been able to combine our efforts and have advanced the spec so that > it > > would be useful for DECADE, WEBSEC and potentially other applications. > > > > We still think that DECADE could benefit most at this time, so we > submitted > > this (as an individual submission) to DECADE now. > > > > We found a, IMO, nice way to have a concise base specification without > > excluding extensions for future application requirements. Basically, > there is > > an extension mechanism that allows applications to specify additional > > parameters. > > > > To make this manageable, we have split the specification into two pieces: > > > > The base spec: > > > > http://tools.ietf.org/html/draft-farrell-decade-ni-00 > > > > This document defines a URI-based name form that identifies a named > > object via hash-based binding. The URI name form defined is intended > for > > use in applications that need to uniquely identify resources in a > location- > > independent way such as accessing in-network storage (DECADE), > > information-centric networking and more generally. The format is > designed > > to support a strong link to the referenced object such that the > referenced > > object may be authenticated to the same degree as the reference to it. > > > > The base spec has a set of useful general features (in addition to the > actual > > syntax definition), such as processing rules (testing for equality), and > an > > algorithm that can be used to map NI URIs to HTTP(S) automatically -- > which I > > believe could be useful for DECADE, too. The base spec also defines the > > fundamentals of the extension mechanism. > > > > > > A spec that defines a set of extension parameters and their semantics: > > > > http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 > > This document specifies some optional algorithms and parameters that may > > be used in the query string of ni URIs. > > > > One of the parameters that we have introduced here would allow you to > > specify additional locators for resources -- again, that is expected to > be useful > > for DECADE. > > > > Looking forward, we envision that DECADE protocols may need additional > > parameters. Investigating this and specifying the parameters could be > done > > in DECADE (should we decide to re-charter for that). > > > > Please note that these two are individual submissions only -- i.e., > merely > > proposals that the group of authors are offering at this point. > > > > Nevertheless, we would be happy for any feedback. > > > > Best regards, > > > > Dirk > > > > > > > > > > _______________________________________________ > > 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 > -- Website: http://hallambaker.com/ --f46d0447850bf0640504b0341f82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that is the best approach as well.

The WebSec us= e is purely to create a strong reference. I think that if we can get conver= gence on the core spec quickly, the WebSec use should be orthogonal.

The aim here is merely to ensure that we end up with on= e mechanism for specifying digests of referenced objects rather than having= slightly different versions in different groups.


There are many interesting things that can be done with dige= st URIs. Some of which will probably solve problems WebSEC faces. But DECAD= E is clearly the best place to discuss those at the moment.

All that WebSEC will be using for the time being is the ability = to refer to securely a blob of security policy related data in a fashion th= at packages all the crypto gubbins into one string of text.

DECADE is rather different because it is in effect describing a = new and very different form of URL. A traditional URL is a procedural conte= nt link, the content is defined by the means of retrieval. An ni URI is als= o a locator in that it MAY give one (or more) means of locating the data. B= ut the data itself is specified in a functional style. Any method of functi= on evaluation that produces the expected result is equally valid (but not n= ecessarily equally efficient).


I do have some proposals for using the d= igest URI that maybe fall outside both WG charters. This is a notary techno= logy that I think we need. But this is something that simply has to be buil= t on top of DECADE so that it can have the acronym DECADE-Notary Technology= , or DECADENT.

On Wed, Oct 26, 2011 at 9:34 AM, Dirk K= utscher <Di= rk.Kutscher@neclab.eu> wrote:
Rich,

yes, I agree that we should decide that.

Our recommendation would be to do the base spec in DECADE.

Best regards,

Dirk




> -----Original Message-----
> From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
> Sent: Mittwoch, 26. Oktober 2011 15:22
> To: Dirk Kutscher; 'decade@ietf= .org'
> Cc: 'cdannewitz@uni= -paderborn.de'; 'ro= b.stradling@comodo.com';
> 'philliph@comodo.com= 9;; Woundy, Richard
> Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme<= br>
>
> Now that we have established that websec and decade are at least
> interested in the named information uri scheme, do we know what group = is
> expected to own the base specification? That might be a good topic to<= br> > discuss with the relevant ADs in email now and at IETF 82 in person (a= pp and
> tsv at least).
>
> ----- Original Message -----
> From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu]
> Sent: Wednesday, October 26, 2011 09:06 AM
> To: decade ietf <decade@ietf.org= >
> Cc: Christian Dannewitz =A0 =A0 =A0 (cdannewitz@uni-paderborn.de) <cdannewitz@uni-
> paderborn.de>= ; Rob Stradling (rob.stradling@= comodo.com)
> <rob.stradling@comodo.c= om>; philliph@comodo.com<= br> > <philliph@comodo.com>=
> Subject: [decade] URIs for DECADE -- Named Information URI Scheme
>
> Dear all,
>
> We have updated the Named Information URI scheme that we presented at<= br> > IETF-81.
>
> It turned out that the WEBSEC folks (Phillip Hallam-Baker and colleagu= es) had
> started a parallel effort on a very similar approach, and -- fortunate= ly -- we
> have been able to combine our efforts and have advanced the spec so th= at it
> would be useful for DECADE, WEBSEC and potentially other applications.=
>
> We still think that DECADE could benefit most at this time, so we subm= itted
> this (as an individual submission) to DECADE now.
>
> We found a, IMO, nice way to have a concise base specification without=
> excluding extensions for future application requirements. Basically, t= here is
> an extension mechanism that allows applications to specify additional<= br> > parameters.
>
> To make this manageable, we have split the specification into two piec= es:
>
> The base spec:
>
> http://tools.ietf.org/html/draft-farrell-decade-ni-00
>
> This document defines a URI-based name form that identifies a named > object via hash-based binding. =A0The URI name form defined is intende= d =A0for
> use in applications that need to uniquely identify resources in a =A0l= ocation-
> independent way such as accessing in-network storage =A0(DECADE),
> information-centric networking and more generally. =A0The format is de= signed
> to support a strong link to the referenced object =A0such that the ref= erenced
> object may be authenticated to the same =A0degree as the reference to = it.
>
> The base spec has a set of useful general features (in addition to the= actual
> syntax definition), such as processing rules (testing for equality), a= nd an
> algorithm that can be used to map NI URIs to HTTP(S) automatically -- = which I
> believe could be useful for DECADE, too. The base spec also defines th= e
> fundamentals of the extension mechanism.
>
>
> A spec that defines a set of extension parameters and their semantics:=
>
> http://tools.ietf.org/html/draft-hallambaker-decad= e-ni-params-00
> This document specifies some optional algorithms and parameters that m= ay
> be used in the query string of ni URIs.
>
> One of the parameters that we have introduced here would allow you to<= br> > specify additional locators for resources -- again, that is expected t= o be useful
> for DECADE.
>
> Looking forward, we envision that DECADE protocols may need additional=
> parameters. Investigating this and specifying the parameters could be = done
> in DECADE (should we decide to re-charter for that).
>
> Please note that these two are individual submissions only -- i.e., me= rely
> proposals that the group of authors are offering at this point.
>
> Nevertheless, we would be happy for any feedback.
>
> Best regards,
>
> Dirk
>
>
>
>
> _______________________________________________
> 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



--
= Website: http://hallambaker.com/
--f46d0447850bf0640504b0341f82-- From yry@cs.yale.edu Wed Oct 26 21:04:41 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1522321F8AFB for ; Wed, 26 Oct 2011 21:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlDPIaN3IyvA for ; Wed, 26 Oct 2011 21:04:40 -0700 (PDT) Received: from vm-emlprdomr-05.its.yale.edu (vm-emlprdomr-05.its.yale.edu [130.132.50.146]) by ietfa.amsl.com (Postfix) with ESMTP id F22DD21F863E for ; Wed, 26 Oct 2011 21:04:39 -0700 (PDT) Received: from [10.0.0.3] (adsl-71-139-148-18.dsl.mrdnct.sbcglobal.net [71.139.148.18]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id p9R44Ggp013466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 27 Oct 2011 00:04:16 -0400 References: <82AB329A76E2484D934BBCA77E9F524924B74297@PALLENE.office.hd> <1CA25301D2219F40B3AA37201F0EACD1136C0EEC@PACDCEXMB05.cable.comcast.com> <82AB329A76E2484D934BBCA77E9F524924B74434@PALLENE.office.hd> In-Reply-To: <82AB329A76E2484D934BBCA77E9F524924B74434@PALLENE.office.hd> Mime-Version: 1.0 (iPad Mail 8J3) Content-Type: text/plain; charset=us-ascii Message-Id: <9487D8D7-2582-4B3B-83C4-FF14FEE2FE6E@cs.yale.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8J3) From: "Y. R. Yang" Date: Thu, 27 Oct 2011 00:06:06 -0400 To: Dirk Kutscher X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146 Cc: "decade@ietf.org" , "cdannewitz@uni-paderborn.de" , "rob.stradling@comodo.com" , "philliph@comodo.com" Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 04:04:41 -0000 Hi Dirk, Very interesting scheme! I definitely can see the high relevance in DECADE. Two understanding questions: - Is there a context for your scheme, i.e., a kind of "related work" paragra= ph so that others can read more and contrast? - Is it possible to provide an example with a non-empty query string? Thanks a lot! Richard On Oct 26, 2011, at 9:34 AM, Dirk Kutscher wrote: > Rich, >=20 > yes, I agree that we should decide that. >=20 > Our recommendation would be to do the base spec in DECADE. >=20 > Best regards, >=20 > Dirk >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] >> Sent: Mittwoch, 26. Oktober 2011 15:22 >> To: Dirk Kutscher; 'decade@ietf.org' >> Cc: 'cdannewitz@uni-paderborn.de'; 'rob.stradling@comodo.com'; >> 'philliph@comodo.com'; Woundy, Richard >> Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme >>=20 >> Now that we have established that websec and decade are at least >> interested in the named information uri scheme, do we know what group is >> expected to own the base specification? That might be a good topic to >> discuss with the relevant ADs in email now and at IETF 82 in person (app a= nd >> tsv at least). >>=20 >> ----- Original Message ----- >> From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu] >> Sent: Wednesday, October 26, 2011 09:06 AM >> To: decade ietf >> Cc: Christian Dannewitz (cdannewitz@uni-paderborn.de) > paderborn.de>; Rob Stradling (rob.stradling@comodo.com) >> ; philliph@comodo.com >> >> Subject: [decade] URIs for DECADE -- Named Information URI Scheme >>=20 >> Dear all, >>=20 >> We have updated the Named Information URI scheme that we presented at >> IETF-81. >>=20 >> It turned out that the WEBSEC folks (Phillip Hallam-Baker and colleagues)= had >> started a parallel effort on a very similar approach, and -- fortunately -= - we >> have been able to combine our efforts and have advanced the spec so that i= t >> would be useful for DECADE, WEBSEC and potentially other applications. >>=20 >> We still think that DECADE could benefit most at this time, so we submitt= ed >> this (as an individual submission) to DECADE now. >>=20 >> We found a, IMO, nice way to have a concise base specification without >> excluding extensions for future application requirements. Basically, ther= e is >> an extension mechanism that allows applications to specify additional >> parameters. >>=20 >> To make this manageable, we have split the specification into two pieces:= >>=20 >> The base spec: >>=20 >> http://tools.ietf.org/html/draft-farrell-decade-ni-00 >>=20 >> This document defines a URI-based name form that identifies a named >> object via hash-based binding. The URI name form defined is intended fo= r >> use in applications that need to uniquely identify resources in a locati= on- >> independent way such as accessing in-network storage (DECADE), >> information-centric networking and more generally. The format is designe= d >> to support a strong link to the referenced object such that the referenc= ed >> object may be authenticated to the same degree as the reference to it. >>=20 >> The base spec has a set of useful general features (in addition to the ac= tual >> syntax definition), such as processing rules (testing for equality), and a= n >> algorithm that can be used to map NI URIs to HTTP(S) automatically -- whi= ch I >> believe could be useful for DECADE, too. The base spec also defines the >> fundamentals of the extension mechanism. >>=20 >>=20 >> A spec that defines a set of extension parameters and their semantics: >>=20 >> http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 >> This document specifies some optional algorithms and parameters that may >> be used in the query string of ni URIs. >>=20 >> One of the parameters that we have introduced here would allow you to >> specify additional locators for resources -- again, that is expected to b= e useful >> for DECADE. >>=20 >> Looking forward, we envision that DECADE protocols may need additional >> parameters. Investigating this and specifying the parameters could be don= e >> in DECADE (should we decide to re-charter for that). >>=20 >> Please note that these two are individual submissions only -- i.e., merel= y >> proposals that the group of authors are offering at this point. >>=20 >> Nevertheless, we would be happy for any feedback. >>=20 >> Best regards, >>=20 >> Dirk >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 Dirk.Kutscher@neclab.eu Thu Oct 27 02:13:10 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E5B21F86AA for ; Thu, 27 Oct 2011 02:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGLnxan38TPc for ; Thu, 27 Oct 2011 02:13:09 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8516F21F8906 for ; Thu, 27 Oct 2011 02:13:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 33494280000FA; Thu, 27 Oct 2011 11:13:35 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3b07yProw-6; Thu, 27 Oct 2011 11:13:35 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 1129B28000080; Thu, 27 Oct 2011 11:13:05 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.17]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 27 Oct 2011 11:12:17 +0200 From: Dirk Kutscher To: "Y. R. Yang" Thread-Topic: [decade] URIs for DECADE -- Named Information URI Scheme Thread-Index: AcyT3Q1fSKP8TWxrSb+hOZRj/UgXMwABTywUAABQgHAAGlwWAAAOSwPg Date: Thu, 27 Oct 2011 09:12:17 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524924B75A98@PALLENE.office.hd> References: <82AB329A76E2484D934BBCA77E9F524924B74297@PALLENE.office.hd> <1CA25301D2219F40B3AA37201F0EACD1136C0EEC@PACDCEXMB05.cable.comcast.com> <82AB329A76E2484D934BBCA77E9F524924B74434@PALLENE.office.hd> <9487D8D7-2582-4B3B-83C4-FF14FEE2FE6E@cs.yale.edu> In-Reply-To: <9487D8D7-2582-4B3B-83C4-FF14FEE2FE6E@cs.yale.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "decade@ietf.org" , "cdannewitz@uni-paderborn.de" , "rob.stradling@comodo.com" , "philliph@comodo.com" Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 09:13:11 -0000 Hi Richard, Thanks for the feedback. I am sure there is some context that could be mentioned, i.e., URNs, DOIs f= rom the URI world. This would be related, but is not quite the same. URNs, for instance are in= tended for managed namespace, while we are looking for a solution where pub= lishers can name their resources independently -- through content hashing. Using content hashes as identifiers is of course done elsewhere, too. There is the MAGNET URI scheme: http://magnet-uri.sourceforge.net/ This one does things a bit differently -- we think that the NI scheme has s= ome advantages in really focusing on URIs for named resources, while still = providing enough flexibility to support different applications. I guess the= main point is that there should be one standardized approach -- that's has= been missing so far. Since this is a spec, we did not want to include too much side information.= We could do it, but I personally think that would be better for a paper or= so... Regarding non-empty query string example -- the ni-params draft (http://too= ls.ietf.org/html/draft-hallambaker-decade-ni-params-00) has a few of those.= Or are looking for something else? Best regards, Dirk > -----Original Message----- > From: Y. R. Yang [mailto:yry@cs.yale.edu] > Sent: Donnerstag, 27. Oktober 2011 06:06 > To: Dirk Kutscher > Cc: Woundy, Richard; decade@ietf.org; rob.stradling@comodo.com; > cdannewitz@uni-paderborn.de; philliph@comodo.com > Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme >=20 > Hi Dirk, >=20 > Very interesting scheme! I definitely can see the high relevance in DECAD= E. >=20 > Two understanding questions: >=20 > - Is there a context for your scheme, i.e., a kind of "related work" para= graph > so that others can read more and contrast? >=20 > - Is it possible to provide an example with a non-empty query string? >=20 > Thanks a lot! >=20 > Richard >=20 > On Oct 26, 2011, at 9:34 AM, Dirk Kutscher > wrote: >=20 > > Rich, > > > > yes, I agree that we should decide that. > > > > Our recommendation would be to do the base spec in DECADE. > > > > Best regards, > > > > Dirk > > > > > > > > > >> -----Original Message----- > >> From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > >> Sent: Mittwoch, 26. Oktober 2011 15:22 > >> To: Dirk Kutscher; 'decade@ietf.org' > >> Cc: 'cdannewitz@uni-paderborn.de'; 'rob.stradling@comodo.com'; > >> 'philliph@comodo.com'; Woundy, Richard > >> Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme > >> > >> Now that we have established that websec and decade are at least > >> interested in the named information uri scheme, do we know what group > >> is expected to own the base specification? That might be a good topic > >> to discuss with the relevant ADs in email now and at IETF 82 in > >> person (app and tsv at least). > >> > >> ----- Original Message ----- > >> From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu] > >> Sent: Wednesday, October 26, 2011 09:06 AM > >> To: decade ietf > >> Cc: Christian Dannewitz (cdannewitz@uni-paderborn.de) > >> paderborn.de>; Rob Stradling (rob.stradling@comodo.com) > >> ; philliph@comodo.com > > >> Subject: [decade] URIs for DECADE -- Named Information URI Scheme > >> > >> Dear all, > >> > >> We have updated the Named Information URI scheme that we presented > at > >> IETF-81. > >> > >> It turned out that the WEBSEC folks (Phillip Hallam-Baker and > >> colleagues) had started a parallel effort on a very similar approach, > >> and -- fortunately -- we have been able to combine our efforts and > >> have advanced the spec so that it would be useful for DECADE, WEBSEC > and potentially other applications. > >> > >> We still think that DECADE could benefit most at this time, so we > >> submitted this (as an individual submission) to DECADE now. > >> > >> We found a, IMO, nice way to have a concise base specification > >> without excluding extensions for future application requirements. > >> Basically, there is an extension mechanism that allows applications > >> to specify additional parameters. > >> > >> To make this manageable, we have split the specification into two piec= es: > >> > >> The base spec: > >> > >> http://tools.ietf.org/html/draft-farrell-decade-ni-00 > >> > >> This document defines a URI-based name form that identifies a named > >> object via hash-based binding. The URI name form defined is intended > >> for use in applications that need to uniquely identify resources in a > >> location- independent way such as accessing in-network storage > >> (DECADE), information-centric networking and more generally. The > >> format is designed to support a strong link to the referenced object > >> such that the referenced object may be authenticated to the same > degree as the reference to it. > >> > >> The base spec has a set of useful general features (in addition to > >> the actual syntax definition), such as processing rules (testing for > >> equality), and an algorithm that can be used to map NI URIs to > >> HTTP(S) automatically -- which I believe could be useful for DECADE, > >> too. The base spec also defines the fundamentals of the extension > mechanism. > >> > >> > >> A spec that defines a set of extension parameters and their semantics: > >> > >> http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 > >> This document specifies some optional algorithms and parameters that > >> may be used in the query string of ni URIs. > >> > >> One of the parameters that we have introduced here would allow you to > >> specify additional locators for resources -- again, that is expected > >> to be useful for DECADE. > >> > >> Looking forward, we envision that DECADE protocols may need > >> additional parameters. Investigating this and specifying the > >> parameters could be done in DECADE (should we decide to re-charter for > that). > >> > >> Please note that these two are individual submissions only -- i.e., > >> merely proposals that the group of authors are offering at this point. > >> > >> Nevertheless, we would be happy for any feedback. > >> > >> Best regards, > >> > >> Dirk > >> > >> > >> > >> > >> _______________________________________________ > >> 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_woundy@cable.comcast.com Fri Oct 28 09:35:17 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD421F8663 for ; Fri, 28 Oct 2011 09:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.302 X-Spam-Level: X-Spam-Status: No, score=-103.302 tagged_above=-999 required=5 tests=[AWL=-1.795, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgLpgG2126f7 for ; Fri, 28 Oct 2011 09:35:16 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id DA0ED21F85F7 for ; Fri, 28 Oct 2011 09:35:15 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.59152579; Fri, 28 Oct 2011 10:42:54 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0339.001; Fri, 28 Oct 2011 12:35:06 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-decade-reqs-04 Thread-Index: Acu+91Byr8CuZlwMSYaaxFnqkg41Dy/qW7BQAl+qvvADW+g6gA== Date: Fri, 28 Oct 2011 16:35:06 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136D11D4@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136A2790@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136A2790@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1136D11D4PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 16:35:17 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1136D11D4PACDCEXMB05cabl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like to move forward with draft-ietf-decade-reqs-04, and incorporat= e the comments received from WGLC. Many thanks to Akbar Rahman, B=F6rje Ohl= man, and Haibin Song for their comments on the draft! Authors, please note that the submission deadline is Monday October 31 at 1= 7:00 PT (00:00 UTC). Let's post a -05 version if at all possible for discus= sion at IETF 82 in Taipei. -- Rich P.S. Let's also remember to fix "Boerje Ohlman" in the Acknowledgments sect= ion. From: Woundy, Richard Sent: Tuesday, October 11, 2011 10:19 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: RE: Start of WGLC for draft-ietf-decade-reqs-04 Just a reminder that the WGLC for the DECADE requirements draft (draft-ietf= -decade-reqs-04) ends next Monday October 17. If you think the document is ready to move forward, please state this on th= e list by Monday and not just silently agree. It would also help if our WG expert reviewers (Dave McDysan, Akbar Rahman, = and Borje Ohlman) would confirm that their draft comments were addressed in= this version by Monday. -- Rich From: Woundy, Richard Sent: Thursday, September 29, 2011 8:13 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-reqs-04 Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -reqs-04, http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be co= mpleted by Monday October 17. Please send all concerns, suggestions and com= ments about this internet-draft to the DECADE mailing list, decade@ietf.org= . Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD1136D11D4PACDCEXMB05cabl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I would like to move f= orward with draft-ietf-decade-reqs-04, and incorporate the comments receive= d from WGLC. Many thanks to Akbar Rahman, B=F6rje Ohlman, and Haibin Song f= or their comments on the draft!

 

Authors, please note t= hat the submission deadline is Monday October 31 at 17:00 PT (00:00 UTC). Let’s post a -05 version if at all = possible for discussion at IETF 82 in Taipei.

 

-- Rich

 

P.S. Let’s also remember to fix “” in the Acknowledgm=
ents section.

 

From: Woundy, = Richard
Sent: Tuesday, October 11, 2011 10:19 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: RE: Start of WGLC for draft-ietf-decade-reqs-04<= /span>

 

Just a reminder that t= he WGLC for the DECADE requirements draft (draft-ietf-decade-reqs-04) ends = next Monday October 17.

 

If you think the docum= ent is ready to move forward, please state this on the list by Monday and n= ot just silently agree.

 

It would also help if = our WG expert reviewers (Dave McDysan, Akbar Rahman, and Borje Ohlman) woul= d confirm that their draft comments were addressed in this version by Monda= y.

 

-- Rich

 

From: Woundy, = Richard
Sent: Thursday, September 29, 2011 8:13 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-reqs-04

 

Folks,

 

Haibin and I are start= ing the working group last call for draft-ietf-decade-reqs-04, http://= datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by Mo= nday October 17. Please send all concerns, suggestions and comments about t= his internet-draft to the DECADE mailing list, decade@ietf.org.

 

Authors, please do not= make any additional changes to the internet-draft unless directed by the W= G chairs.

 

Draft reviewers, it wo= uld be helpful to get your confirmation that your previous review comments = have been correctly reflected in this version.

 

Thanks.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD1136D11D4PACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Fri Oct 28 09:45:03 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B56121F89B8 for ; Fri, 28 Oct 2011 09:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.181 X-Spam-Level: X-Spam-Status: No, score=-106.181 tagged_above=-999 required=5 tests=[AWL=2.280, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+ut06qSs6ky for ; Fri, 28 Oct 2011 09:45:01 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA3121F893C for ; Fri, 28 Oct 2011 09:45:01 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.144538173; Fri, 28 Oct 2011 12:44:27 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Fri, 28 Oct 2011 12:44:27 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-decade-arch-03 Thread-Index: AQHMfqFCTxqrA0OtdEywpt6h+qbSY5V3iDTAgBqV8hA= Date: Fri, 28 Oct 2011 16:44:27 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136D1235@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136A27A8@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136A27A8@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1136D1235PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 16:45:03 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1136D1235PACDCEXMB05cabl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like to move forward with draft-ietf-decade-arch-03, and incorporat= e the comments received from WGLC. Many thanks to B=F6rje Ohlman, Dave McDy= san, and Ning Zong for their comments on the draft! Authors, please note that the submission deadline is Monday October 31 at 1= 7:00 PT (00:00 UTC). Let's post a -04 version if at all possible for discus= sion at IETF 82 in Taipei. -- Rich P.S. The authors might want to add an Acknowledgments section. :) From: Woundy, Richard Sent: Tuesday, October 11, 2011 10:22 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: RE: Start of WGLC for draft-ietf-decade-arch-03 Just a reminder that the WGLC for the DECADE architecture draft (draft-ietf= -decade-arch-03) ends next Monday October 17. If you think the document is ready to move forward, please state this on th= e list by Monday and not just silently agree. It would also help if our WG expert reviewers (Martin Stiemerling, David Mc= Dysan, and Borje Ohlman) would confirm that their draft comments were addre= ssed in this version by Monday. -- Rich From: Woundy, Richard Sent: Thursday, September 29, 2011 8:14 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-arch-03 Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -arch-03, http://datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be co= mpleted by Monday October 17. Please send all concerns, suggestions and com= ments about this internet-draft to the DECADE mailing list, decade@ietf.org= . Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD1136D1235PACDCEXMB05cabl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I would like to move f= orward with draft-ietf-decade-arch-03, and incorporate the comments received = from WGLC. Many thanks to B=F6rje Ohlman, Dave McDysan, and Ning Zong for t= heir comments on the draft!

 

Authors, please note t= hat the submission deadline is Monday October 31 at 17:00 PT = (00:00 UTC). Let’s post a -04 version if at all possible for discussi= on at IETF 82 in Taipei.

 

-- Rich

 

P.S. The authors might= want to add an Acknowledgments section. J

 

From: Woundy, = Richard
Sent: Tuesday, October 11, 2011 10:22 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: RE: Start of WGLC for draft-ietf-decade-arch-03<= /span>

 

Just a reminder that t= he WGLC for the DECADE architecture draft (draft-ietf-decade-arch-03) ends = next Monday October 17.

 

If you think the docum= ent is ready to move forward, please state this on the list by Monday and n= ot just silently agree.

 

It would also help if = our WG expert reviewers (Martin Stiemerling, David McDysan, and Borje Ohlma= n) would confirm that their draft comments were addressed in this version b= y Monday.

 

-- Rich

 

From: Woundy, = Richard
Sent: Thursday, September 29, 2011 8:14 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-arch-03

 

Folks,

 

Haibin and I are start= ing the working group last call for draft-ietf-decade-arch-03, http://= datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be completed by Mo= nday October 17. Please send all concerns, suggestions and comments about t= his internet-draft to the DECADE mailing list, decade@ietf.org.

 

Authors, please do not= make any additional changes to the internet-draft unless directed by the W= G chairs.

 

Draft reviewers, it wo= uld be helpful to get your confirmation that your previous review comments = have been correctly reflected in this version.

 

Thanks.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD1136D1235PACDCEXMB05cabl_-- From yry@cs.yale.edu Fri Oct 28 19:48:13 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C0C21F84B9 for ; Fri, 28 Oct 2011 19:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Olv+DZ5Eb48k for ; Fri, 28 Oct 2011 19:48:13 -0700 (PDT) Received: from vm-emlprdomr-06.its.yale.edu (vm-emlprdomr-06.its.yale.edu [130.132.50.147]) by ietfa.amsl.com (Postfix) with ESMTP id D330021F84B8 for ; Fri, 28 Oct 2011 19:48:11 -0700 (PDT) Received: from dhcp-128-36-169-23.central.yale.edu (dhcp-128-36-169-23.central.yale.edu [128.36.169.23]) (authenticated bits=0) by vm-emlprdomr-06.its.yale.edu (8.14.4/8.14.4) with ESMTP id p9T2lxRB001061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Oct 2011 22:48:00 -0400 Message-ID: <4EAB695F.3060809@cs.yale.edu> Date: Fri, 28 Oct 2011 22:47:59 -0400 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: RFC Errata System References: <20111026074349.0F64198C245@rfc-editor.org> In-Reply-To: <20111026074349.0F64198C245@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.71 on 130.132.50.147 Cc: decade@ietf.org, bortzmeyer+rfceditor@nic.fr, ralimi@google.com Subject: Re: [decade] [Technical Errata Reported] RFC6392 (3006) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 02:48:13 -0000 Dear Stéphane Bortzmeyer, As a co-editor, I checked the related documents referred to by your report. I agree with your proposed change: Section: 5.1.2 Original Text ------------- Not provided. Corrected Text -------------- Basic deletion of resources is provided with the DELETE method. It is an excellent catch. Thanks a lot! Richard On 10/26/11 3:43 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC6392, > "A Survey of In-Network Storage Systems". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6392&eid=3006 > > -------------------------------------- > Type: Technical > Reported by: Stéphane Bortzmeyer > > Section: 5.1.2 > > Original Text > ------------- > Not provided. > > Corrected Text > -------------- > Basic deletion of resources is provided with the DELETE method. > > Notes > ----- > The typical "data management operation" mentioned for other protocols is the deletion of data. HTTP has it from the beginning (Section 9.7 of RFC 2616). > > Apache does not support it directly, you apparently have to provide a module which does it (mod_dav does it, even if DELETE is not a WebDAV method). Anyway, this section is about the abilities of the protocol, not of implementations. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6392 (draft-ietf-decade-survey-06) > -------------------------------------- > Title : A Survey of In-Network Storage Systems > Publication Date : October 2011 > Author(s) : R. Alimi, Ed., A. Rahman, Ed., Y. Yang, Ed. > Category : INFORMATIONAL > Source : Decoupled Application Data Enroute > Area : Transport > Stream : IETF > Verifying Party : IESG From ralimi@google.com Sat Oct 29 00:18:16 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C593221F8514 for ; Sat, 29 Oct 2011 00:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmiqWPt52y59 for ; Sat, 29 Oct 2011 00:18:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id DA58D21F8509 for ; Sat, 29 Oct 2011 00:18:15 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p9T7IDiI011260 for ; Sat, 29 Oct 2011 00:18:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319872694; bh=J9LC2u/+mZfJJVR/XSRax2laA9M=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=yYIWyFqulwr38+zYxykdf1NtFFViy3DzkyYEuc9ub2VamXx0o7zcPRlqcwr34bIq1 mxexvBympeFTtTKsoexWA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=Vh7JJZgIzKyo4AC8L1IFDaS++gLXRsuj9VP4Ao3u5u/3siMsuPDD5gIVevq9MKIqb JJvjbRSyHTcHLJZFnt1DA== Received: from vcbfk14 (vcbfk14.prod.google.com [10.220.204.14]) by hpaq2.eem.corp.google.com with ESMTP id p9T7IBME022895 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 29 Oct 2011 00:18:12 -0700 Received: by vcbfk14 with SMTP id fk14so7219475vcb.6 for ; Sat, 29 Oct 2011 00:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=d12GhnghyXChj5CjB9B5e2Gd45fREVj7f3XqaHzSzk4=; b=T64KLhTTuH8hRMKsjDAjjPqJ9D7G2i0AV3U/Fmi0IMWdGqRn8+KAweWxlbKwcfpgjY rCANdeZnM1ukSpZrlCqA== Received: by 10.229.74.79 with SMTP id t15mr1410294qcj.153.1319872691463; Sat, 29 Oct 2011 00:18:11 -0700 (PDT) Received: by 10.229.74.79 with SMTP id t15mr1410263qcj.153.1319872689569; Sat, 29 Oct 2011 00:18:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.53.146 with HTTP; Sat, 29 Oct 2011 00:17:38 -0700 (PDT) In-Reply-To: <4EAB695F.3060809@cs.yale.edu> References: <20111026074349.0F64198C245@rfc-editor.org> <4EAB695F.3060809@cs.yale.edu> From: Richard Alimi Date: Sat, 29 Oct 2011 00:17:38 -0700 Message-ID: To: "Y. Richard Yang" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Sat, 29 Oct 2011 00:28:09 -0700 Cc: decade@ietf.org, bortzmeyer+rfceditor@nic.fr, RFC Errata System Subject: Re: [decade] [Technical Errata Reported] RFC6392 (3006) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 07:18:16 -0000 I agree with the proposed change as well. Thanks for catching it! Rich On Fri, Oct 28, 2011 at 7:47 PM, Y. Richard Yang wrote: > Dear St=E9phane Bortzmeyer, > > As a co-editor, I checked the related documents referred to by your repor= t. > I agree with your proposed change: > > Section: 5.1.2 > > Original Text > ------------- > Not provided. > > Corrected Text > -------------- > Basic deletion of resources is provided with the DELETE method. > > It is an excellent catch. > > Thanks a lot! > > Richard > > On 10/26/11 3:43 AM, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC6392, >> "A Survey of In-Network Storage Systems". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6392&eid=3D3006 >> >> -------------------------------------- >> Type: Technical >> Reported by: St=E9phane Bortzmeyer >> >> Section: 5.1.2 >> >> Original Text >> ------------- >> Not provided. >> >> Corrected Text >> -------------- >> Basic deletion of resources is provided with the DELETE method. >> >> Notes >> ----- >> The typical "data management operation" mentioned for other protocols is >> the deletion of data. HTTP has it from the beginning (Section 9.7 of RFC >> 2616). >> >> Apache does not support it directly, you apparently have to provide a >> module which does it (mod_dav does it, even if DELETE is not a WebDAV >> method). Anyway, this section is about the abilities of the protocol, no= t of >> implementations. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6392 (draft-ietf-decade-survey-06) >> -------------------------------------- >> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : A Survey of In-Network Storage Syste= ms >> Publication Date =A0 =A0: October 2011 >> Author(s) =A0 =A0 =A0 =A0 =A0 : R. Alimi, Ed., A. Rahman, Ed., Y. Yang, = Ed. >> Category =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL >> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Decoupled Application Data Enroute >> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Transport >> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF >> Verifying Party =A0 =A0 : IESG > > From Akbar.Rahman@InterDigital.com Sun Oct 30 15:48:04 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E667121F8BF3 for ; Sun, 30 Oct 2011 15:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFbk0AumEV2y for ; Sun, 30 Oct 2011 15:48:04 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id D8C9421F8BDC for ; Sun, 30 Oct 2011 15:48:03 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 30 Oct 2011 18:47:58 -0400 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: Sun, 30 Oct 2011 18:47:59 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Technical Errata Reported] RFC6392 (3006) Thread-index: AcyWCvDHG7fC0/PiSfyrKcunMjFj2wBStcZg References: <20111026074349.0F64198C245@rfc-editor.org> <4EAB695F.3060809@cs.yale.edu> From: "Rahman, Akbar" To: "RFC Errata System" , X-OriginalArrivalTime: 30 Oct 2011 22:47:58.0879 (UTC) FILETIME=[F8C842F0:01CC9755] Cc: decade@ietf.org, Richard Alimi Subject: Re: [decade] [Technical Errata Reported] RFC6392 (3006) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 22:48:05 -0000 Yes, I also agree with the proposed correction by Stephane. Thank you = for pointing it out, Stephane. Akbar -----Original Message----- From: Richard Alimi [mailto:ralimi@google.com]=20 Sent: Saturday, October 29, 2011 3:18 AM To: Y. Richard Yang Cc: RFC Errata System; Rahman, Akbar; ietfdbh@comcast.net; = wes@mti-systems.com; Richard_Woundy@cable.comcast.com; = haibin.song@huawei.com; bortzmeyer+rfceditor@nic.fr; decade@ietf.org Subject: Re: [Technical Errata Reported] RFC6392 (3006) I agree with the proposed change as well. Thanks for catching it! Rich On Fri, Oct 28, 2011 at 7:47 PM, Y. Richard Yang = wrote: > Dear St=E9phane Bortzmeyer, > > As a co-editor, I checked the related documents referred to by your = report. > I agree with your proposed change: > > Section: 5.1.2 > > Original Text > ------------- > Not provided. > > Corrected Text > -------------- > Basic deletion of resources is provided with the DELETE method. > > It is an excellent catch. > > Thanks a lot! > > Richard > > On 10/26/11 3:43 AM, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC6392, >> "A Survey of In-Network Storage Systems". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6392&eid=3D3006 >> >> -------------------------------------- >> Type: Technical >> Reported by: St=E9phane Bortzmeyer >> >> Section: 5.1.2 >> >> Original Text >> ------------- >> Not provided. >> >> Corrected Text >> -------------- >> Basic deletion of resources is provided with the DELETE method. >> >> Notes >> ----- >> The typical "data management operation" mentioned for other protocols = is >> the deletion of data. HTTP has it from the beginning (Section 9.7 of = RFC >> 2616). >> >> Apache does not support it directly, you apparently have to provide a >> module which does it (mod_dav does it, even if DELETE is not a WebDAV >> method). Anyway, this section is about the abilities of the protocol, = not of >> implementations. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6392 (draft-ietf-decade-survey-06) >> -------------------------------------- >> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : A Survey of In-Network Storage = Systems >> Publication Date =A0 =A0: October 2011 >> Author(s) =A0 =A0 =A0 =A0 =A0 : R. Alimi, Ed., A. Rahman, Ed., Y. = Yang, Ed. >> Category =A0 =A0 =A0 =A0 =A0 =A0: INFORMATIONAL >> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Decoupled Application Data = Enroute >> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Transport >> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF >> Verifying Party =A0 =A0 : IESG > > From Internet-Drafts@ietf.org Mon Oct 31 09:00:04 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9529221F8E2D; Mon, 31 Oct 2011 09:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40tE3knUHR9W; Mon, 31 Oct 2011 09:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C4021F8E2A; Mon, 31 Oct 2011 09:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031160002.9589.25185.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 09:00:02 -0700 Cc: decade@ietf.org Subject: [decade] I-D ACTION:draft-ietf-decade-integration-example-02.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:00:04 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Decoupled Application Data Enroute Working Group of the IETF. Title : Integration Examples of DECADE System Author(s) : L. Chen, et al Filename : draft-ietf-decade-integration-example-02.txt Pages : 30 Date : 2011-10-31 DECADE is an in-network storage infrastructure which is under discussions and constructions. It can be integrated into Peer-to- Peer (P2P) applications to achieve more efficient content distributions. This document represents two detailed examples of how to integrate DECADE into P2P applications (live streaming and file sharing). Specifically, it describes mainly about: 1) a preliminary DECADE client API; 2) a P2P live streaming integration with DECADE; 3) a P2P file sharing integration with DECADE; 4)ALTO+DECADE based file distribution platform; 5) tests on our DECADE integrarions and 6) an application performance analysis from the tests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-integration-example-02.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-decade-integration-example-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-10-31084743.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Mon Oct 31 15:15:02 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D7C1F0CDD; Mon, 31 Oct 2011 15:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uzx6nQxSboO; Mon, 31 Oct 2011 15:15:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59521F0CE6; Mon, 31 Oct 2011 15:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031221501.31856.8138.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 15:15:01 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-reqs-05.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:15:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : DECADE Requirements Author(s) : Yingjie Gu David A. Bryan Yang Richard Yang Richard Alimi Filename : draft-ietf-decade-reqs-05.txt Pages : 24 Date : 2011-10-31 The target of DECoupled Application Data Enroute (DECADE) is to provide an open and standard in-network storage system for applications, primarily P2P (peer-to-peer) applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for storage and retrieval, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., a protocol used to read and write data from the storage system). The requirements in this document are intended to ensure that the DECADE architecture includes all of the desired functionality for intended applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-reqs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-reqs-05.txt From internet-drafts@ietf.org Mon Oct 31 15:54:50 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB5411E8351; Mon, 31 Oct 2011 15:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r661lZ7Q9AKc; Mon, 31 Oct 2011 15:54:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1BF11E834E; Mon, 31 Oct 2011 15:54:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031225447.15683.25917.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 15:54:47 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-arch-04.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:54:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : DECADE Architecture Author(s) : Richard Alimi Y. Richard Yang Akbar Rahman Dirk Kutscher Hongqiang Liu Filename : draft-ietf-decade-arch-04.txt Pages : 44 Date : 2011-10-31 Content Distribution Applications (e.g., P2P applications) are widely used on the Internet and make up a large portion of the traffic in many networks. One technique to improve the network efficiency of these applications is to introduce storage capabilities within the networks; this is the capability to be provided by DECADE (DECoupled Application Data Enroute). This document presents an architecture for DECADE, discusses the underlying principles, and identifies core components and protocols for introducing in-network storage for these applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-arch-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-arch-04.txt From lampson0505@gmail.com Mon Oct 31 19:36:17 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C90611E808A for ; Mon, 31 Oct 2011 19:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a0tJ+sWPMoS for ; Mon, 31 Oct 2011 19:36:16 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C952111E8086 for ; Mon, 31 Oct 2011 19:36:16 -0700 (PDT) Received: by iaeo4 with SMTP id o4so77001iae.31 for ; Mon, 31 Oct 2011 19:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=cNitJjyyyGI12hKafIHO8GkoWD/uF1jPcdBg9qkWFyU=; b=qD6qLMttwiFgOkCm9flKc4YaSJt9g1gm2tGcV1gWHqXPxc9VxEfUEHzpnk3a2HtRLG pxC14xmCeQFG9LHwB3tz1fuf/0nOGtsb252vwUntJEC1DLWGKToUlkWZWCU+uWy6FOQh sADr8E3KkVkrAmBbGPfGgnDjoh+MFRcmjLTxk= MIME-Version: 1.0 Received: by 10.42.197.195 with SMTP id el3mr10905508icb.54.1320114976512; Mon, 31 Oct 2011 19:36:16 -0700 (PDT) Received: by 10.42.139.10 with HTTP; Mon, 31 Oct 2011 19:36:16 -0700 (PDT) Date: Mon, 31 Oct 2011 22:36:16 -0400 Message-ID: From: Hongqiang To: decade@ietf.org Content-Type: multipart/alternative; boundary=20cf303bff663cdb2604b0a3383d Subject: [decade] decade example draft is updated X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 02:36:17 -0000 --20cf303bff663cdb2604b0a3383d Content-Type: text/plain; charset=UTF-8 Hi All draft-ietf-decade-integration-example-02.txt is just uploaded. Any comments are welcomed. Thanks very much Hongqiang Liu Yale University --20cf303bff663cdb2604b0a3383d Content-Type: text/html; charset=UTF-8 Hi All

draft-ietf-decade-integration-example-02.txt is just uploaded.
Any comments are welcomed.

Thanks very much

Hongqiang Liu
Yale University


--20cf303bff663cdb2604b0a3383d--