Sent From: [log in to unmask]

This is a resend of a message since I had failed to subscribe to SIW-RFOM. It was originally addressed as follows: To: [log in to unmask] Cc: [log in to unmask], [log in to unmask], [log in to unmask] Our support for the RPR FOM SN was indicated on the SAC-DISCUSS reflector (cross-posted to the SISO-RPR reflector) on 29 Aug before the SIW. See "COMMENT ON: SN-97-002" posted by Len Granowetter ([log in to unmask]) under his and my names. However, as Bill Tucker stated, I think a lot of us have been electronically silent with regards to SN-97-002 (the RPR FOM) particularly on the SISO-SAC reflector. Unfortunately I think this silence has been interpreted as a lack of support or interest in the RPR FOM itself. I think this interpretation is incorrect. At the risk of being politically incorrect and with the hopes that others will indicate their support and interest, I have cross posted to the 3 reflectors where I think interested parties may be listening (see point 1 below). I think there have been various reasons for this silence: - Reflector subscription overload and schizophrenia (SAC-DISCUSS where there has been little discussion versus SISO-SAC where the real discussion has been, versus SISO-RPR where the real work of the RPR FOM takes place). - A lack of understanding of the complicated SAC processes (which Randy mentioned) and a wait and see attitude towards how these processes work and how representatitive and responsive they are. - Participation in the in-person process at the SIW (the workshop being traditionally where a lot of decisions were made and work accomplished) with over a hundered people at both of the late evening Reference FOM and RPR FOM meetings. - The statement made at the Reference FOM meeting that no matter all the time and effort to be invested in the Reference FOM Study Group, the SAC could entirely ignore any recommendation and make its own decision. - A similar feeling that a lot of volunteer effort and support, far-sightedness, and community outreach (the ground-swell of community support and participation much looked for on these reflectors) which the RPR FOM SN represents (and is still going into the RPR FOM development and adoption) is being taken lightly, or worse, that efforts are being made to torpedo it. - etc. In addition, there has always been a greater interest in using standards than in being personally involved in developing them, particularly when budget and time constraints do not allow costly development involvement. The above stated reasons for lack of participation in the SISO email reflectors and processes do not indicate a lack of support and interest in standards in general and the RPR FOM SN in particular. In fact, it was my impression at SIW, at both the Reference FOM meeting and certainly at the RPR FOM meeting, that with very few exceptions, people overwhelming supported the concept of reference FOMs in general and the RPR FOM in particular. Many expressed outright disbelief that there was any agrument, particularly against the RPR FOM with its degree of background and the necessity of protecting investments. I fear that the SAC is running the risk of representing the remark, "Where there are no leaders there are no followers." Again, let me restate our avid support of the RPR FOM SN and its adoption as a standard and our opinion that the SAC should indicate now its strong intention to standardize the RPR FOM. -Scott Scott Hamilton [log in to unmask] MaK Technologies, Inc. voice (617) 876-8085 x108 185 Alewife Brook Parkway fax (617) 876-9208 Cambridge, MA 02138 > Date: Sun, 5 Oct 1997 22:46:12 -0500 > Reply-To: [log in to unmask] > X-Precedence: bulk > From: "Tucker, William V" <[log in to unmask]> > X-To: "[log in to unmask]" <[log in to unmask]> > X-Priority: 3 > X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > > Randy' > I am fequently impressed with your reasoning, but I usually greet a > particularly well stated randyism with a vocal, but electronically > silent, yea! I cannot let this oportunity go by, without a stronger > indication of support. I am at home in my living room on this Sunday > night with a limited ability to do research but I seem to remember that > a central premise of SAC and SISO is to help protect investments made by > its members. I have for some time hoped that we would invoke that > premise and adopt the RPR FOM as a standard. I am academically > interested in the outcome of the generic FOM discussion, but if some > other reference FOM comes to the door with the degree of background that > the RPR FOM has, I would support it too, without regard to the general > goodness of reference FOMs. whatever they are.. The approval of the RPR > FOM SN is implied by our own groundrules and I think I have lost track > of why we are arguing about it > > Bill Tucker > e-mail [log in to unmask] > Voice (205) 461-3120 > Fax (205) 461-2983 > mail The Boeing Company > 499 Boeing Blvd, MS JN-80 > PO Box 240002 > Huntsville, AL 35824-6402 > Speaking for myself, not the company > > > > > ---------- > > From: Randy Saunders[SMTP:[log in to unmask]] > > Sent: Sunday, October 05, 1997 9:20 PM > > To: SISO - SAC > > Subject: Re: SAC Telecon Agenda for 10/7 > > > > >SAC Telecon > > > > > >C. Discussion Topics > > >1. Discuss RPR FOM SN disposition > > > vote on action > > > > > At the last telecon we discussed this for 30-45 minutes and people > > agreed to circulate their position via reflector. This was to > > help me see where I might find a compromise position that the > > whole SAC could get behind. I've seen no messages, so I'm going > > to be my normal schizophrenic self and try to play all the sides. > > > > For reference the question is "What to do with the RPR FOM SN?" and > > the options in our current procedure are: a) REJECT and give some > > reason; b) ACCEPT and charter an SDG to write up a standard document; > > and c) HOLD and identify some date/development which would cause the > > SAC to reconsider the SN. > > > > >[log in to unmask] wrote: > > > HOLD > > > > > >The RPR FOM SN should be put on Hold because the SAC does not know > > >what role RFOMs will play in SISO. If the RPR FOM is a standard and > > >the RFOM Study Group identifies good reason that SISO should never > > >have RFOM standards, then we've gotten into an inconsistant state. > > > > I think this argument has been brought up for over a year, and the > > RPR FOM developers are unanimous in their willingness to accept this > > risk. They see the "RFOMs are always bad" result as less than 1% > > probability, and if there was conclusive evidence that RFOMs cause > > cancer the RPR FOM people would be the first to want the RPR FOM > > standard revoked. > > > > I personally feel grave reservations about "Wait until we know more". > > That is the kind of analysis paralysis in the DIS community that > > caused people to start the AMG. The SAC should be proactive, if we > > make a mistake we should promptly revoke it. To wait until there > > is no doubt is just not responsive to a fast evolving community. > > All software, not just M&S, is evolving at WWW rates and a SISO SAC > > moving at this sort of a speed is irrelevant. > > > > >[log in to unmask] wrote: > > > ACCEPT > > > > > >The RPR FOM is a clear statement of a problem an a proven, > > commercially > > >available solution for it. While some people have valid concerns, > > >the RPR FOM developers and the SAC Technical Area Director believe > > they > > >can be addressed within the standards development framework. The > > >standard proposed has not been written, but a draft standard is not > > >required by SAC policy statements or evaluation criteria as an entry > > >condition. > > > > I personally think this argument is directly on point, especially > > since it places such value on my recommendation. ;-) > > > > >[log in to unmask] wrote: > > > REJECT > > > > > >The RPR FOM is a bad idea and SISO should not standardize it. Any > > >standard for FOM content would be widely misused by the procurement > > >community. Even if it saved some federations money, it stiffles the > > >creativity of people in those parts of the M&S community. Once an > > >SDG is formed, it will not listen to community inputs and everybody > > >will be railroaded into approving the result. [I hope this is all > > >the reject reasons. /RS] > > > > I don't see any of these reasons as being very important. While I > > have had arguments with procurement people over which standards > > they should invoke on a contract (I'm sure Jimmy Williams is still > > out there somewhere), I don't think they are dumb. In general the > > wrong specs are not part of the governments contracts. When they > > are put in contracts, ECPs get written (usually VECPs that don't > > even charge the DoD) to take them out. This is a scare tactic, not > > an argument against the RPR FOM. > > > > The purpose of the RPR FOM is not to help everybody, it is to keep > > a part of the community from being hurt. Some programs that use > > DIS have seen their cost to integrate new federates become more > > uniform. This doesn't actually save cost, it reduces risk. The > > relationship between risk and cost is an interesting function of > > many variables and outside the scope of this EMail. These people > > don't want more risk. They have programs where creativity is > > already stifled a certain way. They do not want to get more > > creativity if it means more risk. They won't want HLA at all if > > it means more risk. As an engineer, I accept that sometimes > > creativity is bad engineering (yes, even when it is MY creativity). > > That is what makes engineering different from art. > > > > The purpose of SDGs is to collect and incorporate ideas from the > > community. In the "31 step process" roundly joked about at the > > last SIW, 30 of the steps have to do with getting a balanced SDG > > listening to the whole community and ONLY 1 STEP deals with the > > SDG doing its own thing. We have three tiers of checks and balances > > to make sure nobody gets railroaded. Even if this person's crystal > > ball is better than mine, we should accept this SN so we can find > > how mistakes get made. This is the only way to perfect our process. > > Just saying "It can go wrong!" without an example or corrective > > action is not constructive. Let's do it, I'll let you say "I told > > you so" when we find the problem. At least then we can fix our > > processes. > > > > CONCLUSION > > > > I recommend the SAC should APPROVE the RPR FOM SN, and place three > > taskings in the TOR for the SDG: 1) Align the RPR FOM standard > > schedule with the RFOM Study Group schedule, participate in all > > their discussions and working meetings, and incorporate their > > recommendations; 2) Begin work on the standard document, taking > > care to address the abuse/misuse positions; and 3) Coordinate > > with the HLA SDG and the DMSO Data Standards team to get from > > them the necessary/typical interface standards for all HLA FOMs, > > and integrate their recommendations into the standard's FOM > > appendix/annex. > > > > > > /Randy Saunders > > Hughes Training Inc. > > (248) 619-8321 <== New > > [log in to unmask] > > > > > -Scott Scott Hamilton [log in to unmask] MaK Technologies, Inc. voice (617) 876-8085 x108 185 Alewife Brook Parkway fax (617) 876-9208 Cambridge, MA 02138

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