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

[Izzy Alanis <[e-mail]>]

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
<[e-mail]> 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 <[e-mail]> 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
>> <[e-mail]> 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 <[e-mail]> wrote:
>> >>
>> >> On Wed, 30 Mar 2011 14:27:27 +0000
>> >> "Dickson, Mike (ISS Software)" <[e-mail]> 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 <[e-mail]>
>> >> _______________________________________________
>> >> vwrap mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/vwrap
>> >
>> >
>> > _______________________________________________
>> > vwrap mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/vwrap
>> >
>> >
>
>