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

Carlo Wood <carlo@alinoe.com> Fri, 01 April 2011 13:56 UTC

Return-Path: <carlo@alinoe.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 7DA423A681C for <vwrap@core3.amsl.com>; Fri, 1 Apr 2011 06:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level:
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, SARE_FWDLOOK=1.666]
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 s88yG5uag5Ps for <vwrap@core3.amsl.com>; Fri, 1 Apr 2011 06:56:26 -0700 (PDT)
Received: from fep11.mx.upcmail.net (fep11.mx.upcmail.net [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id EA8613A67FA for <vwrap@ietf.org>; Fri, 1 Apr 2011 06:56:25 -0700 (PDT)
Received: from edge02.upcmail.net ([192.168.13.237]) by viefep11-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110401135805.DAPQ17007.viefep11-int.chello.at@edge02.upcmail.net> for <vwrap@ietf.org>; Fri, 1 Apr 2011 15:58:05 +0200
Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upcmail.net with edge id SDy31g02G0FlQed02Dy4mq; Fri, 01 Apr 2011 15:58:04 +0200
X-SourceIP: 77.250.43.12
Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from <carlo@alinoe.com>) id 1Q5erT-0005Gr-Ds for vwrap@ietf.org; Fri, 01 Apr 2011 15:58:03 +0200
Date: Fri, 1 Apr 2011 15:58:03 +0200
From: Carlo Wood <carlo@alinoe.com>
To: vwrap@ietf.org
Message-ID: <20110401155803.427b2727@hikaru.localdomain>
In-Reply-To: <AANLkTin0g9FxkKDTyV3YsNK+v2LrCtu_FoYuBxNdsCdv@mail.gmail.com>
References: <20110330011458.GB8908@alinoe.com> <AANLkTin0g9FxkKDTyV3YsNK+v2LrCtu_FoYuBxNdsCdv@mail.gmail.com>
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Cloudmark-Analysis: v=1.1 cv=vUpxTctd+kpWCBtSXXIkt5ll4Z8E5Qu9nLREXC/hfIo= c=1 sm=0 a=SNAFxGGoWQUA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=mK_AVkanAAAA:8 a=klfZn6QLZ_uFIorRAXYA:9 a=51XBOe0O6TobSm34TxkA:7 a=CjuIK1q_8ugA:10 a=9xyTavCNlvEA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
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: Fri, 01 Apr 2011 13:56:27 -0000

On Wed, 30 Mar 2011 10:01:33 +0100
Morgaine <morgaine.dinova@googlemail.com> wrote:

> Carlo, your suggested paragraph for consensus is a good one, but is
> too easy to evade .  It makes it trivial for a detractor to argue
> that "substantial extra demands are being made [by B] on an
> implementation that only implements the functionality of A", because
> every B will impose extra demands on A."  That exception contains the
> recipe for neutralizing all progress.

True... it might be too vague and senseless discussion might
take place about what is substantial... Therefore I hope that
by far most, if not all, people involved TRUELY think, like me,
that in principle the protocol should support everything that
is even remotely possibly necessary for some use case. Especially
when it adds no complexity for those implementers who aren't
interested in the extra functionality.

For example, someone could propose to add 'X' that would allow
something that 'Grid Y' doesn't want on THEIR grid. However,
all that is required for them is to add a single parameter to
some protocol message, ie - the parameter FALSE, to signal they
don't want it. Then based on that it should be impossible to
try and bar support for X from the protocol itself: Y would
be "forced" to add that 'FALSE' in order to support X passively.

> Instead of providing such an easy opportunity for veto by people who
> only want A, place the onus on the people requiring B, which is much
> more forward looking.  I suggest something like this: 
> 
>    - 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:
> 
>    1. Protocol B can do everything that A could do.
>    2. Good use-case justification for B is provided.
>    3. Implementation requirements of B are listed.

Although I do not protest against the reformulation,
I have to note that it's as easy to go against point 2:
people can always argue that it's not a "good use-case";
and it isn't in their eyes when they are really opposed
to the whole idea.  Therefore I think it's better to
say something like: if two or three people think it's
a good use case. After all, the whole idea is that those
who don't think that it is, will have to ability to
not support it on their grid, but should not have the
ability to bar it from the protocol.
 
> This would make it clear that features are incremental (A+B must
> always be a superset of A), offer an initial level of technical
> detail about how functionality B can be achieved, and most
> importantly, make everyone aware of the impact that B has on A.  It
> will also ensure that an implementation that provides A but not B is
> by choice a subset implementation.

I don't see it like that. A 'subset' seems to suggest
incompatiblity. For example, if one world allows it's visitors
to use assets from any source, including their own harddisk,
while another world doesn't want to allow that for various
(non-technical) reasons, then the protocol had to support it
nevertheless. The latter world would just reply differently
to certain protocol messages, but still be within the protocol
and AWARE of the possiblity that allowing it is possible.
They'd only refuse it.

I don't really see that as supporting a subset of the protocol,
if you understand what I mean.

Carlo Wood