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

Mike Dickson <> Wed, 30 March 2011 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81E463A6B7D for <>; Wed, 30 Mar 2011 08:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.679
X-Spam-Status: No, score=-101.679 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FoINpP220FFo for <>; Wed, 30 Mar 2011 08:39:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DE5743A6B61 for <>; Wed, 30 Mar 2011 08:39:08 -0700 (PDT)
X-Authority-Analysis: v=1.1 cv=2pE2Kh9Ye2ywHyyFZnC5ZQ1FvuPrdOtuPO5uN4ysVDU= c=1 sm=0 a=SNAFxGGoWQUA:10 a=IkcTkHD0fZMA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:17 a=cH6R9-kdAAAA:8 a=48vgC7mUAAAA:8 a=ZVnC9hWN30Gu0FJL59MA:9 a=5VfERT56rQ_mKVTSldEA:7 a=Doc7XZBrJyK6ReruHgjxaDX6LSAA:4 a=QEXdDO2ut3YA:10 a=bt0zGP92IBIA:10 a=lZB815dzVvQA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:117
X-Cloudmark-Score: 0
Received: from [] ([] helo=[]) by (envelope-from <>) (ecelerity r()) with ESMTP id 47/31-05159-FFE439D4; Wed, 30 Mar 2011 15:40:47 +0000
From: Mike Dickson <>
To: Morgaine <>
In-Reply-To: <>
References: <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 30 Mar 2011 11:40:45 -0400
Message-ID: <1301499645.12359.10.camel@mdickson-hplinux>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14)
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [vwrap] Statements of Consensus. Flexibity First.
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2011 15:39:15 -0000

On Wed, 2011-03-30 at 15:23 +0000, Morgaine wrote:
> Mike, if you don't need the flexibility available in a protocol,
> simply don't use the flexible features that you don't want.  But
> denying those who require a flexible and extensible protocol with a
> degree of future-proofing to it is, I believe, not in line with the
> goals expressed here from the start of this process.

That's not actually consistent with what I thought Carlo wrote.  There's
only one set of specs and I didn't see a commitment to backwards
compatibility, only that flexibility to evolve features would take
precedence over other factors.  And honestly all of this is moot.  I'm
not personally going to agree to any overriding principle other than to
participate in the process and try and reach consensus in the documents
produced. This whole discussion is a proverbial "red herring".  We don't
need to agree on how to produce consensus we need to agree on what goes
into the documents.

> Perhaps closed enterprises don't need flexibility, but open
> communities certainly do, and they are typically long-lived and hence
> require the ability to evolve and to adapt to change.  And open
> communities most certainly need interoperability between their many
> virtual worlds.

I personally believe that focusing on services definitions and interop
will produce the needed "flexibility" your after.   I really want that
level of flexibilty (to be able to compose "virtual worlds" flexibly)
hence the reason I think focusing on the services is important.  And I
doubt that corporate needs and individual needs are that different in
this respect. Use models for VW technologies are still evolving.

> The needs of inwardly-focused companies do not override the needs of
> open Internet communities.  This IETF protocol project serves both
> sets of interests, and it will need to satisfy both sets of
> requirements.

Yes, I get that. I have lots of standards experience, even serving on
the board of one organization in the past.  I honestly find the whole us
vs. them rhetoric tiring.  A healthy community will include both
individual and corporate interests.  And its to be expected that they'll
all argue from their respective POV.  That's healthy.


> Morgaine.
> ========================
> On Wed, Mar 30, 2011 at 3:27 PM, Dickson, Mike (ISS Software)
> <> wrote:
>         On 03/30/2011 03:14 AM, Carlo Wood wrote:
>         > Perhaps we should also start a wiki page (it's nice
>         > to have a stable url that one can refer to, which still
>         > is editable; that give me at least a feeling of progress),
>         > about statements that we reached consensus over.
>         We don't need to make a process that forces agreement under a
>         set of terms.  That's not how the IETF
>         works.  We need consensus and documents.  As a contributor
>         I'll choose to agree or disagree based on
>         the topic.  And in some cases I'm not sure I'd choose
>         flexibility over stability, etc.
>         It seems to me we've sorted drifted to a point we're there are
>         2 camps and a proposal was made for how to
>         deal with it.  There are those that want to work on service
>         level interop.  And others want to define the
>         whole concept of virtual world interop. IMO we need to either
>         agree that seperation exists and arrange the
>         docs so it describes the 2 work streams or agree that we can't
>         agree and disband.  The service level interop.
>         is a subset of the other and given our track record I prefer
>         to walk rather than run.  And I don't buy the "evil
>         corporate interests" argument.  Ideally if  we do this right
>         there *should* be some participation from business
>         interests that are looking at the space.
>         So in summary, no, I'm not going to agree to a fixed process
>         that favours flexibility.  The IETF already has
>         a process for how this stuff gets worked.   And we need to
>         decide what we're working on and move on. I
>         think there's room for 2 work streams here and that personally
>         would be my vote.  I'll put my energy into
>         service level interop personally.
>         Mike (speaking as me and not for HP)
>         _______________________________________________
>         vwrap mailing list