Randy's v.90 modem standard analogy is too tempting a target not to fire
at, so I will not disappoint.  

But first, let me agree with his conclusion.  Once things settle down for a
couple of years, it is probably inevitable that there will be a rising
desire for RTIs to intercommunicate and we will be in a much better
position to understand what that means and how to write standards to bring
it about.  I do not think this is wise.  I think it, in some ways, subverts
some of the things HLA was intended to foster (making people sit down and
understand each others sims before plugging them together). 

 Nevertheless, the plugemtogether-in-the-blind crowd and the
forcemtoallbethesame crowd will keep going after the plug-and-play grail.
If a large enough group wants to do something, one can't really stop them
from meeting and trying to come up with a standards draft.  If it takes
them 2 years in the process, maybe it is fine for them get started now.  In
the meantime, I will continue to fight the good fight to keep pointing out
why plug-and-play is unwise as a mandate.

Now (yum yum).  The two 56K modem domains (Rockwell and US Robotics) are so
similar as to be almost identical.  This is not a good analogy to the
differences between communities in the M&S arena.  Furthermore, the
solution that Randy describes, (CCITT merging the two competing modems
(RTIs) together) into a single CCITT standard=v.90) is not what is being

Michael obviously has a mental simulation domain in his mind that is
homogeneous enough where it makes sense to think of them all agreeing on an
intercommunications standard where they cannot or will not agree on a
common RTI.  I think the M&S universe is in fact so broad that it includes
models that can not, should not and should not be made to intercommunicate
by any language or means.  Thus I get nervous when people start acting as
if they are going to create rules and regulations to force such

Jerry Lucha
SRI International
(speaking for myself as I always do)

>Consider an example.  Two companies make 56K modems (=RTIs).  They both
>use the same interface to your computer (=model), called a serial port
>(=API).  However, they are not interoperable.  Your ISP (ūderation)
>needs to decide which modem (=RTI) to use.  Some ISPs (ūderations)
>offer increased flexibility, at increased cost (=$$), by supporting both
>modems (=RTIs) using internal mechanisms.  This works fine for a while,
>the competing approaches vie for market share.  Everything is fine as
>long as 56K modems (=RTIs) are only used by laboratories or early
>adopters (=HLA 1998).
>However, there are a bunch of nasty people in the world who control how
>much gets spent on networking (=modeling and simulation).  These folks
>want value for their money, and two solutions which don't interoperate
>are low value.  The nasties say "We're not buying either approach until
>it will let me talk to everybody".  This puts the modem (=RTI) providers
>in a pickel.  If they gain compatibility they will lose their primary
>lock on the market.  The investors who paid for the modem (=RTI) to be
>developed see their control of the marketplace diminish.  Eventually
>all sides allow the CCITT Standards group (=SISO) to control the
>evolution of modem standards (=HLA standards) to merge the competing
>implementations together.  After much nashing of teeth, everybody gets
>a rev to their modem (=RTI) which supports universal compatibility.
>The world is a happy, interoperable, productive place (=HLA 2001).
>As a member of the SAC, speaking for myself and not the SAC, I would
>welcome the formation of a group to identify the requirements and
>standardize the interface between RTIs, if there were folks to get the
>job done.  Right now it looks like a big, hard job with a small team
>interested in attacking it.  This won't work, we tried it on the DIS
>Communications Architecture standard.  Far better to get at least one
>RTI that works (and I mean: high performance + low overhead = "works").
>Then we can see if there is a need for another RTI implementation, and
>then we can see what's involved in making them interoperate.  I don't
>see the benefit in making laboratory curiosities like RTI 1.3 work
>with the production RTI (2.0).  That doesn't mean it isn't there, but
>nobody has explained it to me.  I think we'll have a group that does
>this RTI <=> RTI interface standards stuff, so if you think this problem
>will go away I think you're mistaken.  However, I think that about
>18 months from now that task will be meaningful and doable.  If there
>is a proposal for something we could do now that could be accomplished
>with the available volunteers, I'd like to see it.
>/Randy Saunders
>Raytheon Systems Company
>(248) 619-8321
>[log in to unmask]

To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link: