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

Morgaine <morgaine.dinova@googlemail.com> Wed, 30 March 2011 08:59 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 3BE6C3A6919 for <vwrap@core3.amsl.com>; Wed, 30 Mar 2011 01:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.81
X-Spam-Level:
X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1, 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 COZ75sv7OeIQ for <vwrap@core3.amsl.com>; Wed, 30 Mar 2011 01:59:55 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id A7D333A6957 for <vwrap@ietf.org>; Wed, 30 Mar 2011 01:59:55 -0700 (PDT)
Received: by qyk7 with SMTP id 7so716496qyk.10 for <vwrap@ietf.org>; Wed, 30 Mar 2011 02:01:34 -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:content-type; bh=7xwr7aHNvjGWWwcu3rpPAST5eloZ9/HGYLPG/Lvzpek=; b=QPLjGc2wcNgmCWEo5SEZzivcf+YqFTtfMIR2vJyP5q+Cy3yodngC4bOnn8oVbQk2OX rpdgOuYwCqEm1gZ7s+Oy4M+2QPkiMCUbEaCDLSLRvk8SpkCcTaU2oYnz31xYh62bj12f P6d2pEaT8Awsvgywbp7SoSR5U1g1s6eSGTemk=
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 :content-type; b=AilPll31lx3uI518mignWAs7V6deo8u+Zrw2j5bGwQ7gsYy+FVtDW3c8o8vN/3RyDb FnM7rZss+TzZX8zOg27iUcP7nS67tfxsDivGJ/mnMsLXutFYWrZtrNR4TcOOrD/KqvTs iUVr5vmraOAjwIudRiZPY0XwFAannjc+l6PkM=
MIME-Version: 1.0
Received: by 10.229.62.8 with SMTP id v8mr796065qch.33.1301475693949; Wed, 30 Mar 2011 02:01:33 -0700 (PDT)
Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 02:01:33 -0700 (PDT)
In-Reply-To: <20110330011458.GB8908@alinoe.com>
References: <20110330011458.GB8908@alinoe.com>
Date: Wed, 30 Mar 2011 10:01:33 +0100
Message-ID: <AANLkTin0g9FxkKDTyV3YsNK+v2LrCtu_FoYuBxNdsCdv@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary=90e6ba180db26bf357049faf6c61
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: Wed, 30 Mar 2011 08:59:57 -0000

I support Carlo's call for maintaining a page on the IETF wiki that lists
requirements and implementation details in a concise format,and hence marks
our progress along the path.  The items on the wiki would then be required
to be included in subsequent released specification drafts, at least through
placeholders.

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.

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.


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.


Morgaine.





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

On Wed, Mar 30, 2011 at 2:14 AM, Carlo Wood <carlo@alinoe.com> wrote:

> Perhaps we should also start a wiki page (it's nice
> to have a stable url that one can refer to, which still
> is editable; that give me at least a feeling of progress),
> about statements that we reached consensus over.
>
> Being an abstract thinker and analyst, I believe we
> can tackle many of the current discussions at a much
> higer abstraction level first, making it easier, or
> even possible, to deal with the more detailed points
> of discussion.
>
> I'd like to start with one such statement and ask
> for consensus on it (and if not, give your rationale
> why not).
>
>
> * 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) No substantial extra demands are being made on
>     an implementation that only implements the
>     functionality of A.
>
>
> In other words: we choose for flexibility.
>
> Under no circumstances we want the *protocol* itself
> to be a limitation in what is possible, when that
> extra flexibility/possibility doesn't cost much for
> those not needing or using it.
>
> Companies be warned: that DOES mean that you lose
> control: sometimes it is "nice" if it's impossible
> to do with a protocol what your company doesn't
> want. However, if that is what you want-- I'd like
> to hear good reasons for that at THIS abstraction
> level, and not while discussion details, because then
> it's too easy to go against some proposal for "different"
> reasons (not really saying that what you really want
> is that something is just not possible with the protocol,
> in order to garantee that things will deviate from YOUR
> goals and ideas).
>
>
> I sincerely hope we can reach consensus on this and
> ask everyone to give their 'yes' or 'reasons for their
> no'.
>
> --
> Carlo Wood <carlo@alinoe.com>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>