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

["Y. Richard Yang" <[e-mail]>]

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
>>
>>     --
>>     [e-mail]
>>
>>     NEC Laboratories Europe - Network Research Division NEC Europe 
>> Limited
>>     Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>>     Registered in England 283
>>
>