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

Morgaine <morgaine.dinova@googlemail.com> Tue, 05 April 2011 04:28 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 EB19E3A6886 for <vwrap@core3.amsl.com>; Mon, 4 Apr 2011 21:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.789
X-Spam-Level:
X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=0.187, 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 Dz0y8wQl+rBv for <vwrap@core3.amsl.com>; Mon, 4 Apr 2011 21:28:46 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 76E963A6877 for <vwrap@ietf.org>; Mon, 4 Apr 2011 21:28:46 -0700 (PDT)
Received: by qwc23 with SMTP id 23so877212qwc.31 for <vwrap@ietf.org>; Mon, 04 Apr 2011 21:30:29 -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:cc:content-type; bh=z53W6WDN1tXYvZvVbo/r0SBq5rqoqwHawp67jdcTzq8=; b=tbnVBijGQWRMe79z2EW7/zP/rfH9NPPhH8ITkK1kd+8xq1tGbYapbGC2anOPowaxKx eaCn/vmUP6C62nIe+gYedCfjxOhKkVLqB6qQcoXE/ub2MRAnuhgMZGawRGybmPT3E+oR fwjDl7xevh5cmiDUcJHv7n8idM7QBKvezhO9o=
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 :cc:content-type; b=rKy1/eZw8baAeOWrABa+p/Ov2nk5l+SnEhVbOdqHVhHC5XlCQMgmKFPVE8yd97Q5aS xho7nEB6HxM59op3SyLSDEhFQim4nWfjKtI5qr7+1v6tAOLMfyir3XjUXXoA/lYmLJgK 3BW+ZR8cBs8Fh/1ARnzS/87JbYPri+kL1v6nQ=
MIME-Version: 1.0
Received: by 10.229.124.145 with SMTP id u17mr6514858qcr.71.1301977828525; Mon, 04 Apr 2011 21:30:28 -0700 (PDT)
Received: by 10.229.211.84 with HTTP; Mon, 4 Apr 2011 21:30:28 -0700 (PDT)
In-Reply-To: <BANLkTi=hL5YTAW9_V7EA3C3fiknU0o_ARA@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> <BANLkTi=hL5YTAW9_V7EA3C3fiknU0o_ARA@mail.gmail.com>
Date: Tue, 5 Apr 2011 05:30:28 +0100
Message-ID: <AANLkTinRxwgM35yzC-nsukojX2EuFoo0O93hUQd0PUMB@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary=000e0cd25caef986f504a0245530
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 04:28:49 -0000

I expect that Carlo wanted prior agreement on the principle of generally
accepting superset requirements simply to avoid perpetual wrangling between
progressives and regressives.  Or if that term is disliked (nobody likes to
admit that they are regressive after all), between those who want to design
for tomorrow and those who want to design for today.

And it's not only a theoretical worry either, because we've already seen
several instances of participants not wanting to design for tomorrow, for
example in not wanting the open metaverse of VW tourism, or arguing against
open extensibility, or rejecting IPv6-specific enhancements.

I'm on the "design for tomorrow" platform, but I do recognize that if you
want the cart pulled in a specific direction then you have to be the
principle puller yourself.  You can't expect others who don't share your
interest to pull it for you.

This is why I added points #2 and #3 so that the onus is on the people who
have the superset requirements to justify them and do the design legwork for
them.

Point #1 is just as important though.  As long as a new requirement results
in a protocol that is a superset of the previous one, detractors argue
against it either because they see very strong engineering reasons why it is
bad or else they argue unconvincingly, because having your requirement
included but vetoing someone else's requirement just because you don't want
it is unacceptable.  This is why supersets are important:  they replace
one-side-wins either/or arguments by both-sides-win either/and arguments,
which gain agreement much more easily.

Funnily enough, we've already heard arguments against the motherhood and
apple pie of scalability, so I had to chuckle when I read your penultimate
paragraph. :-)

I support Carlo's suggestion very strongly.  These are such early days in
the evolution of virtual worlds that designing for today seems just plain
silly to me, and I would like to see "design for tomorrow" enshrined by
agreement.


Morgaine.





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


On Tue, Apr 5, 2011 at 4:02 AM, Izzy Alanis <izzyalanis@gmail.com> wrote:

> 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
> >
> >
>