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