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

Martin Stiemerling <martin.stiemerling@neclab.eu> Fri, 28 September 2012 13:34 UTC

Return-Path: <Martin.Stiemerling@neclab.eu>
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 1256E21F855E for <decade@ietfa.amsl.com>; Fri, 28 Sep 2012 06:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.411
X-Spam-Level:
X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 r0Rn9p3Jpeb6 for <decade@ietfa.amsl.com>; Fri, 28 Sep 2012 06:34:22 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 42FEB21F8508 for <decade@ietf.org>; Fri, 28 Sep 2012 06:34:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 914E9101FB3; Fri, 28 Sep 2012 15:34:21 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLm1DYbY5NsS; Fri, 28 Sep 2012 15:34:21 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 71A0C101F95; Fri, 28 Sep 2012 15:34:11 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 15:33:49 +0200
Message-ID: <5065A753.1010109@neclab.eu>
Date: Fri, 28 Sep 2012 15:34:11 +0200
From: Martin Stiemerling <martin.stiemerling@neclab.eu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Y. Richard Yang" <yry@cs.yale.edu>
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>
In-Reply-To: <CANUuoLrySxdD2Mmc_+5S1SivoMy5NF+E01uGhoP3zDRKVswzYg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
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 13:34:23 -0000

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?

>
>
>     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 and it requires 
modifications to the application protocol, e.g., to the 2p filesharing 
protocol where the tokens would need to be exchanged.

It is necessary to take 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 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
>

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