Re: [ogpx] revised draft charter for OGPX working group

[Meadhbh Siobhan <[e-mail]>]

again. dave, many of the questions you raise _are_ covered in the
intro and requirements doc.

On Sat, Jul 18, 2009 at 11:39 AM, Dave CROCKER<[e-mail]> wrote:
> (Apologies for the length of this note.  It opened a door, and I've tried to
> make it as short is practical...)
>
>
> Meadhbh Siobhan wrote:
>>
>> @dave crocker . mmm... good feedback, but i think a number of us
>> thought this was such a large design space that it was appropriate to
>> move some details out of the charter and into the "intro and
>> requirements" doc.
>
> The fact that it touches such large problem, design and solutions spaces is
> a problem, not a benefit.  If the group is to have any focus, it needs to
> say what it is going to work on, rather specifically.  Otherwise it will
> spend forever trying to decide just that.  I believe that, in fact, there is
> a core of folk, here, who share a specific set of choices.  That's what
> should be documented. And it needs to be documented in a way that those of
> us outside that core -- and even outside the world of experts in VW, but
> with protocol design experience -- can understand.
>
> A charter says what work is to be done.  It needs to have enough detail for
> that statement to be meaningful to outside readers, so they can tell whether
> they want to participate, and to give focus to folks working within the
> group, so that they know not only what the group is trying to do, but what
> it is NOT trying to do.
>
> The "charter and then figure out what we are going to do" approach only
> works with a topic and participants who have extensive history and focus
> doing similar work.  As soon as the topic is this interesting (ie, complex)
> and this unfamiliar to open standards space and has this potential diversity
> of participation, the group usually has difficulty getting adequate
> agreement.  For one thing, there is no charter -- ie, group contract -- for
> reining in participants who want to push the group into stray areas.
>
> By way of being more concrete, here's a version of the charter with some
> re-working and some comments I've already shared with a few folks privately:
>
>
> -----
>
>
> My original posting to the ogpx list was because there are some very basic
> things that I could not discern from the current draft charter. Things that
> I'd expect from any charter.  As a small example, the first paragraph of the
> charter does not satisfy the requirements of the Working Group Guidlines and
> Procedures document.  Even without that requirement, I see the semantics of
> the paragraph reducing to: "VW is popular and we should do some standards
> work on it."  That's not my trying to be clever or nasty.  I mean that is
> literally all of the paragraph's semantics.  I mean that quite literally:
>  it provides no substantive information to a typical charter reader, in
> terms of specific problems to be solved, capabilities to be enabled or
> protocols to be specified.
>
> As for the Guidelines requirement(Section 2.2), the essential point is that
> the first paragraph is circulated independent of the rest of the charter and
> needs to serve as an abstract, a summary of what the working group is going
> to accomplish, as a technical effort:
>
>     "The first
>      paragraph must give a brief summary of the problem area, basis,
>      goal(s) and approach(es) planned for the working group.  This
>      paragraph can be used as an overview of the working group's
>      effort."
>
>
> By way of a deeper example of the draft's problems please note that the
> draft provides no technical explanation for any of the domain that it will
> be working on.  So it uses many terms, such as "virtual worlds" without any
> technical basis.  Let me be clear:  As a technical term, I do not know what
> it means and what it does not mean.  Really.  But I've got enough technical
> and standards experience that I should be able to read a charter and tell
> what is and is not being solved and created, that is, what the concrete
> value proposition is.  But here, I can't.
>
> If one already is an expert in the topic, then this stuff is probably clear,
> although I'll also note that the technical perspectives of long-standing VW
> workers appears quite divergent, based on the mailing list discussions I've
> seen.  This is what I'd expect for something with a long proprietary history
> but
> just entering standardization.  If these disparities persist, it is going to
> be
> virtually (...) impossible for different views to be understood, nevermind
> reconciled.
>
> When a topic is well-established within the profession, no its nature and
> technical implications don't need to be explained.  But here, yes, we have
> something that is relatively new and a community that has little or no
> experience developing standards for it.
>
> I believe this is a very basic difference, and one that greatly increases
> the risk of failure.  Over the years, I've come to believe that the
> technical work of standards is actually the easiest part.  Getting everyone
> on the same page about the problem to be solved and the functionality to be
> created seems to be the hardest.  This requires common perspective and
> vocabulary. I believe that most working group efforts fail because they do
> not take care of these basics, along with failing to limit scope
> sufficiently... BEFORE chartering.
>
> While I do realize that a number of the folk participating in this effort
> have extensive background in this topic and very much ARE on the same page,
> the question is whether this is to be only a sandbox for them or whether it
> is to be started and run in a way that encourages participation by others.
>  I hope the latter; it makes the chartering and management side a lot more
> difficult, but the results a lot more useful, IMO.
>
> With respect to explaining terms and concepts, in between a 10-page tutorial
> and a complete lack of any explanation, there can be summary information and
> pointers.  I give the barest hint of this, below, in a revised the draft.
>  No doubt it's insufficient.  A bit -- but only a bit -- more tutorial text
> and some well-placed citations, would probably be sufficient.
>
> Side comment:  The charter's repeated use of "application-layer" is
> something I find distracting, since I do not know what technical import it
> has, but its use implies substantive import.  (By contrast, I don't mind
> saying "transport" when citing HTTP -- even though HTTP is classed as an
> apps protocol -- because it properly characterizes the actual role HTTP, or
> the like, will play for this work.)
>
> Equally, is the group:
>
>   1. Starting from scratch and creating brand new protocols,
>
>   2. Starting with some existing ones but using them only for guidance,
>
>   3. Starting with existing ones but making whatever major changes are
> deemed "useful", or
>
>   4. Starting with existing ones and making only "essential" (and minor)
> changes?
>
> Each of these choice has a history of sometimes being appropriate, but they
> entail wildly different charters and types of work.
>
> My guess is that the group's intention is #2 or #3, but I really can't tell
> from the charter or from the mailing list discussion.  Also, to the extent
> that documents are being used as input, they need to be cited.  I see that a
> number have been released as Internet Drafts that look extremely helpful.
>  They need to be cited, and in terms of the 1-4 list, above.
>
> Let me stress that what I am referring to is quite different from trying to
> get them to agree on resolving differences in solution paradigms.  So I'm
> not suggesting that ogpx should really try to do what mmox couldn't. Rather,
> the ogpx work should at least be accessible to others.  Folks from other VW
> disciplines and folks from other protocol experience.  Based on the current
> draft charter and the discussion on the list, it isn't. Too much jargon and
> too
> little explanation.  On the other hand, there were some constructive
> responses
> to my query, until you posted a request not to pursue it.
>
> In addition, the charter is filled with references that have no obvious
> technical meaning.  As such, the text does not really provide much
> meaningful
> guidance about goals and scope, except in the most generic terms.
>
> I've attempted to do some re-working of the draft text, at least fixing the
> first paragraph, but could not get very far with the remainder, because I
> found
> so much of the remaining text in need of significant clarification.
>
> Here's what I got, along with the questions:
>
>
>      {{ Open questions are marked by {{...}} }}
>
>
> Description of Working Group:
>
>      Virtual Worlds (VWs) and other Massively Multi-Party Online
>      Applications (MMOs) are simulation environments consisting of many
>      objects, object types and virtual actors and users (participants).
>  There
>      are many examples VW and MMO applications, most using proprietary
>      protocols. With their roots in games and social interaction, Virtual
>      Worlds are now being used increasingly in business, education and
>      information exchange. The working group will develop a protocol to
> enable
>      user clients to access multiple, independently-operated servers. It
> will
>      also permit servers to share simulation objects and user participant
> data.
>      For example, a user  will be able to have a single, unique presence
> among
>      independent services.  The Open Grid Protocol (OGP) will describe
>      semantics and protocol  interaction for the virtual world, independent
> of
>      transport, though bindings for carrying OGP over HTTP will be defined.
>      {{ one protocol or multiple?  the draft charter says "The objective of
> the
>         OGPX working group is to provide an application-layer wire protocol
> "
>         and "the Open Grid Protocol suite (OGP), a set of application
>         protocols".  Which is it? }}
>
>      The Open Grid Protocol will define virtual worlds with the following
>      assumptions:
>
>      *     The Virtual World exists independent of the participating
> clients.
>            {{ what does this mean? }}
>
>      *     Users have a single, unique presence in the virtual world.
>
>      *     The virtual world contains persistent objects.
>            {{ define persistent }}
>
>      *     The virtual world may be partitioned
>            {{ define partitioned }}
>
>      *     Presence, state and simulation occur on authoritative hosts.
>            {{ where else might they occur?  what choice is being made here?
> }}
>
>
>      Foundational components of the Open Grid Protocol include the
> publication
>      of:
>
>      1.    an abstract dynamic structured data system, suitable for
> describing
>            the application protocol in a transport-neutral manner,
>            {{ what does dynamic mean, here?  what is the alternative? }}
>
>      2.    clear semantics and mechanisms for carrying OGP messages over
>            message-oriented transports with request/response semantics,
>            {{ UDP is a 'message-oriented' transport, but I suspect that's
> not
>               what is meant. }}
>
>      3.    guidelines and mechanisms for host and user authentication and
>            confidentiality,
>            {{ OGPX will define authentication mechanisms? Perhaps is means
>               "Guidines for using existing mutual authentication and
>               confidentiality mechanisms"? }}
>
>      4.    an application-layer protocol for establishing the user's
> presence,
>            {{ is 'establishing a presence' different from logging in?  if
> so,
>               how?  if not, why not say log in? Given Item #3, I'm guessing
>               this item does NOT mean logging in, since that's the same as
>               authentication, isn't it?  Perhaps this item's calling for
>               creating a presence protocol, given that a couple already
> exist
>               and are used, conflicts with the "use existing" approach of
> item
>               #3.  Why invent a new one?  (There might be a good reason to,
> but
>               it should be justified and maybe debated.) }}
>
>      5.    an protocol for moving a user's presence from one authoritative
> host
>            to another,
>            {{ if there are "authoritative" hosts, what other kinds of hosts
> are
>               there? }}
>
>      6.    format descriptions for objects and avatars in the virtual world,
>            {{descriptions=specifications?  and avatars are not objects?
>  what
>            are they? }}
>
>      7.    an application-layer protocol for identifying agents, and
>            requesting information about them.
>            {{ is this client/server or server/server?  this is a distinct
>               protocol, from any other ogpx work?  what does it mean to
>              "identify" agents? }}
>
>
> d/
>
> --
>
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
>
>
> --
>
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
>