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

"Y. Richard Yang" <yry@cs.yale.edu> Fri, 28 September 2012 14:22 UTC

Return-Path: <yry@cs.yale.edu>
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 DC04121F8620 for <decade@ietfa.amsl.com>; Fri, 28 Sep 2012 07:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxhoAWaPl4Mn for <decade@ietfa.amsl.com>; Fri, 28 Sep 2012 07:22:03 -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 2A23B21F8617 for <decade@ietf.org>; Fri, 28 Sep 2012 07:22:03 -0700 (PDT)
Received: from dhcp-128-36-46-174.central.yale.edu (dhcp-128-36-46-174.central.yale.edu [128.36.46.174]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (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: <5065B288.20401@cs.yale.edu>
Date: Fri, 28 Sep 2012 10:22:00 -0400
From: "Y. Richard Yang" <yry@cs.yale.edu>
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 <martin.stiemerling@neclab.eu>
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <505C7772.3070503@cs.yale.edu> <50602997.6090201@neclab.eu> <50607948.6060002@cs.yale.edu> <5062E5FA.7030405@neclab.eu> <CANUuoLrySxdD2Mmc_+5S1SivoMy5NF+E01uGhoP3zDRKVswzYg@mail.gmail.com> <5065A753.1010109@neclab.eu>
In-Reply-To: <5065A753.1010109@neclab.eu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144
Cc: "decade@ietf.org" <decade@ietf.org>
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
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" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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 
condition.

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

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

Thanks.

Richard

> 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
>>
>>     --
>>     martin.stiemerling@neclab.eu
>>
>>     NEC Laboratories Europe - Network Research Division NEC Europe 
>> Limited
>>     Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>>     Registered in England 283
>>
>