Re: [vwrap] Statements of Consensus. Flexibity First.

Morgaine <morgaine.dinova@googlemail.com> Tue, 05 April 2011 22:22 UTC

Return-Path: <morgaine.dinova@googlemail.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DD028C0EE for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 15:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.177, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZoDBCa8CezS for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 15:22:33 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 9ACBF3A67F3 for <vwrap@ietf.org>; Tue, 5 Apr 2011 15:22:30 -0700 (PDT)
Received: by qyk29 with SMTP id 29so1972105qyk.10 for <vwrap@ietf.org>; Tue, 05 Apr 2011 15:24:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=bAhwzqNmdlvNYTSau3R5EE+/8Zn8AgTAfPn73cn9PUQ=; b=e8sbfgSSVNtA+BVRHTarEHzeXxbo7ffAyymb8u8/FxkoNIystFdbec/nH+4brMRvi/ IDkSEPk9qkXKC0VPOSFTUifZ1oeHtKH6hvizajU8iCJ8sqN2teGHXGv8D5l2h8cy0G0b jjFg6/M8kCxcXEFv9zz6cLkD6XDo3Z2Hwy5AE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=TDM+ysH/n853Vt+dXfJXLor1bMj4B8C8XFfGnpvSWHJP0f3dvKUPyxBOU/OsNmJjHi tsBcBzXIgyBJdeqjzzRnyR8QBvQk37Uv4SbYLz7u4cs3VfuEQ09QCSeZDUlEOVxG/1jP LDtQTjd+6111wmTlVH7YPwXvQUGetSKtx0Gi4=
MIME-Version: 1.0
Received: by 10.229.78.22 with SMTP id i22mr225355qck.33.1302042253669; Tue, 05 Apr 2011 15:24:13 -0700 (PDT)
Received: by 10.229.211.84 with HTTP; Tue, 5 Apr 2011 15:24:13 -0700 (PDT)
In-Reply-To: <4D9B937C.1040403@gmail.com>
References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <AANLkTimcMbrJzXYTvs0cszn+rhH4ygEPvzvLwu94gr-4@mail.gmail.com> <BANLkTi=hL5YTAW9_V7EA3C3fiknU0o_ARA@mail.gmail.com> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <BANLkTi=hX1ne=hvFqPh_EwTV_Urryxbp_A@mail.gmail.com> <4D9B73D5.4000809@gmail.com> <BANLkTikO5qY+ZOJuMkBfMRT2Y3HjtPCLYw@mail.gmail.com> <4D9B8ADA.9000106@gmail.com> <BANLkTimgdU6mzu+Vz-yUU_33cm9VrdHR0w@mail.gmail.com> <4D9B937C.1040403@gmail.com>
Date: Tue, 05 Apr 2011 23:24:13 +0100
Message-ID: <BANLkTik+V6xfbrx07eQO-zNq9r1v03j6CQ@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary="00235429d8f40338f404a03356b2"
Subject: Re: [vwrap] Statements of Consensus. Flexibity First.
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 22:22:35 -0000

On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:

>
> Your approach, besides exploitations, has the typical problem to assume
> asset IDs are only needed and are hash-able.
>


Asset IDs are not hash-able, it is the asset data that is hashed.  The asset
identifier is the hash of the asset data using a defined hash digest
algorithm.  The asset identifier is not guessable unless you already have
access to the asset.


Morgaine.




=============================

>
>>
>> ==================
>>
>> On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol <dzonatas@gmail.com<mailto:
>> dzonatas@gmail.com>> wrote:
>>
>>    Again Morgaine, your appeals alone don't support themselves, and
>>    your ridicule is unwelcome. If you can not honestly make any
>>    serious response, please move on and don't reply to my posts just
>>    to further ridicule. It's very RUDE.
>>
>>    If you have any implementation of your hash-based idea or actual
>>    technical detailed documentation ready for implementation, then
>>    introduce it. Until then, it's stuck in your head, and sounds
>>    other's ideas just with your name on it. Plus security by
>>    obscurity makes it as moot point.
>>
>>    Documentation... ?
>>
>>    Remember people tried to take one temp variable away from the
>>    JPEG2000 int multiple/divide routine because the idea it looks
>>    good (on paper) with one less variable. Actual implementation
>>    reveals, with timed tests, it is slower when anybody takes away
>>    that one temp variable.
>>
>>    Morgaine wrote:
>>
>>        Unfortunately your response was devoid of technical content,
>>        Dzonatas.
>>
>>        If you have something technical to say about hash-based
>>        addressing, I would love to hear it.
>>
>>        I have detailed in some depth the many benefits of hash-based
>>        addressing in the article I linked, and subsequently.  If
>>        other good schemes exist, we should of course analyze them for
>>        technical merit and compare their benefits against those of
>>        hash-based addressing.
>>
>>        That's the engineering process for making VWRAP as good as it
>>        can be.
>>
>>
>>        Morgaine.
>>
>>
>>
>>
>>        =========================
>>
>>        On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol
>>        <dzonatas@gmail.com <mailto:dzonatas@gmail.com>
>>        <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>> wrote:
>>
>>           Morgaine, we mooted your hash-based idea. This does nothing to
>>           help implement asset services. The only significant point
>>        you made
>>           is some expression for optimization, not correct functionality,
>>           which is needed first
>>
>>           As for your other two, we can summarize those with public
>>           resources and flow (forward/reverse). Any more specific network
>>           topology than that only makes it harder to address. The
>>        only thing
>>           to worry about is already custom resources that overlap
>>        with newer
>>           public resources.
>>
>>           Morgaine wrote:
>>
>>               On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol
>>               <dzonatas@gmail.com <mailto:dzonatas@gmail.com>
>>        <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
>>               <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
>>        <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>> wrote:
>>
>>
>>                  Do you think we are ready to implement some asset
>>        services now,
>>                  with/without complete documentation?
>>
>>                  What more do you think is needed?
>>
>>
>>               Two or three things seem to be needed:
>>
>>                  * Defining the asset addressing concept is an extremely
>>               important
>>                    matter, almost certainly the most important matter
>>        of all,
>>                    because that determines how robust and scalable our
>>               worlds will
>>                    be.� I've already examined alternatives for that
>>        in some
>>               depth,
>>                    and the design with the best engineering properties so
>>               far seems
>>                    to be universal hash-based addressing.� I first
>>        described
>>               that
>>                    approach on the list here ---
>>
>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html
>>                    , and referred to it in various subsequent
>>        discussions.
>>
>>                  * Defining the data flows between regions, clients,
>>        and asset
>>                    services and which parameters control the flows
>>        needs to
>>               be done
>>                    before a test asset service can be implemented.�
>>        Without
>>               that,
>>                    an asset service is just a network-accessible storage
>>               service,
>>                    not an asset service in the VWRAP sense.� Network
>>        storage
>>                    services exist already, so just implementing one
>>        of those
>>               would
>>                    not advance VWRAP.
>>
>>                  * We need to examine how various deployment patterns
>>        will
>>               use the
>>                    asset services, and how the /multiple/ asset
>>        services that
>>                    interop introduces are handled.� I am working on this
>>               currently.
>>
>>
>>               None of the above is particularly hard.� I think it
>>        won't be
>>               long before we have a scheme worked out and are ready
>>        for some
>>               implementation work.
>>
>>
>>               Morgaine.
>>
>>
>>
>>
>>
>>  ------------------------------------------------------------------------
>>
>>
>>
>>               _______________________________________________
>>               vwrap mailing list
>>               vwrap@ietf.org <mailto:vwrap@ietf.org>
>>        <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>
>>
>>
>>               https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>           --     --- https://twitter.com/Dzonatas_Sol ---
>>           Web Development, Software Engineering, Virtual Reality,
>>        Consultant
>>
>>
>>
>>  ------------------------------------------------------------------------
>>
>>        _______________________________________________
>>        vwrap mailing list
>>        vwrap@ietf.org <mailto:vwrap@ietf.org>
>>        https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>
>>    --     --- https://twitter.com/Dzonatas_Sol ---
>>    Web Development, Software Engineering, Virtual Reality, Consultant
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
>