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 >> >
- [decade] WG Action: Conclusion of Decoupled Appli… IESG Secretary
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Konstantinos Pentikousis
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- Re: [decade] WG Action: Conclusion of Decoupled A… Konstantinos Pentikousis
- Re: [decade] WG Action: Conclusion of Decoupled A… Carsten Bormann
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Konstantinos Pentikousis
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- Re: [decade] WG Action: Conclusion of Decoupled A… Songhaibin
- Re: [decade] WG Action: Conclusion of Decoupled A… Songhaibin
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- [decade] 答复: WG Action: Conclusion of Decoupled A… Guyingjie (Yingjie)
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] 答复: WG Action: Conclusion of Decoupl… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang