From haibin.song@huawei.com Mon Apr 2 08:13:27 2012 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 B835E21F85EF for ; Mon, 2 Apr 2012 08:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 uGUsQYI-JQxf for ; Mon, 2 Apr 2012 08:13:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2480F21F85CC for ; Mon, 2 Apr 2012 08:13:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEW92888; Mon, 02 Apr 2012 11:13:26 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 08:12:17 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 08:12:16 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.30]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Mon, 2 Apr 2012 23:12:12 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: draft meeting minutes for DECADE WG at IETF 83 Thread-Index: Ac0Q4tJJQaqjMMSHSKOZQaFUjBKU3w== Date: Mon, 2 Apr 2012 15:12:19 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F1586FA6Cszxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] draft meeting minutes for DECADE WG at IETF 83 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, 02 Apr 2012 15:13:27 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F1586FA6Cszxeml534mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, Many thanks to Rich Alimi for taking the notes. Please check the following = link for the draft meeting minutes, and send your comments to the chairs by= April 26 if you have any questions. http://www.ietf.org/proceedings/83/minutes/minutes-83-decade.htm -Haibin & Rich (Co-chairs) --_000_E33E01DFD5BEA24B9F3F18671078951F1586FA6Cszxeml534mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Many thanks to Rich Alimi for taking the notes. Please check the fo= llowing link for the draft meeting minutes, and send your comments to the c= hairs by April 26 if you have any questions.

 

http://www.ietf.org/proceedings/83/minutes/minutes-83-decade.htm

 

-Haibin & Rich (Co-chairs)

--_000_E33E01DFD5BEA24B9F3F18671078951F1586FA6Cszxeml534mbxchi_-- From richard_woundy@cable.comcast.com Mon Apr 2 12:53:36 2012 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 218DA21F871D for ; Mon, 2 Apr 2012 12:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.23 X-Spam-Level: X-Spam-Status: No, score=-101.23 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=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 QwcrlJeaiM7J for ; Mon, 2 Apr 2012 12:53:34 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 871CE21F871C for ; Mon, 2 Apr 2012 12:53:33 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11834168; Mon, 02 Apr 2012 13:40:27 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Mon, 2 Apr 2012 15:53:39 -0400 From: "Woundy, Richard" Thread-Topic: [decade] Remote Get Object Message Thread-Index: AQHNDoKBg3eg7H8F4ECL+B6dPaD8m5aDi/UwgARonwA= Date: Mon, 2 Apr 2012 19:53:26 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD131A168EC@PACDCEXMB05.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.173] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD131A168ECPACDCEXMB05cabl_" MIME-Version: 1.0 To: "Rahman, Akbar" Cc: "decade@ietf.org" Subject: Re: [decade] Remote Get Object Message 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, 02 Apr 2012 19:53:36 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD131A168ECPACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > However, I guess this model breaks down if we are required to support a u= se case where "DECADE server-1" wants to exchange content with "DECADE serv= er-2" without being triggered by a client. Yes I would tend to agree. One *could* make this look like a proxy case by = forcing server-1 to act as its own proxy, but that seems inelegant. But then I would imagine that server-1 could obtain content from server-2 u= sing a simple HTTP GET, and could push content to server-2 using a simple H= TTP POST, right? We still wouldn't need a new X-DECADE-ORIGIN header or a n= ew HTTP message, right? -- Rich From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] Sent: Friday, March 30, 2012 8:40 PM To: Woundy, Richard Cc: decade@ietf.org Subject: RE: [decade] Remote Get Object Message Hi Rich, I agree that using a classic HTTP GET request (instead of a new modified PO= ST) to implement the "DECADE-compatible Remote Get Object" message is a goo= d approach. I also like your proposal for the local DECADE server to act as a non-trans= parent proxy when processing a request from a client. (I.E. Client makes = a request to "DECADE server-1" which then acts as a proxy by forwarding the= request to "DECADE server-2"). However, I guess this model breaks down if we are required to support a use= case where "DECADE server-1" wants to exchange content with "DECADE server= -2" without being triggered by a client. Do you agree? Akbar From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Woundy, Richard Sent: Friday, March 30, 2012 10:37 AM To: decade@ietf.org Subject: [decade] Remote Get Object Message Folks, In Thursday's session, we discussed how to implement the Remote Get Object = message. One proposal is to use HTTP Post with a new X-DECADE-ORIGIN header= ; another proposal is to define a new HTTP message. See slide 3 of > and >>. My thought (as an individual contributor, not as co-chair) is to use existi= ng HTTP Get headers and leverage the base functionality of an HTTP caching = proxy in DECADE. The local "DECADE" server would act as a caching proxy (wi= th additional functionality of course) in order to reach the remote "DECADE= " server, and cache the contents of the reply in the "DECADE" storage. I ha= ve a "non-transparent proxy" behavior in mind, per the definition of "proxy= " in RFC 2616 (http://tools.ietf.org/html/rfc2616#section-1.3). Also see , , and perhaps as well. Did we fully explore this possibility? As a co-chair, I can assure you that= it would be much better to leverage existing protocols and standards, vers= us inventing new ones. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD131A168ECPACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> However, I guess this model breaks down if we are required to= support a use case where “DECADE server-1” wants to exchange content w= ith “DECADE server-2” without being triggered by a client.

 <= /p>

Yes I would tend to agree= . One *could* make this look like a proxy case by forcing server-1 t= o act as its own proxy, but that seems inelegant.

 <= /p>

But then I would imagine = that server-1 could obtain content from server-2 using a simple HTTP GET, a= nd could push content to server-2 using a simple HTTP POST, right? We still wouldn’t need a new X-DECADE-ORIGIN header or a new = HTTP message, right?

 <= /p>

-- Rich=

 <= /p>

From: Rahman, = Akbar [mailto:Akbar.Rahman@InterDigital.com]
Sent: Friday, March 30, 2012 8:40 PM
To: Woundy, Richard
Cc: decade@ietf.org
Subject: RE: [decade] Remote Get Object Message

 

Hi Rich,

 <= /p>

I agree that using a clas= sic HTTP GET request (instead of a new modified POST) to implement the R= 20;DECADE-compatible Remote Get Object” message is a good approach.

 <= /p>

I also like your proposal= for the local DECADE server to act as a non-transparent proxy when process= ing a request from a client.   (I.E. Client makes a request to “DECADE server-1” which then acts as a proxy by forwarding = the request to “DECADE server-2”).

 <= /p>

However, I guess this mod= el breaks down if we are required to support a use case where “DECADE= server-1” wants to exchange content with “DECADE server-2̶= 1; without being triggered by a client.

 <= /p>

Do you agree?<= /span>

 <= /p>

Akbar

 

 

 <= /p>

From: decade-b= ounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard
Sent: Friday, March 30, 2012 10:37 AM
To: decade@ietf.org
Subject: [decade] Remote Get Object Message

 

Folks,

 

In Thursday's session, we d= iscussed how to implement the Remote Get Object message. One proposal is to= use HTTP Post with a new X-DECADE-ORIGIN header; another proposal is to define a new HTTP message. See slide 3 of <http://w= ww.ietf.org/proceedings/83/slides/slides-83-decade-4.pdf> and <http://tools.ietf.org/html/draft-wang-decade-drp-03#section-8>.

 

My thought (as an individua= l contributor, not as co-chair) is to use existing HTTP Get headers and lev= erage the base functionality of an HTTP caching proxy in DECADE. The local "DECADE" server would act as a caching proxy (= with additional functionality of course) in order to reach the remote "= ;DECADE" server, and cache the contents of the reply in the "DECA= DE" storage. I have a "non-transparent proxy" behavior in mind, per the definition of "proxy" in RFC 2616 (http://tools.ietf.org/html/rfc2= 616#section-1.3). Also see <http://tools.ietf.org/html/rfc2616#section-13>, <http://tools.ietf.org/h= tml/rfc3040>, and perhaps <http://tools.ietf.org/html/rfc3143> as well.

 

Did we fully explore this p= ossibility? As a co-chair, I can assure you that it would be much better to= leverage existing protocols and standards, versus inventing new ones.

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD131A168ECPACDCEXMB05cabl_-- From Akbar.Rahman@InterDigital.com Tue Apr 3 06:55:27 2012 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 0E4C611E8096 for ; Tue, 3 Apr 2012 06:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 kO1d1We2ImTH for ; Tue, 3 Apr 2012 06:55:24 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC3311E8079 for ; Tue, 3 Apr 2012 06:55:17 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 09:55:17 -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_01CD11A1.664F980E" Date: Tue, 3 Apr 2012 09:55:16 -0400 Message-ID: In-reply-to: <1CA25301D2219F40B3AA37201F0EACD131A168EC@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Remote Get Object Message Thread-Index: AQHNDoKBg3eg7H8F4ECL+B6dPaD8m5aDi/UwgARonwCAATCQAA== References: <1CA25301D2219F40B3AA37201F0EACD131A168EC@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Woundy, Richard" X-OriginalArrivalTime: 03 Apr 2012 13:55:17.0471 (UTC) FILETIME=[66BD6EF0:01CD11A1] Cc: decade@ietf.org Subject: Re: [decade] Remote Get Object Message 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, 03 Apr 2012 13:55:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD11A1.664F980E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rich, =20 =20 Yes, that is a good point. I agree that for server-server communications (without a client involved) then standard HTTP GETs, PUTs and POSTs could be used without need for new headers or methods. =20 =20 Akbar =20 =20 =20 From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Monday, April 02, 2012 3:53 PM To: Rahman, Akbar Cc: decade@ietf.org; Woundy, Richard Subject: RE: [decade] Remote Get Object Message =20 > However, I guess this model breaks down if we are required to support a use case where "DECADE server-1" wants to exchange content with "DECADE server-2" without being triggered by a client. =20 Yes I would tend to agree. One *could* make this look like a proxy case by forcing server-1 to act as its own proxy, but that seems inelegant. =20 But then I would imagine that server-1 could obtain content from server-2 using a simple HTTP GET, and could push content to server-2 using a simple HTTP POST, right? We still wouldn't need a new X-DECADE-ORIGIN header or a new HTTP message, right? =20 -- Rich =20 From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com]=20 Sent: Friday, March 30, 2012 8:40 PM To: Woundy, Richard Cc: decade@ietf.org Subject: RE: [decade] Remote Get Object Message =20 Hi Rich, =20 I agree that using a classic HTTP GET request (instead of a new modified POST) to implement the "DECADE-compatible Remote Get Object" message is a good approach. =20 I also like your proposal for the local DECADE server to act as a non-transparent proxy when processing a request from a client. (I.E. Client makes a request to "DECADE server-1" which then acts as a proxy by forwarding the request to "DECADE server-2"). =20 However, I guess this model breaks down if we are required to support a use case where "DECADE server-1" wants to exchange content with "DECADE server-2" without being triggered by a client.=20 =20 Do you agree? =20 Akbar =20 =20 =20 From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Friday, March 30, 2012 10:37 AM To: decade@ietf.org Subject: [decade] Remote Get Object Message =20 Folks, =20 In Thursday's session, we discussed how to implement the Remote Get Object message. One proposal is to use HTTP Post with a new X-DECADE-ORIGIN header; another proposal is to define a new HTTP message. See slide 3 of > and > >. =20 My thought (as an individual contributor, not as co-chair) is to use existing HTTP Get headers and leverage the base functionality of an HTTP caching proxy in DECADE. The local "DECADE" server would act as a caching proxy (with additional functionality of course) in order to reach the remote "DECADE" server, and cache the contents of the reply in the "DECADE" storage. I have a "non-transparent proxy" behavior in mind, per the definition of "proxy" in RFC 2616 (http://tools.ietf.org/html/rfc2616#section-1.3). Also see , , and perhaps as well. =20 Did we fully explore this possibility? As a co-chair, I can assure you that it would be much better to leverage existing protocols and standards, versus inventing new ones. =20 -- Rich ------_=_NextPart_001_01CD11A1.664F980E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rich,

 

 

Yes, that is a good point.  I agree that for server-server = communications (without a client involved) then standard HTTP GETs, PUTs = and POSTs could be used without need for new headers or = methods.

 

 

Akbar

 

 

 

From:= = Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] =
Sent: Monday, April 02, 2012 3:53 PM
To: Rahman, = Akbar
Cc: decade@ietf.org; Woundy, Richard
Subject: = RE: [decade] Remote Get Object = Message

 

> However, I guess this model breaks down if we are required to = support a use case where “DECADE server-1” wants to exchange = content with “DECADE server-2” without being triggered by a = client.

 

Yes I would tend to agree. One *could* make this look like a = proxy case by forcing server-1 to act as its own proxy, but that seems = inelegant.

 

But then I would imagine that server-1 could obtain content from = server-2 using a simple HTTP GET, and could push content to server-2 = using a simple HTTP POST, right? We still wouldn’t need a new = X-DECADE-ORIGIN header or a new HTTP message, = right?

 

-- Rich

 

From:= = Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com]
Sent: = Friday, March 30, 2012 8:40 PM
To: Woundy, = Richard
Cc: decade@ietf.org
Subject: RE: [decade] = Remote Get Object Message

 

Hi Rich,

 

I agree that using a classic HTTP GET request (instead of a new = modified POST) to implement the “DECADE-compatible Remote Get = Object” message is a good approach.

 

I also like your proposal for the local DECADE server to act as a = non-transparent proxy when processing a request from a client. =   (I.E. Client makes a request to “DECADE = server-1” which then acts as a proxy by forwarding the request to = “DECADE server-2”).

 

However, I guess this model breaks down if we are required to support = a use case where “DECADE server-1” wants to exchange content = with “DECADE server-2” without being triggered by a client. =

 

Do you agree?

 

Akbar

 

 

 

From:= = decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of = Woundy, Richard
Sent: Friday, March 30, 2012 10:37 = AM
To: decade@ietf.org
Subject: [decade] Remote Get = Object Message

 

Folks,

 

In Thursday's session, we discussed how to implement the Remote Get = Object message. One proposal is to use HTTP Post with a new = X-DECADE-ORIGIN header; another proposal is to define a new HTTP = message. See slide 3 of <http://www.ietf.org/proceedings/83/slides/slides-83-decade-4.pdf&= gt; and <http://tools.ietf.org/html/draft-wang-decade-drp-03#section-8>.<= o:p>

 

My thought (as an individual contributor, not as co-chair) is to use = existing HTTP Get headers and leverage the base functionality of an HTTP = caching proxy in DECADE. The local "DECADE" server would act = as a caching proxy (with additional functionality of course) in order to = reach the remote "DECADE" server, and cache the contents of = the reply in the "DECADE" storage. I have a = "non-transparent proxy" behavior in mind, per the definition = of "proxy" in RFC 2616 (http://tools.ietf= .org/html/rfc2616#section-1.3). Also see <http://tools.ietf.= org/html/rfc2616#section-13>, <http://tools.ietf.org/html/rf= c3040>, and perhaps <http://tools.ietf.org/html/rf= c3143> as well.

 

Did we fully explore this possibility? As a co-chair, I can assure you = that it would be much better to leverage existing protocols and = standards, versus inventing new ones.

 

-- Rich

------_=_NextPart_001_01CD11A1.664F980E-- From stephen.farrell@cs.tcd.ie Thu Apr 5 13:09:41 2012 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 74A2921F86A0 for ; Thu, 5 Apr 2012 13:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 GQpKAD6Zf4J7 for ; Thu, 5 Apr 2012 13:09:40 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B311721F869E for ; Thu, 5 Apr 2012 13:09:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EBDAF171C02 for ; Thu, 5 Apr 2012 21:09:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1333656578; bh=fh7mClla1kKULT0hm2rAAtJh UdystROWWgkKfPmZB9Y=; b=aLuszYsi320Q/MlIicKOittojB0s6p0TEuBForpU ndNhyWvOlhkpEhAcQNqWWOF0ypOwC9kRm8+/tQGSTtZgmZuAgjzO5IP0H6Sux4Gy +BvTfQLa2iQbWccL7zW1FMirAu1JNpN0euA+xz0eqJxytGdxsE9ZioBZQCLodAoe u/2sqVj+ccuR2r/gcaH9FGOzH4gAdERZQ8Mj3c0AdFf3fU521yhIfnHWw7TruxcK pEkEJx32QiJxjoDxHavXmq8FnCEhvbAR3IpmKneg6AWZxR+A0yC1osv5ZV44vhu3 QW7UJtCj4KVLMfKMjGbf2Svj+KFRgDt0Qi6IZsJI9mnMlA== 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 0j+hPb6OPtXa for ; Thu, 5 Apr 2012 21:09:38 +0100 (IST) Received: from [10.87.48.3] (unknown [86.41.2.139]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 841DB171BFD for ; Thu, 5 Apr 2012 21:09:38 +0100 (IST) Message-ID: <4F7DFC02.1050809@cs.tcd.ie> Date: Thu, 05 Apr 2012 21:09:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [decade] draft-farrell-decade-ni-02 - we think this is done... 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, 05 Apr 2012 20:09:41 -0000 ...well, modulo one or two questions still in the document [1] and getting your review:-) This document has been discussed in the decade WG as a way to standardise how to emded hashes into names, which is something that'll likely be needed there but is clearly more general. As if to prove that, at IETF-83 we added a binary form that seems to better fit what the core WG want for doing the same thing in CoAP. We've worked on it a good bit in the time since and so we reckon this is pretty much ready now. Our plan is to try get comments from the decade, core and appsarea lists and if we're looking good to then ask Barry Leiba if he'll AD sponsor this document, so it can be done in time to not slow down CoAP. (Barry's ok with this plan.) So, please take a read if you're interested in naming things with hashes and send your comments. Since this was first discussed on the decade list, I'll suggest using that [2] as a good place to send comments. Any of the above-mentioned lists will work though, since various authors are on each. Probably better to not cross-post to them all though. (I've sent separate mails to each for that reason.) Thanks, Stephen. [1] http://tools.ietf.org/html/draft-farrell-decade-ni [2] https://www.ietf.org/mailman/listinfo/decade From haibin.song@huawei.com Tue Apr 17 19:26:59 2012 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 8175B11E80D7 for ; Tue, 17 Apr 2012 19:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 lD9eUYVhyPeL for ; Tue, 17 Apr 2012 19:26:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0A311E80E2 for ; Tue, 17 Apr 2012 19:26:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFH73200; Tue, 17 Apr 2012 22:26:54 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 19:23:58 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 19:24:01 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.43]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 10:23:54 +0800 From: Songhaibin To: "Rahman, Akbar" , "Woundy, Richard" Thread-Topic: [decade] Remote Get Object Message Thread-Index: AQHNDoKBg3eg7H8F4ECL+B6dPaD8m5aDi/UwgARonwCAATCQAIAWz0iQ Date: Wed, 18 Apr 2012 02:23:54 +0000 Message-ID: References: <1CA25301D2219F40B3AA37201F0EACD131A168EC@PACDCEXMB05.cable.comcast.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.129] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23A4A68Fszxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] Remote Get Object Message 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, 18 Apr 2012 02:26:59 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23A4A68Fszxeml534mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also agree with that using standard HTTP GET and POST can be better for r= emote get behavior and server to server data communication than inventing n= ew headers. I also agree with the non-transparent proxy concept. BR, -Haibin (as contributor) From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Rahman, Akbar Sent: Tuesday, April 03, 2012 9:55 PM To: Woundy, Richard Cc: decade@ietf.org Subject: Re: [decade] Remote Get Object Message Hi Rich, Yes, that is a good point. I agree that for server-server communications (= without a client involved) then standard HTTP GETs, PUTs and POSTs could be= used without need for new headers or methods. Akbar From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Monday, April 02, 2012 3:53 PM To: Rahman, Akbar Cc: decade@ietf.org; Woundy, Richard Subject: RE: [decade] Remote Get Object Message > However, I guess this model breaks down if we are required to support a u= se case where "DECADE server-1" wants to exchange content with "DECADE serv= er-2" without being triggered by a client. Yes I would tend to agree. One *could* make this look like a proxy case by = forcing server-1 to act as its own proxy, but that seems inelegant. But then I would imagine that server-1 could obtain content from server-2 u= sing a simple HTTP GET, and could push content to server-2 using a simple H= TTP POST, right? We still wouldn't need a new X-DECADE-ORIGIN header or a n= ew HTTP message, right? -- Rich From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] Sent: Friday, March 30, 2012 8:40 PM To: Woundy, Richard Cc: decade@ietf.org Subject: RE: [decade] Remote Get Object Message Hi Rich, I agree that using a classic HTTP GET request (instead of a new modified PO= ST) to implement the "DECADE-compatible Remote Get Object" message is a goo= d approach. I also like your proposal for the local DECADE server to act as a non-trans= parent proxy when processing a request from a client. (I.E. Client makes = a request to "DECADE server-1" which then acts as a proxy by forwarding the= request to "DECADE server-2"). However, I guess this model breaks down if we are required to support a use= case where "DECADE server-1" wants to exchange content with "DECADE server= -2" without being triggered by a client. Do you agree? Akbar From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Woundy, Richard Sent: Friday, March 30, 2012 10:37 AM To: decade@ietf.org Subject: [decade] Remote Get Object Message Folks, In Thursday's session, we discussed how to implement the Remote Get Object = message. One proposal is to use HTTP Post with a new X-DECADE-ORIGIN header= ; another proposal is to define a new HTTP message. See slide 3 of > and >>. My thought (as an individual contributor, not as co-chair) is to use existi= ng HTTP Get headers and leverage the base functionality of an HTTP caching = proxy in DECADE. The local "DECADE" server would act as a caching proxy (wi= th additional functionality of course) in order to reach the remote "DECADE= " server, and cache the contents of the reply in the "DECADE" storage. I ha= ve a "non-transparent proxy" behavior in mind, per the definition of "proxy= " in RFC 2616 (http://tools.ietf.org/html/rfc2616#section-1.3). Also see , , and perhaps as well. Did we fully explore this possibility? As a co-chair, I can assure you that= it would be much better to leverage existing protocols and standards, vers= us inventing new ones. -- Rich --_000_E33E01DFD5BEA24B9F3F18671078951F23A4A68Fszxeml534mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also agr= ee with that using standard HTTP GET and POST can be better for remote get = behavior and server to server data communication than inventing new headers. I also agree with the non-transparent proxy concept.

 = ;

BR,

-Haibin (a= s contributor)

 = ;

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Rahman, Akbar
Sent: Tuesday, April 03, 2012 9:55 PM
To: Woundy, Richard
Cc: decade@ietf.org
Subject: Re: [decade] Remote Get Object Message

 

Hi Rich,

 = ;

 = ;

Yes, that = is a good point.  I agree that for server-server communications (witho= ut a client involved) then standard HTTP GETs, PUTs and POSTs could be used without need for new headers or methods.

 = ;

 = ;

Akbar=

 = ;

 = ;

 = ;

From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.= com]
Sent: Monday, April 02, 2012 3:53 PM
To: Rahman, Akbar
Cc: decade@ietf.org; Woundy, Richard
Subject: RE: [decade] Remote Get Object Message

 

> Howev= er, I guess this model breaks down if we are required to support a use case= where “DECADE server-1” wants to exchange content with “= DECADE server-2” without being triggered by a client.

 = ;

Yes I woul= d tend to agree. One *could* make this look like a proxy case by for= cing server-1 to act as its own proxy, but that seems inelegant.=

 = ;

But then I= would imagine that server-1 could obtain content from server-2 using a sim= ple HTTP GET, and could push content to server-2 using a simple HTTP POST, right? We still wouldn’t need a new X-DECADE-ORIGIN heade= r or a new HTTP message, right?

 = ;

-- Rich

 = ;

From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com]
Sent: Friday, March 30, 2012 8:40 PM
To: Woundy, Richard
Cc: decade@ietf.org
Subject: RE: [decade] Remote Get Object Message

 

Hi Rich,

 = ;

I agree th= at using a classic HTTP GET request (instead of a new modified POST) to imp= lement the “DECADE-compatible Remote Get Object” message is a good approach.

 = ;

I also lik= e your proposal for the local DECADE server to act as a non-transparent pro= xy when processing a request from a client.   (I.E. Client makes a request to “DECADE server-1” which then acts as a prox= y by forwarding the request to “DECADE server-2”).

 = ;

However, I= guess this model breaks down if we are required to support a use case wher= e “DECADE server-1” wants to exchange content with “DECAD= E server-2” without being triggered by a client.

 = ;

Do you agr= ee?

 = ;

Akbar=

 

 

 = ;

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Woundy, Richard
Sent: Friday, March 30, 2012 10:37 AM
To: decade@ietf.org
Subject: [decade] Remote Get Object Message

 

Folks,<= /o:p>

 <= /o:p>

In Thursday'= s session, we discussed how to implement the Remote Get Object message. One= proposal is to use HTTP Post with a new X-DECADE-ORIGIN header; another proposal is to define a new HTTP message. See slide 3 of <= http://www.ietf.org/proceedings/83/slides/slides-83-decade-4.pdf> an= d <http://tools.ietf.org/html/draft-wang-decade-drp-03#section-8&= gt;.

 <= /o:p>

My thought (= as an individual contributor, not as co-chair) is to use existing HTTP Get = headers and leverage the base functionality of an HTTP caching proxy in DECADE. The local "DECADE" server would act as a cachin= g proxy (with additional functionality of course) in order to reach the rem= ote "DECADE" server, and cache the contents of the reply in the &= quot;DECADE" storage. I have a "non-transparent proxy" behav= ior in mind, per the definition of "proxy" in RFC 2616 (http://tools.ietf.org/html/r= fc2616#section-1.3). Also see <http://tools.ietf.org/html/rfc2616#section-13>, <http://tools.ietf.org/h= tml/rfc3040>, and perhaps <http://tools.ietf.org/html/rfc3143> as well.

 <= /o:p>

Did we fully= explore this possibility? As a co-chair, I can assure you that it would be= much better to leverage existing protocols and standards, versus inventing new ones.

 <= /o:p>

-- Rich=

--_000_E33E01DFD5BEA24B9F3F18671078951F23A4A68Fszxeml534mbxchi_-- From Akbar.Rahman@InterDigital.com Wed Apr 18 19:35:00 2012 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 A22C911E80B0 for ; Wed, 18 Apr 2012 19:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 XlOshogQ2Y9F for ; Wed, 18 Apr 2012 19:34:56 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 27CED11E8089 for ; Wed, 18 Apr 2012 19:34:55 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Apr 2012 22:34:55 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1DD5.0115F75E" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Apr 2012 22:34:53 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG review of draft-ietf-decade-integration-example-03 Thread-Index: Ac0d1QAixcgZ+fKKS2Wh40ZxMUXw0A== From: "Rahman, Akbar" To: "ZongNing" X-OriginalArrivalTime: 19 Apr 2012 02:34:55.0596 (UTC) FILETIME=[019DA2C0:01CD1DD5] Cc: decade@ietf.org Subject: [decade] WG review of draft-ietf-decade-integration-example-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: Thu, 19 Apr 2012 02:35:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1DD5.0115F75E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ning (and the other authors), =20 =20 As per the chairs request in the IETF Paris meeting, I reviewed the draft-ietf-decade-integration-example-03 and have the following feedback: =20 1. Overall, the document is well written and useful and I support advancing it to IESG. =20 2. My previous comments (http://www.ietf.org/mail-archive/web/decade/current/msg00608.html ) have been all addressed in the -03 version. Thank you for that. 3. I did have a few small remaining editorial comments though: a) In the draft, you should NOT refer to a "WG" which is temporal and will disappear in time. This I-D will become an RFC and thus should not point to a temporary WG. You should just refer to "DECADE" as a technology. You can look at RFC 6392 (Survey) for an example of how to refer to DECADE or at some of the other WG I-Ds. b) In section 4.1.3, can you please provide a bit more explanation of what "... the name of the data object as the ID ..." means. For example, is this name assigned by a human administrator or by some other means? c) In section 9 * Change the title from "Short Conclusion" to just "Conclusion" * Remove the last sentence about "More information would be provided after more experiments are done in the future". Unless you want to keep your document out of the RFC process until then! =20 =20 That's it. Thanks for all your good work. =20 =20 Akbar =20 ------_=_NextPart_001_01CD1DD5.0115F75E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ning = (and the other authors),

 

 

As per the = chairs request in the IETF Paris meeting, I reviewed the = draft-ietf-decade-integration-example-03 and have the following = feedback:

 

1.       = Overall, the document is well written and useful = and I support advancing it to IESG. 

2.       My = previous comments (http://www.ietf.org/mail-archive/web/decade/current/msg00608.html = ) have been all addressed in the -03 version.  Thank you for = that.

3.       I = did have a few small remaining editorial comments = though:

a)      = In the draft, you should NOT refer to a = “WG” which is temporal and will disappear in time.  = This I-D will become an RFC and thus should not point to a temporary = WG.  You should just refer to “DECADE” as a = technology.   You can look at RFC 6392 (Survey) for an example = of how to refer to DECADE or at some of the other WG = I-Ds.

b)      = In section 4.1.3, can you please provide a bit = more explanation of what “… the name of the data object as = the ID …” means.  For example, is this name assigned by = a human administrator or by some other means?

c)       In = section 9

·         = Change the title from “Short = Conclusion” to just “Conclusion”

·         = Remove the last sentence about = “More information would be provided after more experiments are = done in the future”.  Unless you want to keep your document = out of the RFC process until then!

 

 

That’s = it.  Thanks for all your good work.

 

 

Akbar

 

------_=_NextPart_001_01CD1DD5.0115F75E-- From zongning@huawei.com Wed Apr 18 19:45:41 2012 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 F3ED611E8089 for ; Wed, 18 Apr 2012 19:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 2EaYJ6wB+e6F for ; Wed, 18 Apr 2012 19:45:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EF1F511E8086 for ; Wed, 18 Apr 2012 19:45:32 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI56995; Wed, 18 Apr 2012 22:45:32 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 19:42:30 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 19:42:28 -0700 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.151]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Thu, 19 Apr 2012 10:42:24 +0800 From: Zongning To: "Rahman, Akbar" Thread-Topic: WG review of draft-ietf-decade-integration-example-03 Thread-Index: Ac0d1QAixcgZ+fKKS2Wh40ZxMUXw0AAANaQQ Date: Thu, 19 Apr 2012 02:42:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.33] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677916CECE85szxeml504mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] WG review of draft-ietf-decade-integration-example-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: Thu, 19 Apr 2012 02:45:41 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677916CECE85szxeml504mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Akbar, Thank you so much for (again) taking time reviewing the draft. I will definitely resolve your comments in the new revision. -Ning From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] Sent: Thursday, April 19, 2012 10:35 AM To: Zongning Cc: decade@ietf.org Subject: WG review of draft-ietf-decade-integration-example-03 Hi Ning (and the other authors), As per the chairs request in the IETF Paris meeting, I reviewed the draft-i= etf-decade-integration-example-03 and have the following feedback: 1. Overall, the document is well written and useful and I support adv= ancing it to IESG. 2. My previous comments (http://www.ietf.org/mail-archive/web/decade/= current/msg00608.html ) have been all addressed in the -03 version. Thank = you for that. 3. I did have a few small remaining editorial comments though: a) In the draft, you should NOT refer to a "WG" which is temporal and = will disappear in time. This I-D will become an RFC and thus should not po= int to a temporary WG. You should just refer to "DECADE" as a technology. = You can look at RFC 6392 (Survey) for an example of how to refer to DECAD= E or at some of the other WG I-Ds. b) In section 4.1.3, can you please provide a bit more explanation of = what "... the name of the data object as the ID ..." means. For example, i= s this name assigned by a human administrator or by some other means? c) In section 9 * Change the title from "Short Conclusion" to just "Conclusion" * Remove the last sentence about "More information would be provide= d after more experiments are done in the future". Unless you want to keep = your document out of the RFC process until then! That's it. Thanks for all your good work. Akbar --_000_B0D29E0424F2DE47A0B36779EC66677916CECE85szxeml504mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Akbar,

 

Thank you so much for (again) taking time reviewing the draft.

I will definitely resolve your comments in the new revision.=

 

-Ning

 

From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com]
Sent: Thursday, April 19, 2012 10:35 AM
To: Zongning
Cc: decade@ietf.org
Subject: WG review of draft-ietf-decade-integration-example-03<= /o:p>

 

Hi Ning (and the other authors)= ,

 

 

As per the chairs request in th= e IETF Paris meeting, I reviewed the draft-ietf-decade-integration-example-= 03 and have the following feedback:

 

1. &nbs= p;     Overall, the document i= s well written and useful and I support advancing it to IESG. 

2. &nbs= p;     My previous comments (<= a href=3D"http://www.ietf.org/mail-archive/web/decade/current/msg00608.html= ">http://www.ietf.org/mail-archive/web/decade/current/msg00608.html ) h= ave been all addressed in the -03 version.  Thank you for that.

3. &nbs= p;     I did have a few small = remaining editorial comments though:

a= )   &= nbsp;  In the draft, you shoul= d NOT refer to a “WG” which is temporal and will disappear in t= ime.  This I-D will become an RFC and thus should not point to a tempo= rary WG.  You should just refer to “DECADE” as a technolog= y.   You can look at RFC 6392 (Survey) for an example of how to refer to DECADE= or at some of the other WG I-Ds.

b= )   &= nbsp;  In section 4.1.3, can y= ou please provide a bit more explanation of what “… the name of= the data object as the ID …” means.  For example, is this= name assigned by a human administrator or by some other means?<= /span>

c= )   &= nbsp;   In section 9=

·         Change the title from &= #8220;Short Conclusion” to just “Conclusion”

·         Remove the last sentenc= e about “More information would be provided after more experiments ar= e done in the future”.  Unless you want to keep your document ou= t of the RFC process until then!

 

 

That’s it.  Thanks f= or all your good work.

 

 

Akbar

 

--_000_B0D29E0424F2DE47A0B36779EC66677916CECE85szxeml504mbschi_-- From haibin.song@huawei.com Mon Apr 23 01:05:01 2012 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 A8B7621F85E3 for ; Mon, 23 Apr 2012 01:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Vflrrrr0etQP for ; Mon, 23 Apr 2012 01:04:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C0F5921F851D for ; Mon, 23 Apr 2012 01:04:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFL33166; Mon, 23 Apr 2012 04:04:56 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 01:03:03 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 01:02:49 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.43]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 16:02:53 +0800 From: Songhaibin To: "Rahman, Akbar" , Zongning Thread-Topic: WG review of draft-ietf-decade-integration-example-03 Thread-Index: Ac0d1QAixcgZ+fKKS2Wh40ZxMUXw0ADUi/LA Date: Mon, 23 Apr 2012 08:02:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.129] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23A51001szxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] WG review of draft-ietf-decade-integration-example-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, 23 Apr 2012 08:05:01 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23A51001szxeml534mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Rahman, Akbar Sent: Thursday, April 19, 2012 10:35 AM To: Zongning Cc: decade@ietf.org Subject: [decade] WG review of draft-ietf-decade-integration-example-03 Hi Ning (and the other authors), As per the chairs request in the IETF Paris meeting, I reviewed the draft-i= etf-decade-integration-example-03 and have the following feedback: 1. Overall, the document is well written and useful and I support adv= ancing it to IESG. 2. My previous comments (http://www.ietf.org/mail-archive/web/decade/= current/msg00608.html ) have been all addressed in the -03 version. Thank = you for that. 3. I did have a few small remaining editorial comments though: a) In the draft, you should NOT refer to a "WG" which is temporal and wil= l disappear in time. This I-D will become an RFC and thus should not point= to a temporary WG. You should just refer to "DECADE" as a technology. Y= ou can look at RFC 6392 (Survey) for an example of how to refer to DECADE o= r at some of the other WG I-Ds. [Haibin] This point is really important to all working group documents. b) In section 4.1.3, can you please provide a bit more explanation of what= "... the name of the data object as the ID ..." means. For example, is th= is name assigned by a human administrator or by some other means? c) In section 9 * Change the title from "Short Conclusion" to just "Conclusion" * Remove the last sentence about "More information would be provided af= ter more experiments are done in the future". Unless you want to keep your= document out of the RFC process until then! [Haibin] Agree with this point. -Haibin (as individual) That's it. Thanks for all your good work. Akbar --_000_E33E01DFD5BEA24B9F3F18671078951F23A51001szxeml534mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Rahman, Akbar
Sent: Thursday, April 19, 2012 10:35 AM
To: Zongning
Cc: decade@ietf.org
Subject: [decade] WG review of draft-ietf-decade-integration-example= -03

 

Hi Ning (and the other authors)= ,

 

 

As per the chairs request in th= e IETF Paris meeting, I reviewed the draft-ietf-decade-integration-example-= 03 and have the following feedback:

 

1. &nbs= p;     Overall, the document i= s well written and useful and I support advancing it to IESG. 

2. &nbs= p;     My previous comments (<= a href=3D"http://www.ietf.org/mail-archive/web/decade/current/msg00608.html= ">http://www.ietf.org/mail-archive/web/decade/current/msg00608.html ) h= ave been all addressed in the -03 version.  Thank you for that.

3. &nbs= p;     I did have a few small = remaining editorial comments though:

a= )   In the draft, you shoul= d NOT refer to a “WG” which is temporal and will disappear in t= ime.  This I-D will become an RFC and thus should not point to a tempo= rary WG.  You should just refer to “DECADE” as a technolog= y.   You can look at RFC 6392 (Survey) for an example of how to refer to DECADE= or at some of the other WG I-Ds.

 

[Haibin]  This point is really important to all working grou= p documents.

 

b= )  In section 4.1.3, can y= ou please provide a bit more explanation of what “… the name of= the data object as the ID …” means.  For example, is this= name assigned by a human administrator or by some other means?<= /span>

c= )   In section 9=

·     Change the title from &= #8220;Short Conclusion” to just “Conclusion”

·     Remove the last sentenc= e about “More information would be provided after more experiments ar= e done in the future”.  Unless you want to keep your document ou= t of the RFC process until then!

[Haibin] Agree with this point.

 

-Haibin (as individual)

 

 

That’s it.  Thanks f= or all your good work.

 

 

Akbar

 

--_000_E33E01DFD5BEA24B9F3F18671078951F23A51001szxeml534mbxchi_--