Re: [vwrap] Statements of Consensus. Flexibity First.
Izzy Alanis <izzyalanis@gmail.com> Tue, 05 April 2011 17:09 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 713D728C125 for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 10:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.529
X-Spam-Level:
X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 rHKdT3gd5gVn for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 10:09:37 -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 7616E28C120 for <vwrap@ietf.org>; Tue, 5 Apr 2011 10:09:37 -0700 (PDT)
Received: by fxm15 with SMTP id 15so487323fxm.31 for <vwrap@ietf.org>; Tue, 05 Apr 2011 10:11:20 -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=angyXClT+x76vZe/3Aj1JVO53gIs4D8NMLbCD79b6qE=; b=dPctyaH8ZiQDTaV28ATW5qSgb2md05CTZOyPAmwW4UDEMdOLlruKyCE25WdQGnMiO5 o+KEGNEJVE5Z2QTPqWbT3k96WEbZ06sbZmvrcgSpmL4sKwhxe4wrFcYfSHC8otiaNWGG 4ZNbwBwrdoK0lhxdwlRuQQ1mvzJdiIZCMBNZI=
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=NY1Ga6lrJnhIgcjvH0Bj+rclTda3ftisGsINgfq6m4oi8xm7vjlNT0efOj0y8CSbOP jWo1GzJP0Iyb2oSB7W2CsU4UO0ZeyV39GMoMaAhB7+zjUpSpMoO1FV6dHdvuhsH/KEKU T+NB44ln1RRq1aRgnD+deXJxblj2Jtuw1ir0M=
MIME-Version: 1.0
Received: by 10.223.2.8 with SMTP id 8mr20359fah.82.1302023016925; Tue, 05 Apr 2011 10:03:36 -0700 (PDT)
Received: by 10.223.81.66 with HTTP; Tue, 5 Apr 2011 10:03:36 -0700 (PDT)
In-Reply-To: <AANLkTinRxwgM35yzC-nsukojX2EuFoo0O93hUQd0PUMB@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> <AANLkTinRxwgM35yzC-nsukojX2EuFoo0O93hUQd0PUMB@mail.gmail.com>
Date: Tue, 05 Apr 2011 13:03:36 -0400
Message-ID: <BANLkTiknjmCFfFz1NsYjrit18Vyais7S_Q@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 17:09:39 -0000
I'm not against the "design for tomorrow" platform. I'm pro-"design for tomorrow", but I believe the proposition, as currently worded, does not appropriately communicate those intentions. I could agree with the following wording (though I still don't believe it communicates your 'design for tomorrow intentions'): * 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 *# Protocol B SHOULD do everything that A could do. *# Good use-case justification for B MUST be provided. *# Implementation requirements of B MUST be listed. On Tue, Apr 5, 2011 at 12:30 AM, Morgaine <morgaine.dinova@googlemail.com> wrote: > 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 >> > >> > > >
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Boroondas Gupte
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dickson, Mike (ISS Software)
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- [vwrap] Statements of Consensus. Flexibity First. Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Boroondas Gupte
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis