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

"Y. Richard Yang" <yry@cs.yale.edu> Thu, 27 September 2012 23:10 UTC

Return-Path: <yang.r.yang@gmail.com>
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 CF98021F84E4 for <decade@ietfa.amsl.com>; Thu, 27 Sep 2012 16:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 To5qnUaB-0eY for <decade@ietfa.amsl.com>; Thu, 27 Sep 2012 16:10:13 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20B7821F860E for <decade@ietf.org>; Thu, 27 Sep 2012 16:10:13 -0700 (PDT)
Received: by obqv19 with SMTP id v19so2826058obq.31 for <decade@ietf.org>; Thu, 27 Sep 2012 16:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=I9+hlwyHuW4z45f+rN/wl9oqVWGFoW4Ch6MNwRXTFW8=; b=BGA4T+gTe5GoXe52M69vxXQLXo21GiccH2mMIZoCSUJv4tcXGQn6LrOXSFnWzHq3ID IineuuWYPcTktSK+Kn+XpPmg2iMxSvFOhH6HmjmhY+PG4qd4EluZo/Hk0gCEfibkTkeS RNdAXcaIeYT/rVWQBSs4yzR40ZxqA5lm9YPZE5KPeIzWdCxbCHQ8rbmBNQjZ0UJ8aQlz ZqXqTxJ9eeYgxyFNFWlHi9s7JaMZMWCV7XT2ge1tFghkCnKLVn1Go1AJsMEcO2faM295 k6kmdkcGJp2YswQ0mWKgOO0wngOuT43B3Y6ZZs4BxORLZOk/RRdRKfmPYQ1mphF0hfYd 8Zrw==
MIME-Version: 1.0
Received: by 10.60.8.71 with SMTP id p7mr4569614oea.56.1348787412685; Thu, 27 Sep 2012 16:10:12 -0700 (PDT)
Sender: yang.r.yang@gmail.com
Received: by 10.76.152.166 with HTTP; Thu, 27 Sep 2012 16:10:12 -0700 (PDT)
In-Reply-To: <5062E5FA.7030405@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>
Date: Thu, 27 Sep 2012 19:10:12 -0400
X-Google-Sender-Auth: Ckjt1LUHr2QOnvfStIlEtzWKm_E
Message-ID: <CANUuoLrySxdD2Mmc_+5S1SivoMy5NF+E01uGhoP3zDRKVswzYg@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
To: Martin Stiemerling <martin.stiemerling@neclab.eu>
Content-Type: multipart/alternative; boundary="e89a8ff1c5549c534604cab70ab2"
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: Thu, 27 Sep 2012 23:10:13 -0000

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!


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

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
>