Subject: [mmox] IETF policy question

From: Heiner Wolf <[email-masked]>
Date: Wed, 25 Mar 2009 16:20:13 -0700

Hi,

Assumed there are multiple systems with incompatible architecture,
each sophisticated and with it's own protocols.
Assumed that we as a WG do not know enough about the general problem space.
Assumed that there are sub-groups which know enough about their
problem and have working solutions.

What would the IETF do?
1. task one of the sub-groups to standardize one of the
protocol/architecture variants, although it might leave a large part
of the community out of the loop, while having at least a hope to
defeat fragmentation in the future
...or...
2. do not standardize at IETF level, which might be good for the
competition of ideas and allows the community to learn more about the
general problem space, but preserves fragmentation unless the market
cleans it up.

I am really undecided, but there is probably BCP in the IETF.

Best
-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org

---

From: "Mystical Demina" <[email-masked]>
Date: Wed, 25 Mar 2009 21:10:21 -0400

But I think you are wrong about the other 57 platforms out there.  Don't
they all need to have a teleport location specification so that can jump
between their own virtual worlds time they are able to interoperate.  And if
they all move forward using the same specification the foundation is set for
when a client can interoperate with different virtual worlds.

But more than that, you suggest all 57 virtual worlds wait till they can all
talk together.  I will suggest to you the market will not wait for that.  To
me it better to have simple solution and grow it, than have no solution.

But that is my opinion, maybe others feel different.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Heiner Wolf
Sent: Wednesday, March 25, 2009 7:20 PM
To: [email-masked]
Subject: [mmox] IETF policy question

Hi,

What would the IETF do?

Best
-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org
_______________________________________________
mmox mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmox

---

From: Heiner Wolf <[email-masked]>
Date: Wed, 25 Mar 2009 18:21:52 -0700

Hi,

I am not
- suggesting,
- talking about 57 VWs.

I am
- trying to be balanced without implied tendency,
- asking experienced IETF members, e.g. ADs about proven policy.

Best
hw

-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org

---

From: Morgaine <[email-masked]>
Date: Thu, 26 Mar 2009 14:14:20 +0000

Heiner, your question presupposes that incompatibilities make it impossible
to find common areas of interop, and you then ask what the IETF can do about
it.  I think that your premise does not reflect the actual situation, but
only reflects that some parties have not been willing to build bridges so
far, and just keep making position statements instead.

If MMOX were an *engineering* team, the way ahead would be clear.  We would
break down the problem space into pieces based on the needs of many
different worlds, and then we would find a model and protocol for decoupled
services that is applicable to all the architectures involved.

I would like to point out that the second letter of IETF stands for *
Engineering*.  Maybe the only advice needed from the IETF is that this group
should try to use more engineering methodology and break down problems.  If
the preceding paragraph were our M.O., the difficulties would soon be
disentangled and suitable solutions would appear quite quickly.

Morgaine.

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Mar 2009 14:45:41 -0700

Morgaine wrote:
> Heiner, your question presupposes that incompatibilities make it 
> impossible to find common areas of interop, and you then ask what the 
> IETF can do about it.  I think that your premise does not reflect the 
> actual situation, but only reflects that some parties have not been 
> willing to build bridges so far, and just keep making position 
> statements instead.
>

I think we should come out and say what we mean. Saying "some parties 
keep making position statements" is too imprecise. Saying "when person X 
says Y, I don't understand how this relates to a concrete virtual world 
interoperability standard" would probably be more helpful.

As for concrete proposals: I've tried proposing actual, concrete 
actions, and I then back those proposals up by describing how I see the 
needs of the market and the future, integrated, multi-vendor metaverse. 
I believe that's a solid, requirement-based engineering: Given problem 
statement X, a proposal Y is mapped to solve that problem. One of the 
problems, I think, is that different parties on this list have a 
different concept of problem statement X. Thus, having vastly different 
ideas about what Y looks like is not surprising.

What is frustrating to me is that I have not actually gotten any 
response from the Linden people about the concrete proposals; neither on 
the problem statement proposal, nor the specific concrete action 
proposals. All I have gotten a detailed response to is some, but not 
all, of my critique of the currently available OGP proposals, mostly to 
tell me that I'm wrong because my assumptions are wrong and the 
pre-existing AWG-derived assumptions are right.

These concrete proposals of mine have otherwise gotten some positive 
response from the Open Sim community, and other non-Linden-derived 
participants, and mostly absent response from other parts of the Open 
Sim community.

If we can't agree on assumptions (and there's a real chance that we 
can't), then all the bridge building in the world won't help us, 
unfortunately. That's why getting the assumptions and use cases down 
first is crucial.

> If MMOX were an /engineering/ team, the way ahead would be clear.  We 
> would break down the problem space into pieces based on the needs of 
> many different worlds, and then we would find a model and protocol for 
> decoupled services that is applicable to all the architectures involved.
>

I agree! In engineering, you start with requirements.

That's why I posted five detailed use cases for virtual world 
interoperability.

I have since asked explicitly for other use cases to complement the ones 
I contributed, but nobody has stepped up to the plate -- in fact, nobody 
from Linden Lab even replied to the use cases as posted. And for some 
reason, the chairs of the BoF meeting excluded the use case slides and 
presentation from the actual meeting, even though it was on the agenda. 
I inserted myself at the end to at least make the concluding proposal 
that perhaps we should solve smaller problems in different WGs, rather 
than one big WG that tries to solve everything VW related in one swell foop.

However, I am also definitely getting the feeling that the majority of 
the active people on this list are mainly interested in achieving 
near-term Second Life / Open Sim interoperability specifically, and not 
interested in engineering a standard that would be generally accepted 
and implemented by a majority of VW vendors/platforms (most of whom 
aren't even members of this list). If that turns out to be the end 
result, then it probably should come as no surprise that those not 
interested in that particular facet would bow out.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Fri, 27 Mar 2009 14:10:18 +0000

On Thu, Mar 26, 2009 at 9:45 PM, Jon Watte <[email-masked]> wrote:

>
> As for concrete proposals: I've tried proposing actual, concrete actions,
> and I then back those proposals up by describing how I see the needs of the
> market and the future, integrated, multi-vendor metaverse. I believe that's
> a solid, requirement-based engineering: Given problem statement X, a
> proposal Y is mapped to solve that problem.
>

Indeed, you have done that, and it was very useful.  Unfortunately, you then
jump from that helpful input to a "take it or leave it" S-S package deal in
solution space, instead of trying to unify your requirements with what
already exists.

We have to build upon the universe as it stands, rather than force everybody
into the same model (you often say this about OGP after all).  That universe
includes architectures in which clients are intelligent and gain massively
by direct contact with remote worlds, as well as architectures in which all
contact is through servers.  That's how things are, and we need to come
together and find protocols that are helpful to both.  (And let's not forget
C-C or P2P worlds as well.)

OGP is a barebones framework that can embrace all of these models, if we
require it to do so:  *OGP client endpoints* can be opened by the servers of
another world, for example.  Nothing precludes that, and we could quite
easily make the specification reflect this mode of usage and also provide
more helpful capability for server-based client endpoints, a merger between
OGP and LESS concepts.

Unless we take this kind of unified approach that embraces all our models,
we will continue to pitch alternative package deals at each other and get
nowhere.

A concrete suggestion:  As I see it, what little exists of OGP already
supports connection of servers that are proxying on behalf of non-OGP
clients, albeit rather poorly (for example, it assumes 1 connection per
avatar).  I suggest that we examine in depth these assumptions that are not
very favourable to S-S interop, so that our protocols can address all modes
of operation effectively.

Morgaine.

On Thu, Mar 26, 2009 at 9:45 PM, Jon Watte <[email-masked]> wrote:

>> impossible to find common areas of interop, and you then ask what the IETF
>> can do about it.  I think that your premise does not reflect the actual
>> situation, but only reflects that some parties have not been willing to
>> build bridges so far, and just keep making position statements instead.
>>
>>
> I think we should come out and say what we mean. Saying "some parties keep
> making position statements" is too imprecise. Saying "when person X says Y,
> I don't understand how this relates to a concrete virtual world
> As for concrete proposals: I've tried proposing actual, concrete actions,
> and I then back those proposals up by describing how I see the needs of the
> market and the future, integrated, multi-vendor metaverse. I believe that's
> a solid, requirement-based engineering: Given problem statement X, a
> proposal Y is mapped to solve that problem. One of the problems, I think, is
> that different parties on this list have a different concept of problem
> statement X. Thus, having vastly different ideas about what Y looks like is
> not surprising.
>
> What is frustrating to me is that I have not actually gotten any response
> from the Linden people about the concrete proposals; neither on the problem
> statement proposal, nor the specific concrete action proposals. All I have
> gotten a detailed response to is some, but not all, of my critique of the
> currently available OGP proposals, mostly to tell me that I'm wrong because
> my assumptions are wrong and the pre-existing AWG-derived assumptions are
> right.
>
> participants, and mostly absent response from other parts of the Open Sim
> community.
>
> If we can't agree on assumptions (and there's a real chance that we can't),
> then all the bridge building in the world won't help us, unfortunately.
> That's why getting the assumptions and use cases down first is crucial.
>
>> would break down the problem space into pieces based on the needs of many
> I have since asked explicitly for other use cases to complement the ones I
> contributed, but nobody has stepped up to the plate -- in fact, nobody from
> Linden Lab even replied to the use cases as posted. And for some reason, the
> chairs of the BoF meeting excluded the use case slides and presentation from
> the actual meeting, even though it was on the agenda. I inserted myself at
> the end to at least make the concluding proposal that perhaps we should
> solve smaller problems in different WGs, rather than one big WG that tries
> to solve everything VW related in one swell foop.
>
> However, I am also definitely getting the feeling that the majority of the
> active people on this list are mainly interested in achieving near-term
> Second Life / Open Sim interoperability specifically, and not interested in
> engineering a standard that would be generally accepted and implemented by a
> majority of VW vendors/platforms (most of whom aren't even members of this
> list). If that turns out to be the end result, then it probably should come
> as no surprise that those not interested in that particular facet would bow
> out.
>
> Sincerely,
>
> jw
>
>

---

From: Heiner Wolf <[email-masked]>
Date: Fri, 27 Mar 2009 10:12:43 -0700

Ahem, I really don't want to interrupt your flow, but I started with a
rather theoretical question to experienced IETF members. Please guys
make your own threads, they are cheap.

hw
-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 27 Mar 2009 10:41:05 -0700

Hi Heiner,

Your concern seems to be preventing fragmentation of work and
standards.  We are actually gaining experience in handling
fragmentation later, along with experience of what happens when we try
too hard to prevent fragmentation.  When IETF has tried to force there
to be "only one" answer we usually don't succeed, usually delay
progress, and often regret the effort later when enough time has
passed and multiple solutions emerge anyway.

I believe you're quite familiar with the SIP area, where the Session
Initiation and Session Description technologies are defined to let
agents negotiate which standard to use.  The higher we get in the
stack, the easier this approach is to use.  We don't get fussed about
how IMAP, HTTP/WebDAV, NFS and FTP access are still different
protocols even though if they were (over) engineered today we'd
probably have a giant discussion about how they're all fundamentally
access to a hierarchical static object store!

That said, we do have an increasing number of useful general-purpose
modules.  Some examples: for session security there's TLS, for
authentication there's SASL, for delegated authorization we're
building OAUTH, for resource download there's HTTP, for document
sharing/collab there's WebDAV, and URIs solve a number of shared
problems.  I'm hoping SDP and XMPP and Atom also prove to be useful
reusable components.

We don't task sub-groups.  Groups self-organize and if a group can
show a focused topic, a list of achievable deliverables, sufficient
volunteers, and IETF relevancy, we typically approve that charter
after making sure that subgroup is actually still talking to other
subgroups.  Split efforts are sometimes a failure of communication,
but sometimes a true differentiation of goals or tradeoffs.

Lisa

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 27 Mar 2009 13:52:43 -0400

Hello;

I am not wearing any hats here, and this is my own opinion.

> Assumed that we as a WG do not know enough about the general problem  

This to me sounds like an IRTF Research Group should be chartered.  
(I.e., it sounds like there is
research, not just engineering, here.)

> problem and have working solutions.

This is not clear to me. Do you mean "there are sub-pieces A, B, C,...  
of the problem,
and for at least some of the sub-pieces there are working solutions  
and groups willing to work on them"

or

"there are alternative proposals A, B, C,... and for at least some of  
these proposals
there are working solutions and groups willing to work on them"

For the first situation, in my opinion there is nothing wrong with the  
WG taking a bottom up approach,
or spinning off WG to focus on the pieces. It depends on the details,  
of course.

If the second applies, you may be about to learn about the rough part  
of rough consensus.

Regards
Marshall

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 27 Mar 2009 12:37:14 -0700

> Assumed there are multiple systems with incompatible architecture,
...
> protocol/architecture variants, 
...
> 2. do not standardize at IETF level, 

Folks,

Hi.  Sorry for not responding sooner. Your question is a good one to ask at the 
start of an interesting effort from an established and diverse community, since 
the likelihood of competitive proposals is pretty high.

Alas, the simple answer to your question is that there is no simple answer.

So I will provide some discourse which represents both my own view of the way 
this ought to play out and my own view of why it might or might not happen that 
way.

For all its increasing number of formally documented rules, the IETF is really a 
body of people, including ADs and the IESG, and specific decisions often come 
down to what their personal assessment of the right choice is.  Choices which 
one person might think to have a blindingly obvious correct outcome can be, and 
often are, interpreted wildly differently by others, including ADs.  This is 
both a distinctive strength and a distinctive weakness of the IETF...

For reference, at the Thursday evening IETF plenary, a version of your question 
was commented on, during a presentation about MPLS, which is a successful 
lower-layer service for optimizing the handling of packets riding over certain 
kinds of media.  The presentation was about the factors that helped the protocol 
succeed.

One of the comments was about the presence of competing specifications, for 
various components of the MPLS service and that the competition often helped 
/improve/ individual specifications.  Competing efforts split the available 
focus and the allocation of resources and they can confuse the market; so it's 
difficult to believe they can actually be a Good Thing.  Hence, competing 
proposals are something that no one likes, and that everyone would prefer to 
believe should be resolved quickly, by fiat if necessary.  The uncertainty and 
potential cost and delay in letting the market do the choosing, is not all that 
appealing.

However the comment in the presentation was that it is, in fact, better to let 
the market decide:  Pre-emptive selection during standardization can be 
premature, because it is based on too little practical knowledge.

This matches my own view of what should happen:

      Let each competing proposal form its own constituency of supporters, run 
each through the process of creating, testing and deploying its preferred 
specification, and let the market decide the winner (or winners.)

      IMO, an administrative decision, down to a single choice, before the 
process has gone through these steps, is subject both to ignorance and politics.

      Ignorance because there often is not enough information to fully 
appreciate the technical, operational or efficacy subtleties of a proposal. 
Politics because it entails a Grand Decision by a central Grand Authority. 
Concentrated authority invites concentrated lobbying.

Most of the standards spec competitions I've seen -- that have been allowed to 
play out on their own energy -- actually resolve reasonably soon, during the 
specification or testing process: one or another competitor fails to maintain 
enough community support or fails to do the hard work of technical specification 
and vetting the results.  In other words, the proposals failed on their merits. 
  The put-up-or-shut-up pragmatics of all this ought to appeal to anyone 
interested in delivering real value to the community...

All that said, there is the earlier question:

      Should competing proposals seek to merge?

The glib answer is that seeking world peace is always a laudable goal, but it 
has a problem being practical... In my own view the practical answer is that it 
depends on the nature of the differences.  If the proposals differ on matters of 
form, such as using periods rather than semicolons, then yeah, they need to 
merge.  Not should.  Must.  The differences are not real matters of substance 
and the community can't really care about such minutiae.

On the other hand, if the difference is a matter of paradigm -- such as having a 
central server versus a true peer-to-peer (with no intermediary) model -- then 
the difference is really quite fundamental and the answer is that it's almost 
never possible to merge them.  Or at least not without destroying the essence of 
one or both proposals.  Again, this is IMO.

So go ahead and have the merger discussion, since it is always possible that 
some common ground might be found, and even if it isn't, mutual understanding 
will improve and sometimes the details of one or both proposals will improve. 
But do not artificially force them to reconcile.  It will be an unnatural act 
and no one will like the offspring.

Now as for how competing proposals are likely to be handled in the IETF, the 
answer as I said at the start is not obvious.  Area Directors differ on their 
handling of such competition.  On the average, I strongly recommend developing a 
vigorous community of support and participation -- based on work, not lobbying 
-- along with discussing the matter with Chairs and ADs.  Community momentum 
based on doing the hard work can, and often is, the most compelling argument for 
being allowed to continue.

Again IMO, when the differences are in paradigms, the competition is between 
efforts that should have separate working groups.  At best, it is extremely 
distracting to have them in the same wg.  At worst, it encourages fighting 
rather than working.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Charles Krinke <[email-masked]>
Date: Fri, 27 Mar 2009 16:30:39 -0800

I dont get it. I dont see a controversy.

We have OGP *implemented*. We have HyperGrid *implemented*. We have MXP
*implemented*. To me, these are the serious contenders as they exist, folks
can use them, folks are using some of them.

Lets move forward and discuss:

1. How to extend these existing "implemented" interop notions to have
additional features.
2. Encourage other virtual worlds to make "implementations" that can be
tested and used to determine their "usefullness".

When there are additional "implementations", then we can and should increase
the scope of this discussion.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Mar 27, 2009 at 11:37 AM, Dave CROCKER <[email-masked]> wrote:

> Hi.  Sorry for not responding sooner. Your question is a good one to ask at
> the start of an interesting effort from an established and diverse
> community, since the likelihood of competitive proposals is pretty high.
>
> So I will provide some discourse which represents both my own view of the
> way this ought to play out and my own view of why it might or might not
> happen that way.
>
> For all its increasing number of formally documented rules, the IETF is
> really a body of people, including ADs and the IESG, and specific decisions
> often come down to what their personal assessment of the right choice is.
>  Choices which one person might think to have a blindingly obvious correct
> outcome can be, and often are, interpreted wildly differently by others,
> including ADs.  This is both a distinctive strength and a distinctive
> weakness of the IETF...
>
> For reference, at the Thursday evening IETF plenary, a version of your
> question was commented on, during a presentation about MPLS, which is a
> successful lower-layer service for optimizing the handling of packets riding
> over certain kinds of media.  The presentation was about the factors that
> helped the protocol succeed.
>
> focus and the allocation of resources and they can confuse the market; so
> it's difficult to believe they can actually be a Good Thing.  Hence,
> competing proposals are something that no one likes, and that everyone would
> prefer to believe should be resolved quickly, by fiat if necessary.  The
> uncertainty and potential cost and delay in letting the market do the
> choosing, is not all that appealing.
>
> However the comment in the presentation was that it is, in fact, better to
> let the market decide:  Pre-emptive selection during standardization can be
>     Let each competing proposal form its own constituency of supporters,
> run each through the process of creating, testing and deploying its
> preferred specification, and let the market decide the winner (or winners.)
>
> Most of the standards spec competitions I've seen -- that have been allowed
> to play out on their own energy -- actually resolve reasonably soon, during
> the specification or testing process: one or another competitor fails to
> maintain enough community support or fails to do the hard work of technical
> specification and vetting the results.  In other words, the proposals failed
> on their merits.  The put-up-or-shut-up pragmatics of all this ought to
> appeal to anyone interested in delivering real value to the community...
>
> The glib answer is that seeking world peace is always a laudable goal, but
> it has a problem being practical... In my own view the practical answer is
> that it depends on the nature of the differences.  If the proposals differ
> on matters of form, such as using periods rather than semicolons, then yeah,
> they need to merge.  Not should.  Must.  The differences are not real
> matters of substance and the community can't really care about such
> minutiae.
>
> On the other hand, if the difference is a matter of paradigm -- such as
> having a central server versus a true peer-to-peer (with no intermediary)
> model -- then the difference is really quite fundamental and the answer is
> that it's almost never possible to merge them.  Or at least not without
> destroying the essence of one or both proposals.  Again, this is IMO.
>
> So go ahead and have the merger discussion, since it is always possible
> that some common ground might be found, and even if it isn't, mutual
> understanding will improve and sometimes the details of one or both
> proposals will improve. But do not artificially force them to reconcile.  It
> will be an unnatural act and no one will like the offspring.
>
> Now as for how competing proposals are likely to be handled in the IETF,
> the answer as I said at the start is not obvious.  Area Directors differ on
> their handling of such competition.  On the average, I strongly recommend
> developing a vigorous community of support and participation -- based on
> work, not lobbying -- along with discussing the matter with Chairs and ADs.
>  Community momentum based on doing the hard work can, and often is, the most
> compelling argument for being allowed to continue.
>
> Again IMO, when the differences are in paradigms, the competition is
> between efforts that should have separate working groups.  At best, it is
> extremely distracting to have them in the same wg.  At worst, it encourages
> fighting rather than working.
>
> d/
>
> --
>
>  Dave Crocker

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director