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

Izzy Alanis <izzyalanis@gmail.com> Wed, 06 April 2011 00:07 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 4B03A3A6881 for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 17:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.053
X-Spam-Level:
X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 iss0M12h-svu for <vwrap@core3.amsl.com>; Tue, 5 Apr 2011 17:07:43 -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 A2E963A6844 for <vwrap@ietf.org>; Tue, 5 Apr 2011 17:07:43 -0700 (PDT)
Received: by qyk7 with SMTP id 7so611506qyk.10 for <vwrap@ietf.org>; Tue, 05 Apr 2011 17:09:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:x-mailer:from :subject:date:to; bh=vSOh0OAo3vBQ00wuNXYSN5rc1vemlI42+8tQHROFHWg=; b=rJTxaLkKC66GzwTvBIJy74f1i0ipeHigGBGUuop96ptPphkq6DPo/1vKbp/VMteaI5 nSiSKi3XCJ0vPYWpff1hjwM0L7lSFwoQdpmdS1orCucMQJM3fbQiVuGmqNe0MAaHoZi7 oBM1bnnLuvk/Npo8i8uEr7lYoXmk70xkTYBlo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=PvemgplaHkfe7hZhe5xWFQk1UZ1ghFtHXVo32ilShQrxx51TN60CE48vVncoR7O/Tt 3A0y/hWmHA4WtnoxRemfv0JDru/hJuP5i/lhQDcVBGWfhtq2nE+uGKyxD5o/EIXWimk1 qqqlRWZNoqK14Z/52nRk21mUPV/rpHUwPzAcI=
Received: by 10.224.74.14 with SMTP id s14mr258727qaj.191.1302048566995; Tue, 05 Apr 2011 17:09:26 -0700 (PDT)
Received: from [192.168.1.104] (c-75-68-52-200.hsd1.nh.comcast.net [75.68.52.200]) by mx.google.com with ESMTPS id m3sm10784qck.26.2011.04.05.17.09.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 17:09:25 -0700 (PDT)
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> <BANLkTiknjmCFfFz1NsYjrit18Vyais7S_Q@mail.gmail.com> <20110405231144.4cec7412@hikaru.localdomain> <4D9B8E6B.6010409@gmail.com>
In-Reply-To: <4D9B8E6B.6010409@gmail.com>
Mime-Version: 1.0 (iPhone Mail 8C148)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <7EE0A3BB-C52C-4DEC-8928-E0D990B2487D@gmail.com>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPhone Mail (8C148)
From: Izzy Alanis <izzyalanis@gmail.com>
Date: Tue, 05 Apr 2011 20:09:13 -0400
To: Dzonatas Sol <dzonatas@gmail.com>
Cc: "vwrap@ietf.org" <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: Wed, 06 Apr 2011 00:07:45 -0000

I agree, this is a purely academic exercise, but I think Carlo wanted to practice attempting to reach a consensus. Proposal, counter proposal, discuss the ramifications of specific verbiage, etc... ;)

  - Izzy


On Apr 5, 2011, at 5:49 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:

> IETF seems to already have this nailed down on the political side. The working groups help.
> 
> Any proposal needs documentation, so that is where any consensus happens aside from implementation (actual or attempted).
> 
> We can assume succession of RFCs.
> 
> Carlo Wood wrote:
>> On Tue, 5 Apr 2011 13:03:36 -0400
>> Izzy Alanis <izzyalanis@gmail.com> wrote:
>>  
>>> 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.
>>>    
>> 
>> That completely changes the whole intent of the proposal:
>> to make progress by reaching consensus on an (abstract) goal.
>> 
>> My goal is to have less discussion about whether or not something
>> should be supported by making clear that if there is even a single
>> use case, maybe, that might need it, then why not? Then people wont
>> have to defend anymore why that use case is essential, or morally ok,
>> or not endangering the private agenda of someone. Then it's just
>> clear from the start that "Oh yes, someone might want that, so VWRAP
>> HAS to support that"... There shouldn't be any discussion about
>> something like that.
>> 
>> In your bullet points, I don't see that goal back at all anymore.
>> 
>> Worse, I oppose to it.  If A then B is NOT the same as if B then A.
>> You changed the meaning completely. What you are saying that it
>> is forbidden to even make a proposal for a change unless the result can
>> still do exactly what it could be before that. That means we can't make
>> any real CHANGES anymore. Everything we have done so far is set in
>> stone and apparently holy (correct, without errors).
>> 
>>  
> 
> 
> -- 
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
> 
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap