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

"Y. Richard Yang" <> Thu, 27 September 2012 23:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E20C21F8599 for <>; Thu, 27 Sep 2012 16:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.976
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jzrOu-52uftn for <>; Thu, 27 Sep 2012 16:44:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2E6A821F8594 for <>; Thu, 27 Sep 2012 16:44:01 -0700 (PDT)
Received: by obqv19 with SMTP id v19so2849527obq.31 for <>; Thu, 27 Sep 2012 16:44:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mFWapuijgLvUNj5IO/MSIHSWpafmxnz45sI1IrlpO80=; b=hfUBz9nk9+C6DXkGbM8zE5+UxNYb4q5uvBYjV/LONkJ2+iW0BR4Da42EP8PWy5VPHY Mx8if2zM4aJiEw6iCn2H4Cx0Qfxokh34kbLdzydyDeIpldD7jZ9f6hXqu8PLXOsPNVqb O9IqENp6ybJmu3uRxwDU5L33K7eSsjDq2TzntNKd9/96ZKICUWBg0CQhKGzSEwT+N6tn eNf2H52vBRVA8rJxYoigKGkhGuBqJoqnetT8KW7El5f7//uGTn/MzrgwYWu71DrA4HMa MzX0IygMNjUuZ9YPvN6kktCzUmxXXo8AYiJXh/tNla5cyAHeheicBvR1UoJUWEOaX0DO yuQw==
MIME-Version: 1.0
Received: by with SMTP id d2mr4609532oec.110.1348789440691; Thu, 27 Sep 2012 16:44:00 -0700 (PDT)
Received: by with HTTP; Thu, 27 Sep 2012 16:44:00 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Thu, 27 Sep 2012 19:44:00 -0400
X-Google-Sender-Auth: mp730cg672mUAp0k_5T8drTSZbI
Message-ID: <>
From: "Y. Richard Yang" <>
To: "Y. Richard Yang" <>
Content-Type: multipart/alternative; boundary=e89a8ff256727d3c8e04cab783dc
Cc: "" <>, Martin Stiemerling <>
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Sep 2012 23:44:02 -0000

On Thursday, September 27, 2012, 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!
>> 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!

Let me add to this. As a researcher, I am always impressed by human
ingeninuity.  As an example, in my today's lecture on wireless
networks/mobile computing, we discussed how to handle ISI. After so many
years, I am still impressed by the endless human ingenuity in handling the
problem, wave shaping, vertibi, ofdm, rake receiver... You learn to be
humble. One key research strategy in my group is also to come up with
surprising solutions. This approach works well and we are the few who
consistently publish in sigcomm, the most competitive networking
conference. Hence, in the requirement specification setting, we make sure
that it is possible, by coming up with a solution ourself, and then post
the requirement. We are humble, but not incapable. I am puzzled that you
did not ask these questions in your tenure as the AD so that we can
help/clarify. This is one piece of the puzzle why we were hugely surprised
by the unexpected closure.


>> why it has been pushed back to the WG, and why this is one piece of the
>> puzzle why the DECADE was closed.
>>   Martin
>> --
>> NEC Laboratories Europe - Network Research Division NEC Europe Limited
>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>> Registered in England 283