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

Izzy Alanis <izzyalanis@gmail.com> Tue, 05 April 2011 03:00 UTC

Return-Path: <izzyalanis@gmail.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 4E0083A6840 for <vwrap@core3.amsl.com>; Mon, 4 Apr 2011 20:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level:
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 oDpx2bLOreEz for <vwrap@core3.amsl.com>; Mon, 4 Apr 2011 20:00:33 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B06D63A6866 for <vwrap@ietf.org>; Mon, 4 Apr 2011 20:00:32 -0700 (PDT)
Received: by fxm15 with SMTP id 15so4967890fxm.31 for <vwrap@ietf.org>; Mon, 04 Apr 2011 20:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OpgUR6PqQ7dfQ7lNwEOsdaB4cBvYal47p6AWv/S+Y60=; b=C28I260P60hfRTXk98DX8X+L9n9gCPJ5yGUET2d5H6XB5y3+Ds1O4PP71njanNkt/l +UEoGczxVxflExqm2f9I39nrOvSeULz1EyRZRuipuiC981P2WDXlIrtstr8K3wTXKkod H7uVFnF7lVRcTqTfhbsRc9bjxjIVPNjYC1Xwk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Nb+9xcN7uJy/rOA2jctnLghfujvEG/CyzFv2x9JSa+ceTid4iqd/XuMuXmW2qyz7/b LR3ZYvA6nN2SLZJk0bo6bF6u+SUOhhVc55iyDXbFnV5cE9clfayQ4qlX0NTxnUSUGqHT hKFIrtlY2tE2YzYQuQtpTzbi/UARjZAAJin1Q=
MIME-Version: 1.0
Received: by 10.223.63.212 with SMTP id c20mr1114903fai.63.1301972535034; Mon, 04 Apr 2011 20:02:15 -0700 (PDT)
Received: by 10.223.81.66 with HTTP; Mon, 4 Apr 2011 20:02:14 -0700 (PDT)
In-Reply-To: <AANLkTimcMbrJzXYTvs0cszn+rhH4ygEPvzvLwu94gr-4@mail.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>
Date: Mon, 04 Apr 2011 23:02:14 -0400
Message-ID: <BANLkTi=hL5YTAW9_V7EA3C3fiknU0o_ARA@mail.gmail.com>
From: Izzy Alanis <izzyalanis@gmail.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: vwrap@ietf.org
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 03:00:34 -0000

I applaud the effort to further the documentation... but, what does it
mean to say "then that change is accepted as part of VWRAP"?

> * Whenever a change X in the protocol is proposed (which might be
> an addition, a change of existing protocol or even deletion: any
> change, making the protocol > *# (VWRAP) go from A --> B), then
> that change is accepted as part of VWRAP provided that:
> *# Protocol B can do everything that A could do.
> *# Good use-case justification for B is provided.
> *# Implementation requirements of B are listed.

Things that have *consensus* become part of the protocol. If changes
meet reasonable criteria (such as the above), they will be more likely
have consensus. Changes that do things like break backwards
compatibility or limit 'flexibility' will likely be hard to get
consensus on.

But I agree with Mike when he said "We don't need to make a process
that forces agreement under a set of terms...".

That's not an argument against flexibility. But I do question why we
need to have consensus on this abstract meta-issue? Do we really need
explicit written consensus on overly general principles like
"flexibility is good", or "scalability is good" or "sunshine and
puppies are good" to make progress? Specific features and details will
or will not become part of the protocol based on their merits.

If a minority interest (a potential "vetoer") has no interest in a
particular use case, and their concerns are resolved or mitigated --
by limiting the impact to their implementation of the previous version
of the protocol, making the change/proposed feature optional, etc --
then we can still reach consensus. Consensus doesn't mean unanimity.



On Fri, Apr 1, 2011 at 11:01 AM, Morgaine
<morgaine.dinova@googlemail.com> wrote:
> I agree 100% with every point made by Carlo in this post.
>
> Please note that I have extended Carlo's 2-clause proposal from his earlier
> email, because in his original formulation, flexibility in the protocol is
> easily vetoed by backward-looking detractors or vested interests.
>
> My formulation is here --
> http://www.ietf.org/mail-archive/web/vwrap/current/msg00637.html .  I am
> sure it can be improved still further.
>
> My goal is that (i) new areas of flexibility should be justified by use
> cases and supported by engineering solutions, and (ii) not subject to veto
> by those who are not interested in those use cases.  That's how you make
> technical progress.
>
>
> Morgaine.
>
>
>
>
> =====================
>
> On Fri, Apr 1, 2011 at 3:13 PM, Carlo Wood <carlo@alinoe.com> wrote:
>>
>> On Wed, 30 Mar 2011 14:27:27 +0000
>> "Dickson, Mike (ISS Software)" <mike.dickson@hp.com> wrote:
>>
>> > 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.
>>
>> Nobody forces you to anything. I'm asking if there is consensus
>> about this point. Frankly, I'm disappointed that you disagree
>> already - at THIS level of abstraction. Perhaps it's caused by
>> a false sense of fear that you would be forced to accept things
>> into the protocol: you clearly want control. You want to decide
>> on a case by case basis if you like it or not.
>>
>> But hell, that is NOT possible at this abstraction level.
>> Please rethink carefully what the proposal means: do you REALLY
>> want to reject the Ideal of an open protocol that doesn't deny
>> support for use-cases that YOU don't want?
>>
>> >  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.
>>
>> I don't see the 'etc' here. And IF the minimal support that
>> an implementer would have to add who does NOT needed X would
>> lead to instability then surely you wouldn't be able to speak
>> of "No substantial extra demands are being made"!
>>
>> If implementation is so difficult, even for implementers NOT
>> needing it, that it causes the danger of instability then you
>> have EVER possibility to go against it, even if now you agree
>> with the Principle of trying to be flexible.
>>
>> > 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.
>>
>> I am not really sure how this applies to making the choice if
>> you want to be flexible, or - put differently - want to cripple
>> the protocol to make certain applications of it impossible.
>>
>> >  And I don't buy the "evil corporate interests" argument.
>>
>> ... unless this is the case. And you just want to win a battle
>> before it started.
>>
>> >  Ideally if we do this right there *should* be some participation
>> > from business interests that are looking at the space.
>>
>> A flexible protocol would be superset of what those businesses
>> need (see point 1: Protocol B can do everything that A could do).
>> So, if they would be interested when the protocol can only do A,
>> please explain why they won't be interested anymore when it
>> can do B?
>>
>> > Mike (speaking as me and not for HP)
>>
>> --
>> Carlo Wood <carlo@alinoe.com>
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/vwrap
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>