Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)

"Y. Richard Yang" <> Fri, 28 September 2012 14:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC04121F8620 for <>; Fri, 28 Sep 2012 07:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cxhoAWaPl4Mn for <>; Fri, 28 Sep 2012 07:22:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2A23B21F8617 for <>; Fri, 28 Sep 2012 07:22:03 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id q8SEM0fk013045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Sep 2012 10:22:01 -0400
Message-ID: <>
Date: Fri, 28 Sep 2012 10:22:00 -0400
From: "Y. Richard Yang" <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Martin Stiemerling <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.71 on
Cc: "" <>
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
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 Sep 2012 14:22:04 -0000

On 9/28/12 9:34 AM, Martin Stiemerling wrote:
> On 09/28/2012 01:10 AM, Y. Richard Yang wrote:
>> On Wednesday, September 26, 2012, Martin Stiemerling wrote:
>>                8.3 Distributed Resource Sharing Specification
>>              REQUIREMENT(S):  A Provider MUST be able to indicate to its
>>         DECADE-
>>                  compatible server, without itself contacting the
>>         server, resource
>>                  control policies for a Consumer.  The DECADE-compatible
>>         server
>>                  MUST be able to authenticate the resource control 
>> policies.
>>     How can the provider indicate its policies to a DECADE server w/o
>>     contacting the server? This is completely impossible!
>> This is possible! A provider can indicate the policies in a token.
>> Hence, the consumer contacts the server and the provider does not!
> Right, but than I do have the question on how the DECADE server is 
> able to verify that the token is correct?
The requirement has the following sentence: "The DECADE-compatible 
server MUST be able to authenticate the resource control policies". Like 
I repeatedly said, I do not feel that it is wise to specify how to 
authenticate: there are so many variations, shared key, public key, from 
standard textbooks.

>>     Probably you can see from where I coming, by comparing the text in
>>     the RATIONAL with the REQUIREMENT(S) text. While the rational gives
>>     a hint to what is expected by this requirement, the requirement
>>     itself is not useful at all.
>>     And, this requirement does still not say how this is done.
>> I gave one example how abve. There can be other smart approaches that I
>> may not foresee. The documents specify what but now how.
>>     Is this done via the SDT or DRP or something else?
>> Either way can work. Depend on the design.
>>     This is an excellent example about what is wrong with the
>>     requirements draft,
>> I look it diferrently. This is an excellent example of giving
>> requirements, but not limiting the design space!
> No, it is limiting the space to the use of tokens 
It is not clear that we have to be limited to the use of tokens. The 
-req authors have thought through that tokens work and hence it is a 
feasible requirement. But there is no "proof" that it is a necessary 

> and it requires modifications to the application protocol, e.g., to 
> the 2p filesharing protocol where the tokens would need to be exchanged.
Yes. This is consistent.

> It is necessary to take design choices at the beginning 
It depends on what you mean by "it is necessary". Personally, I prefer a 
minimal (late-binding) approach, i.e., give more design choices at the 

> and I would expect that the architecture draft would do this. For 
> instance, explicitly arguing for tokens and introducing it. Such 
> decisions do influence a lot in the design and also in the requirements.
> For instance, if you use tokens, you need a management interface where 
> you can configure, for instance, public keys 
It does not have to use a public-key system. It can be a symmetric key 
system. Either way can go through, as I think through, and why not leave 
this space to the protocol designer so that they can come up with a 
coherent design? This is IETF design, not a class homework assignment 
where the instructor already has a solution in mind and prefers that the 
students just say the right answer.



> which are used to verify if a token has been issued by a known and 
> trusted party. This assumes that the token is signed with the private 
> key.
>   Martin
>> Richard
>>     why it has been pushed back to the WG, and why this is one piece of
>>     the puzzle why the DECADE was closed.
>>        Martin
>>     --
>>     NEC Laboratories Europe - Network Research Division NEC Europe 
>> Limited
>>     Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>>     Registered in England 283