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

[Morgaine <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>