The use of abstract valuetypes for handle types in the current
DistributedSimulation IDL requires a user to have matching
implementations of the handle and the handle factory for both the client
federate and RTI. Because it is usually an RTI developer who provides
the implementation of these handle types and their corresponding
factories, it is unnecessary to use a valuetype to create this
definition. It is recommended that valuetype definitions of handles be
replaced with IDL interfaces. That is, in the section labeled “Handles”
from pp 1-9 to 1-10, the word “valuetype” should everywhere be replaced
by “interface”. Paragraphs 5 and 6 on p. 1-9 are replaced by the
following:

Each kind of handle is represented in IDL as an IDL interface, e.g.,
ObjectClassHandle or FederateHandle. An RTI implementer will create an
implementation for each such interface., the details of which are hidden
from the federate developer.
In paragraph 7 on p. 1-9, the words “concrete valuetype” should be
replaced by “interface”.
In the IDL, the HANDLETYPE macro is replaced by the following:
#define HANDLETYPE(A) \
interface A

; \
interface A##Factory

;

Replace valuetype definitions of handles with IDL interfaces.

The use of abstract valuetypes for order and transportation types in the
current DistributedSimulation IDL require a user to have matching
implementations of the handle and the handle factory for both the client
federate and RTI. Since it is usually an RTI developer who provides the
implementation of these types and their corresponding factories, it is
unnecessary to use a valuetype to create this definition. It is
recommended that the valuetype definitions for order and transportation
types should be replaced with IDL interfaces for them and corresponding
factory interfaces. The following revisions are recommended:
On p. 1-12, in the first paragraph of the section headed “Message order
and transportation types”, replace the words “(concrete) valuetype” with
“IDL interface”.
In the IDL, replace the valuetypes OrderType and TransportationType with
the following:
interface OrderType

;

interface TransportationTypeFactory

;

see above

As currently stated, the standard says that designators of region realizations are conveyed in conveyed region sets. However, the conveyed region sets must contain designators of copies of region realizations, rather than designators of region realizations themselves, because if the designators of the actual region realizations were to be conveyed, this would result in an undesirable race condition. If the designators were of actual region realizations, for example, rather than of just copies of region realizations, then after a federate invokes an Update Attribute Values service or a Send Interaction with Regions service that results in a set of sent region designators being conveyed in the corresponding Reflect Attribute Values † service or Receive Interaction † service, there is a race that could occur between the federate that sent the update or interaction setting new range bounds and committing region modifications to a sent region, and the federate that received the reflect or interaction invoking the Get Dimension Handle Set and Get Range Bounds services to query all of the range bounds of the region realization received.

According to post-condition (b) of the Commit Region Modifications service, when a region specification is modified, all update region realizations that are derived from that region specification are also modified. If the updating federate modifies the conveyed region realization before the reflecting federate has a chance to use the Get Range Bounds service to determine what the range values of each dimension of the sent region realization were, then the reflecting federate will never be able to determine what the range values of the region realization were when the overlap calculation that resulted in the reflect was performed. A race condition would exist between the updating federate's attempt to modify the region specification and the reflecting federate's attempt to determine the range values of each dimension of the derived region realizations received.

Conveying designators of copies of these region realization, instead of designators of the region realizations themselves, eliminates this race condition. The reflecting federate is always guaranteed that if it queries the range bounds using a region designator conveyed in a reflect or received interaction while the reflect or receive interaction is still in progress, the range values of the region specification copy will be the values of the update region realization that were in effect at the time that the overlap calculation was done on the update region set and subscription region set that resulted in that reflect or received interaction.

The text should be amended to make clear that the set of sent region designators conveyed are not a set of designators of region specifications or a set of designators of region realizations. They are, instead, a set of designators of copies of the update region realizations. The range values of each of the dimensions in each of these region realization copies are the same as the range values of each of the dimensions of the corresponding update region realization that were in effect when the region overlap calculation was performed. Each designator is guaranteed to refer to a particular region realization copy, and the copy is guaranteed to remain in tact, until the Reflect Attribute Values † service or the Receive Interaction † service invocation at the receiving/reflecting federate completes. No change to the range values of the region realization from which the copy was made will cause a change to the range values of the copy as long as the Reflect Attribute Values † service or the Receive Interaction † service invocation is still in progress.

Add the suggested clarifying text.

According to the fourth paragraph of section 9.1.7, whenever the Convey Region Designator Sets Switch is enabled, "the optional Set of Sent Region Designators argument shall be provided (as appropriate) with all Reflect Attribute Values † and Receive Interaction † service invocations at all joined federates".

The meaning of "as appropriate" should be clarified. The following text is recommended as consistent with the rest of the standard:

The Set of Sent Region Designators argument shall be provided in a Reflect Attribute Values service invocation or in a Receive Interaction service invocation if and only if:
· the Convey Region Designator Sets Switch is enabled, and
· the reflected instance attribute(s) or the received interaction has available dimensions.
This means that if the above conditions are true, all federates, not just those federates that are using DDM or that are subscribed to the specified attributes or interaction class with regions, will receive the reflect or interaction with a set of sent region designators argument.

Add the suggested clarifying text.

As currently specified, some DDM services can be invoked with a region template as argument, but using a region template as argument is not useful because not all dimensions of a region template have had their range bounds set. The preconditions of many DDM services need to be modified to reflect whether they can accept region templates or region specifications as argument. The following text is recommended:

Some DDM services shall require that the region designator used as an argument be the designator of a region specification, whereas other DDM services shall require that the region designator used as an argument be the designator of either a region template or a region specification. One DDM service, Commit Region Modifications, requires that the region designator used as an argument be that of either a region template that has had the Set Range Bounds service called at least once for all of its dimensions, or a region specification. If a DDM or Support service is invoked with a region designator argument that is not of the variety it is expecting, the service shall throw the "Invalid region" exception. Hence, the circumstances that shall cause the "Invalid region" exception to be thrown will vary from service to service, depending on the type of region entity (template, specification, or template with all range bounds set) for which the service is expected to receive a designator.

All services that can be used to create a region realization from a region specification require that the region designators provided as arguments to those services be designators of region specifications. Specifically, the following services, which result in the creation of region realizations from region specifications, require that the region designator that is passed to them as argument be the designator of region specification: Register Object Instance With Regions, Associate Regions For Updates, Subscribe Object Class Attributes With Regions, Subscribe Interaction Class With Regions, Send Interaction With Regions, and Request Attribute Value Update With Regions.
The following services also require that the region designator that is passed to them as an argument be the designator of a region specification: Unassociate Regions for Updates, Unsubscribe Object Class Attributes With Regions, and Unsubscribe Interaction Class With Regions.

The Delete Region service will allow the region designator that is passed to it as an argument to be either the designator of a region template or of a region specification.

There are also three Support Services that take a region designator as argument:
· The Get Range Bounds service requires that the region designator passed to it as an argument be either the designator of a region specification or of a region realization.
· The Get Dimension Handle Set service will permit the region designator passed to it as an argument to be the designator of a region template, region specification, or region realization.
· The Set Range Bounds service requires that the region designator passed to it as an argument be either the designator of a region template or of a region specification.

Add clarifying text.

This service shall result in the creation of one or more region realizations. A region realization can only be derived from a region specification, not a region template, because all range bounds of the specified regions of the region realization must be set. If the designator of a region template, instead of a designator of a region specification, is used as an argument to this service, then this service could not result in the creation of a region realization because the range bounds of one or more of the dimensions in the region would not be set. Therefore, a new precondition should be added to this service description that says, "All supplied region designators are designators of region specifications." If a region designator specified is not a designator of a region specification, the "Invalid region" exception shall be generated.

Add the suggested new pre-condition

This service description should be clarified regarding the intended use of the optional passive subscription indicator. The text does not explain what it means for a subscription with region to be passive or active. That is, it is not clear whether the active/passive characteristic applies on a per-(object class, class attribute, region) triple basis, on a per-(object class, class attribute) pair basis, or on some other basis It is recommended that text be provided indicating that the use of the optional passive subscription indicator is expected to work on a per-triple basis.

Add text that explains the effects of the optional passive subscription indicator.

Only region specifications, not region templates, can be used as arguments to the Associate Regions For Updates service, so it would make no sense to use a region template as argument to the Unassociate Regions For Updates service. A region template cannot be associated for updates, so it therefore cannot be unassociated for updates either. A new precondition needs to be added to this service that says, "All supplied region designators are designators of region specifications." If a region designator specified is not a designator of a region specification, the "Invalid region" exception shall be generated

Add the suggested new pre-condition.

The second sentence in this service description says that, "No changes shall be made to the association set if the specified regions are not in the set of associations of the specified instance attributes." However, it does not indicate what should happen if one or more of the specified regions is in the set of associations. Text needs to be added that clarifies that if one or more of the specified regions is in the set of associations, then these regions shall be unassociated from the specified instance attributes; if any of the specified regions are not in the set of associations of the specified instance attributes, they shall be ignored

Add the suggested clarifying text.

This service shall result in the creation of one or more region realizations. A region realization can only be derived from a region specification, not a region template, because all range bounds of the specified regions of the region realization must be set. If the designator of a region template, instead of a designator of a region specification, is used as an argument to this service, then this service could not result in the creation of a region realization because the range bounds of one or more of the dimensions in the region would not be set. Therefore, a precondition needs to be added to this service that says, "All supplied region designators are designators of region specifications." If a region designator specified is not a designator of a region specification, the "Invalid region" exception shall be generated.

Add the suggested pre-condition.

According to section 9.1.3.2, (a), if an instance attribute is associated with the default region, there is no value in also associating it with other regions, because the default region always overlaps with all other regions that have dimensions. An instance attribute should only be associated with the default region if it is not associated with any other region. When an instance attribute is associated with another region, its association with the default region should no longer exist. So, if an instance attribute is associated with the default region, associating that instance attribute with one or more other regions shall have the effect of removing the association of that instance attribute with the default region, because there is no way to explicitly remove the association of that instance attribute with the default region. Therefore, the Associate Regions For Updates service description, which now says that, "This service shall add the specified regions to the set of associations of each specified instance attribute" needs to be changed to indicate that if an instance attribute is associated with the default region, then invocation of the Associate Regions For Updates service shall remove the association of that instance attribute with the default region as well as add the association of that instance attribute to the specified region. This is the sole exception to the additive semantics rule.

Change the service description as suggested.

Only region specifications, not region templates, can be used as arguments to the Subscribe Object Class Attributes With Regions service, so it would make no sense to use a region template as argument to the Unsubscribe Object Class Attributes With Regions service. A region template cannot be subscribed, so it therefore cannot be unsubscribed either. There shall be a precondition of this service that says, "All supplied region designators are designators of region specifications." If a region designator specified is not a designator of a region specification, the "Invalid region" exception shall be generated.

Add the suggested new pre-condition.

This service begins by saying that, "The Unsubscribe Object Class Attributes With Regions service shall inform the RTI that it shall stop notifying the joined federate of object instance discoveries and attribute updates for instance attributes of the specified object class in the specified region." This is not consistent with the rest of the standard. Instead, this sentence should be revised to say:

The Unsubscribe Object Class Attributes With Regions service shall require the RTI to remove the specified region from the subscription region set of the specified class attribute at the specified object class, which is used to determine when the Discover Object Instance † service and the Reflect Attribute Values † service shall be invoked at this joined federate.

Revise this sentence as suggested.

The purpose of the Commit Region Modifications service is to either create a region specification from a region template or to modify an already-existing region specification and all derived region realizations. If not all dimensions of a region template have had their range bounds set, then no region specification can be created by the Commit Region Modifications service because a region specification, by definition, has range bounds set for each dimension in the region template. Therefore, invoking the Commit Region Modifications service in this situation is considered an error. However, as currently written, the standard permits invocation of the Commit Region Modifications service in this situation. The following text is recommended to correct this problem:

Each region designator that is passed to the Commit Region Modifications service is required to be the designator of either a region template that has had the Set Range Bounds service invoked at least once for all of its dimensions, or a region specification. If a federate invokes the Commit Region Modifications service with a region designator argument that is neither the designator of a region template that has had the Set Range Bounds service invoked at least once for all of its dimensions, nor the designator of a region specification, then the Commit Region Modifications service shall throw the "Invalid region" exception.

Add the suggested text.

The last sentence of Section 9.1.7 does not make sense as currently written. This sentence should say, "A joined federate shall use the region realization designators received in conveyed region sets only in the Get Range Bounds and Get Dimension Handle Set service invocations.

Change the text as suggested.

The last paragraph of this service description says,

If the optional object instance name argument is supplied, that name shall have been successfully reserved as indicated by the Object Instance Name Reserved † service and shall be coadunated with the object instance. If the optional object instance name argument is not supplied, the RTI shall create one when needed (Get Object Instance Name service).

This implies that the RTI may not always create an object instance name. However, the registration of all object instances should be treated consistently, whether they are registered with or without regions. All object instances should have federation execution-wide unique names. With regard to the behavior described in this paragraph, the Register Object Instance With Regions service should behave identically to the Register Object Instance service, 6.4. That is, if the optional object instance name argument is not supplied when the Register Object Instance With Regions service is invoked, the RTI shall create a federation execution-wide unique name and that name shall be coadunated with the object instance.

see above

This service shall result in the creation of one or more region realizations. A region realization can only be derived from a region specification, not a region template, because all range bounds of the specified regions of the region realization must be set. If the designator of a region template, instead of a designator of a region specification, is used as an argument to this service, then this service could not result in the creation of a region realization because the range bounds of one or more of the dimensions in the region would not be set. Therefore, there should be an additional precondition of this service that says, "All supplied region designators are designators of region specifications." If a region designator specified is not a designator of a region specification, the "Invalid region" exception shall be generated.

Add the suggested pre-condition.

Deletion of a region that is in use must not be carried out by the RTI, because the expected behavior of the RTI in such a situation is not well-defined. Pre-condition e, "The region is not in use for update or subscription", and exception c, "The region is in use for update or subscription", support the contention that deletions of regions that are in use shall not be allowed. However, the second sentence of the service description seems to make such deletions undesirable, but permissible. This second sentence of the service description should be changed to say, "A region in use for subscription or update shall not be deleted."

Change the second sentence of the service description as suggested.

Exception (c) should have a "not" in it. It should read "The parameter is not an available parameter of the interaction class."

Add the “not” as suggested.

This clause says that, "The enabling of an advisory switch directs that the RTI shall inform the joined federate, via the appropriate advisory notifications, whenever the conditions covered by that advisory change." However, it is not clear what the initial state of each advisory switch is. It is recommended that for purposes of determining whether the conditions covered by each advisory have changed, text be added that indicates that when the conditions required for sending each advisory become relevant at a given federate, the initial state of each advisory, as known by that federate, is as follows:
1. Before a federate begins publishing an object class, the conditions covered by the Object Class Relevance Advisory switch are assumed to be such that the registration of new object instances of the specified object class is not advised.
2. Before a federate begins publishing an interaction class, the interaction class is in the Interactions Turned Off state with respect to that federate. (see Figure 12)
3. Before a federate becomes the owner of an instance attribute, the instance attribute is in the Updates Turned Off state with regard to that federate. (see Figure 14)
4. Before a federate knows about an object instance, all of the instance attributes of that object instance are in the Attributes Out-of-Scope state with regard to the federate. (see Figure 14)

Add text explaining the initial state of each advisory, as suggested.

Service 9.5: Register Object Instance With Regions: The returned argument should be an object instance "handle" (not an object instance "designator").

Change the returned argument from “designator” to “handle”.

This service begins by saying that, "The Unsubscribe Interaction Class With Regions service shall inform the RTI that it shall no longer notify the joined federate of interactions of the specified class that are sent into the specified region." This is not consistent with the rest of the standard. Instead, this sentence should be revised to say:

The Unsubscribe Interaction Class With Regions service shall require the RTI to remove the specified region from the subscription region set of the specified interaction class, which is used to determine when the Receive Interaction † service shall be invoked at this joined federate.

Revise the text as suggested.

This service shall result in the creation of one or more region realizations. A region realization can only be derived from a region specification, not a region template, because all range bounds of the specified regions of the region realization must be set. If the designator of a region template, instead of a designator of a region specification, is used as an argument to this service, then this service could not result in the creation of a region realization because the range bounds of one or more of the dimensions in the region would not be set. Therefore, a new precondition should be added to this service description that says, "All supplied region designators are designators of region specifications." If a region designator specified is not a designator of a region specification, the "Invalid region" exception shall be generated.

Add the suggested new pre-condition.

If the designator of a region template, instead of a designator of either a region specification or a region realization copy, is used as an argument to this service, then this service would not be able to return the range bounds for those dimensions of the region template that have not yet been set. Therefore, to avoid this situation in which behavior is undefined, a new precondition should be added to this service that says, "All supplied region designators are designators of either region specifications or of region realization copies." If a region designator specified is not a designator of a region specification or of a region realization copy, the "Invalid region" exception shall be generated.

Add the suggested new pre-condition.

The standard does not define what behavior would be expected if a federate were to invoke the Get Dimension Handle Set service on a region specification designator that it got by any other means than creating the region specification itself, or on a region realization designator that it got by any other means than having received it in a conveyed region set. Therefore, it is recommended that text be added to this service prohibiting all other designators as arguments: "There shall be an additional pre-condition to this service that says, "The region was either created by the invoking joined federate using the Create Region Service or it was conveyed to the invoking joined federate in a Set of Sent Region Designators argument." If the region designator specified is not the designator of a region that was either created by the invoking federate or conveyed to it in a Set of Sent Region Designators argument, the "Invalid region" exception shall be generated

Add the suggested new pre-condition.

This service description should be clarified regarding the intended use of the optional passive subscription indicator. The text does not explain what it means for a subscription with region to be passive or active. It is recommended that clarifying text be added that indicates that the intent is for invocations of the Subscribe Interaction Class With Regions service for any given interaction class to be cumulative with respect to the set of subscribed regions of a given interaction class, but substitutive with respect to whether each (interaction class, region) pair is subscribed actively or passively. If the current invocation of the Subscribe Interaction Class With Regions service includes a given (interaction class, region) subscription that already exists, the property of active versus passive for that (interaction class, region) subscription is substituted according to the value (or absence) of the optional passive subscription indicator argument to the current invocation of the Subscribe Interaction Class With Regions service.

Add text explaining the use of the optional passive subscription indicator.

Section 9.1.6, second paragraph: the term "DM" should be replaced by "Object Management" in the sentence, "A joined federate using data distribution management services shall interpret all uses of the following three declaration management services by any joined federate in the federation execution (including itself)…"

Replace “DM” by “Object Management”, as suggested.

This service shall result in the creation of one or more region realizations. A region realization can only be derived from a region specification, not a region template, because all range bounds of the specified regions of the region realization must be set. If the designator of a region template, instead of a designator of a region specification, is used as an argument to this service, then this service could not result in the creation of a region realization because the range bounds of one or more of the dimensions in the region would not be set. A new precondition should be added to this service that says, "All supplied region designators are designators of region specifications." If a region designator specified is not a designator of a region specification, the "Invalid region" exception shall be generated.

Add the new pre-condition as suggested.

This service shall result in the creation of one or more region realizations. A region realization can only be derived from a region specification, not a region template, because all range bounds of the specified regions of the region realization must be set. If the designator of a region template, instead of a designator of a region specification, is used as an argument to this service, then this service could not result in the creation of a region realization because the range bounds of one or more of the dimensions in the region would not be set. A new precondition should be added to this service that says, "All supplied region designators are designators of region specifications." If a region designator specified is not a designator of a region specification, the "Invalid region" exception shall be generated.

Add the suggested new pre-condition.

The second sentence of this service description reads, "The interaction parameters shall only be those in the specified class and all super-classes, as defined in the FDD." This should be clarified to make clear that only parameters that are available at that interaction class may be sent in a given interaction, but a federate is not required to send all available parameters of the interaction class with the interaction.

Clarify the text as suggested.

The standard does not define what behavior would be expected if a federate were to invoke the Get Range Bounds service on a region specification designator that it got by any other means than creating the region specification itself, or on a region realization designator that it got by any other means than having received it in a conveyed region set. Therefore, it is recommended that text be added to this service prohibiting all other designators as arguments: "The region was either created by the invoking joined federate using the Create Region Service or it was conveyed to the invoking joined federate in a Set of Sent Region Designators argument. If the region designator specified is not the designator of a region that was either created by the invoking federate or conveyed to it in a Set of Sent Region Designators argument, the "Invalid region" exception shall be generated

Add the suggested new pre-condition.

Only region specifications, not region templates, can be used as arguments to the Subscribe Interaction Class With Regions service, so it would make no sense to use a region template as argument to the Unsubscribe Interaction Class With Regions service. A region template cannot be subscribed, so it therefore cannot be unsubscribed either. A new precondition should be added to this service that says, "All supplied region designators are designators of region specifications." If a region designator specified is not a designator of a region specification, the "Invalid region" exception shall be generated

Add the suggested new pre-condition.

The second paragraph of the 9.11 service description contains an error. The first sentence reads, "If the region set provided is empty, no subscription to the interaction class shall not be removed." The "not" should not be present in this sentence. It should read, " If the region set provided is empty, no subscriptions to the interaction class shall be removed."

Delete the “not” from the sentence, as suggested.

Each HLAreportObjectClassSubscription interaction must, according to Table 17, contain four parameters: HLAnumberOfClasses, HLAobjectClass, HLAactive, and HLAattributeList. When a federate subscribes to object class attributes using only DM subscriptions, all attributes that are subscribed at a given class must necessarily be all subscribed with the same passive subscription indicator value (either passive or active). However, when a federate subscribes to object class attributes using DDM subscriptions, it is possible for the federate to be subscribed to the same attribute at a given object class both passively and actively (as long as they are subscribed with different regions). The parameter information present in the HLAreportObjectClassSubscription interaction is not flexible enough to both meet the constraint that at most one interaction of the class HLAmanager.HLAfederate.HLAreport.HLAreportObjectClassSubscription shall be sent for each object class subscribed, and to accurately convey whether these subscriptions are either active, passive, or both active and passive. The text must be changed in order to enable the service to accurately reflect DDM usage.

The definition of the HLAmanager.HLAfederate.HLArequest.HLArequestSuscriptions interaction says that this interaction shall result in one interaction of class HLAmanager.HLAfederate.HLAreport.HLAreportInteractionSubscription and one interaction of class HLAmanager.HLAfederate.HLAreport.HLAreportObjectClassSubscription for each object class published. Instead, it is recommended that the text be changed to say that it shall result in one interaction of class HLAmanager.HLAfederate.HLAreport.HLAreportInteractionSubscription and one interaction of class HLAmanager.HLAfederate.HLAreport.HLAreportObjectClassSubscription for each different combination of (object class, passive subscription indicator) values that are subscribed. (Note that the change of the word "published" to "subscribed in the suggested preceding revision is a correction of what is believed to be a typographical error.)

In other words, if a federate is subscribed to a given object class and class attribute with the same passive/active subscription indicator value either with multiple DDM subscriptions or with one or more DDM subscriptions and a DM subscription, that (object class, attribute, active/passive indicator) triple should only appear in one HLAmanager.HLAfederate.HLAreport.HLAreportObjectClass Subscription interaction that is sent. However, if a federate is subscribed to a given object class and class attribute with different passive/active subscription indicators (at least once actively and at least once passively), either with multiple DDM subscriptions or with one or more DDM subscriptions and a DM subscription, that (object class, attribute, active/passive indicator) triple should appear in two separate HLAmanager.HLAfederate.HLAreport.HLAreportObjectClass Subscription interactions that are sent, one of which has an HLAactive parameter value of HLAtrue, and one of which has an HLAactive parameter value of HLAfalse.

In addition, the HLAnumberOfClasses parameter shall represent the count of the number of different (object class, active/passive subscription indicator) values being reported. This number shall not exceed twice the number of different object classes that are subscribed.

Similarly, if a federate is subscribed to a given interaction class with the same active/passive subscription indicator value with both a DDM subscription and a DM subscription, that (interaction class, active/passive indicator) pair should appear only once in the HLAmanager.HLAfederate.HLAreport.HLAreportInteractionSubscription interaction that is sent. However, if a federate is subscribed to a given interaction class with different active/passive subscription indicators (once actively and once passively), once with a DDM subscription and once with a DM subscription, that (interaction class, active/passive indicator) pair should appear twice in the HLAmanager.HLAfederate.HLAreport.HLAreportInteractionSubscription interaction that is sent, once with an HLAactive parameter value of HLAtrue, and once with an HLAactive parameter value of HLAfalse.

see above

It is not clear what the format of the HLAFDDID attribute of the MOM HLAmanager.HLAfederation object class and the HLAFDDID attribute of the MOM HLAmanger.HLAfederate object class should be. It is recommended that the following clarifying text be added:

The HLAFDDID attribute of the MOM HLAmanager.HLAfederation object class
is defined as the "identifier associated with the FDD used in the relevant Create Federation Execution service invocation". In particular, this identifier shall be the same as the FOM document designator argument that was supplied in the Create Federation Execution service when the federation execution was created. However, all of the path-specific information shall have been removed from the designator and, if this designator took the form of a URL, all of the URL-specific information shall also have been removed.

There is also an HLAFDDID attribute of the MOM HLAmanager.HLAfederate object class that is defined as the "identifier associated with the FDD used in the joined federate". This identifier shall be the same as the FOM document designator argument that was supplied in the Create Federation Execution service when the federation execution was created.

Add the suggested clarifying text.

It is not clear what behavior is expected in the case in which the HLAmanager.HLAfederate.HLArequest.HLArequestSynchronizationPointStatus interaction is sent when there are no active synchronization points in the federation execution. It is recommended that the following text be provided to clarify this situation:

One interaction of class HLAmanger.HLAfederate.HLAreport.HLAreportSynchronizationPointStatus shall be sent by the RTI for each active synchronization point in the federation execution. If there are no active synchronization points in the federation execution, no HLAmanger.HLAfederate.HLAreport.HLAreportSynchronizationPointStatus interaction shall be sent.

Add text clarifying the specified case, as suggested.

As currently written, the standard does not discuss what parameters shall be supplied when a federate sends MOM interactions. In order for the RTI to be able to send a HLAmanager.HLAfederate.HLAreport.HLAreportMOMexception interaction when a MOM interaction is sent without all the necessary parameters, it must be well-defined as to what the necessary parameters for each interaction are. It is recommended that clarifying text be added that defines what parameters must be required when the federate sends MOM interactions. The following text is recommended:

Unless specifically noted otherwise in Table 17, when a federate sends an interaction, it shall always supply all pre-defined parameters that are available at that interaction class and no more, with the following exceptions:

· the HLAfederate parameter of the HLAmanger.HLAfederate.HLArequest.HLArequestSynchronizationPoints interaction is not required
· the HLAfederate parameter of the HLAmanger.HLAfederate.HLArequest.HLArequestSynchronizationPointStatus interaction is not required
· a federate shall not be required to supply parameters of any HLAmanager.HLAfederate.HLAservice interaction that correspond to optional arguments of the HLA service that the HLAmanager.HLAfederate.HLAservice interaction is intended to cause to be invoked on behalf of another federate. (For example, HLAattributeList is not a required parameter of the HLAmanager.HLAfederate.HLAservice.HLAunpublishObjectClassAttributes interaction because the set of attribute designators argument of the Unpublish Object Class Attributes service is an optional argument to that service)
· a federate shall be required to supply either the HLAautoProvide parameter or the HLAconveyRegionDesignatorSets parameter (or both) of the HLAmanager.HLAfederation.HLAadjust.HLAsetSwitches interaction.

see above

The value of the HLAfederate parameter is not relevant to the other information that is provided in the HLAmanager.HLAfederate.HLAreport.HLAreportSynchronizationPoints or the HLAmanager.HLAfederate.HLAreport.HLAreportSynchronizationPointStatus interactions. These interactions are more like HLAmanger.HLAfederation than HLAmanager.HLAfederate interactions. There is no reason that the RTI should supply the HLAfederate parameter when sending these MOM interactions.

Similarly, if a federate does not know an object instance, then that object instance has no known class at that federate. Therefore, there is no valid value of the HLAknownClass parameter of a HLAmanger.HLAfederate.HLAreport.HLAreportObjectInstanceInformation interaction that can be sent for this federate and object instance.

Clause 11.4.1 (d) states that, "When sending an interactions of one of the leaf classes in Table 5, the RTI shall always supply all parameters listed in Table 7 for that interaction class, and no more." It is recommended, however, that the text be amended to allow for the following exceptional cases (described above) in which the RTI shall not supply all the parameters:
· the HLAfederate parameter of the HLAmanger.HLAfederate.HLAreport.HLAreportSynchronizationPoints interaction shall not be supplied
· the HLAfederate parameter of the HLAmanger.HLAfederate.HLAreport.HLAreportSynchronizationPointStatus interaction shall not be supplied
· the HLAknownClass parameter of the HLAmanger.HLAfederate.HLAreport.HLAreportObjectInstanceInformation interaction shall not be supplied if the HLAfederate parameter of this interaction specifies a joined federate that does not know the object instance specified by the HLAobjectInstance parameter of this interaction.

Amend the text to allow for the exceptional cases, as suggested.

When a federate is in the Federate Restore In Progress state, the identity of that federate, being in a possible state of flux, is undefined. When at least one federate in the federation execution is in the Federate Restore In Progress state, it does not make sense for the RTI to maintain the values of instance attributes of HLAmanager.HLAfederate object instances, because it is not clear to which federate any given HLAmanager.HLAfederate object instance corresponds, nor is it clear at which federate an update to such an instance attribute should be reflected. So, while under normal circumstances, if a service invocation occurs that causes the HLAfederateState of a HLAmanager.HLAfederate object instance to change value, then the corresponding instance attribute should be updated, there is an exception to this rule. The state of each HLAmanger.HLAfederate object instance is in flux during a restore. Only after all federates have restored successfully and moved back into the Active Federate state should the RTI resume maintaining the values of instance attributes of HLAmanager.HLAfederate object instances. Therefore, it is recommended that the text be amended to make clear that when a federate's state changes from that of Active Federate to that of Federate Restore In Progress, no updates are expected. In fact, the MOM is not expected to update any instance attribute values after the first Federation Restore Begun † callback is invoked at any federate in the federation execution and before the last Federation Restored † callback is invoked at some federate for a given federation restoration.

see above

Some parameter definitions in Table 17 indicate that under certain circumstances the value of a MOM interaction parameter shall be null. For example, according to Table 17, if the specified service does not normally return a value, then the HLAreturnedArgument parameter of the HLAmanager.HLAfederate.HLAreport.HLAreportServiceInvocation interaction shall be null. Also, if the value of the HLAsuccessIndicator parameter of the HLAmanager.HLAfederate.HLAreport.HLAreportServiceInvocation interaction is HLAtrue, then the value of the HLAexception parameter shall be null. By "null" the text should make clear that the expectation is that the parameter/value pair set will be present in the interaction, but the value will be an empty (zero-length) array.

Clarify the meaning of the term “null”, as suggested.

Item (g) shall refer to Table 6, the MOM attribute table, instead of Table 4.

Change the text as suggested.

Some attribute definitions in Table 16 indicate that under certain circumstances the value of a MOM attribute shall be null. For example, according to Table 16, if no saves have occurred, the value of the HLAlastSaveName attribute shall be null. By "null" the expectation is that the attribute/value pair set will be present in the reflect, but the value will be an empty (zero-length) array.

Explain the meaning of “null”, as suggested.

It is not clear whether the HLAreflectionsReceived attribute shall have as value the total number of times the Reflect Attribute Values † service has been invoked at the joined federate or the number of instance attribute value reflections that have been received at the joined federate. It is recommended that the following clarifying text be provided:

The HLAreflectionsReceived attribute shall have as value the total number of times the Reflect Attribute Values † service has been invoked at the joined federate (as opposed to the number of instance attribute value reflections have been received at the joined federate

Add the suggested clarifying text.

It needs to be clarified that this interaction shall report the number of object instances (by registered class of the object instances) for which the joined federate has successfully invoked the Update Attribute Values service.

Add the word “successfully” to the table entry.

Text in this section currently states, "The RTI shall be responsible for
attempting to find an owner for instance attributes that are left unowned
(either via registration, federate resignation, or some form of divestiture).
The RID provided to an RTI may allow the federation to control how often or for
how long an RTI will attempt to find an owner for unowned instance
attributes." This text should not be considered to be part of the standard.
The first sentence states a requirement that the RTI be responsible for
something without explaining the mechanism by which the RTI is expected to
fulfill this requirement. The second sentence, about the RID, is simply out of
place in the standard, as it refers to implementation-specific behavior.

Without explanation of the mechanism by which the RTI is expected to fulfill
its responsibility, this text in its current unqualified form violates a
guiding principle of the HLA specification, which is the principle of minimum
astonishment. If no federates in a federation execution are using some aspect
of the HLA specification (such as, in this case, ownership management) then no
federates in the federation execution should receive service invocations
related to that aspect of the specification that is not in use. In particular,
this text would result in the following circumstance: Suppose there is a
federation execution in which no ownership management services are explicitly
invoked by any federate and there are two attributes, x and y, available at
object class A.
Fed1 invokes Publish Object Class Attributes (A,

)
Fed2 invokes Subscribe Object Class Attributes (A,

)
Fed1 registers an instance, object1, of class A
Fed2 discovers object1
Fed2 would receive a Request Attribute Ownership Assumption callback for
instance attribute y of object1. This service invocation would be astonishing
to a federate such as federate 2 that is not using ownership management.

Similarly astonishing callbacks would also be received by eligible federates in
the following two situations that do not involve any explicit use of ownership
management:

• an owning federate unpublishes a class attribute, thereby causing a
  corresponding instance attribute to become unowned
• a non-owning federate begins publishing a class attribute at the known class
  of an object instance that has a corresponding instance attribute that is
  unowned.

In other issues that we raise with respect to IEEE 1516.1-2000 (interpretations
for Unconditional Attribute Ownership Divestiture and Resign Federation
Execution), we suggest text that explains the mechanism according to which the
RTI is expected to fulfill its responsibility for attempting to find an owner
for unowned instance attributes when they become unowned as a result of the use
of an explicit ownership management service or directive. However, there is no
suggestion that the RTI should try to find an owner for unowned instance
attributes when they either become unowned as a result of registration or
unpublishing a class attribute, or when a non-owning federate that was not
previously eligible to own the unowned instance attribute becomes eligible to
do so.

Delete the text as suggested.

This service description does not explain or even mention the mechanism
according to which the RTI is expected to try to find an owner for unowned
instance attributes that become unowned as the result of invocation of the
Resign Federation Execution service with directive 1, 4, or 5 (all of which
involve ownership management). Text needs to be added that explains this
mechanism, which should work as follows:

If a federate invokes this service with either directive 1, 4, or 5, then for
each instance attribute that becomes unowned as a result, then if no joined
federates are in either the “Acquiring” or “Willing to Acquire” state with
respect to the specified instance attribute, the RTI shall try to identify
other joined federates that are willing to own the instance attribute. If any
joined federate is in either the “Acquiring” or “Willing to Acquire” state with
respect to the specified instance attribute, the RTI may try to identify other
joined federates that are willing to own the instance attribute. The mechanism
that the RTI shall use to try to identify other joined federates that are
willing to own the instance attribute is invocation of the Request Attribute
Ownership Assumption † service at all joined federates that are both eligible
to own the instance attribute and not in either the “Acquiring” or “Willing to
Acquire” state with respect to the specified instance attribute.

Add the suggested text.

This service description does not explain or even mention the mechanism
according to which the RTI is expected to try to find an owner for unowned
instance attributes that become unowned as the result of the invocation of the
Unconditional Attribute Ownership Divestiture service. Text needs to be added
that explains this mechanism, which should work as follows:

For each instance attribute that becomes unowned as a result of invocation of
this service, if no joined federates are in either the “Acquiring” or “Willing
to Acquire” state with respect to the specified instance attribute, the RTI
shall try to identify other joined federates that are willing to own the
instance attribute. If any joined federate is in either the “Acquiring” or
“Willing to Acquire” state with respect to the specified instance attribute,
the RTI may try to identify other joined federates that are willing to own the
instance attribute. The mechanism that the RTI shall use to try to identify
other joined federates that are willing to own the instance attribute is
invocation of the Request Attribute Ownership Assumption † service at all
joined federates that are both eligible to own the instance attribute and not
in either the “Acquiring” or “Willing to Acquire” state with respect to the
specified instance attribute.

Delete the text as suggested.

Table 17: interaction subclass HLAmanager.HLAfederate.HLAreport.HLAreportReflectionsReceived: no reflects received : It is not clear what interactions should be expected if no reflects of instance attributes of any object instances of a given class or of any class for a given transportation type have been received.

Clarifying text should be added that makes clear that if no reflects of instance attributes of any object instances of any class for a given transportation type have been received, then the RTI shall send a HLAmanager.HLAfederate.HLAreport.HLAreportReflectionsReceived interaction for that transportation type. However, no HLAobjectClassBasedCount elements at all shall appear in the HLAobjectClassBasedCount array for that interaction of that transportation type. In other words, the HLAreportReflectionsReceived interaction that is sent for that transportation type shall have an empty HLAobjectClassBasedCount array.

If no reflects of instance attributes of any object instances of a given class for a given transportation type have been received, then no HLAobjectClassBasedCount element for that object class shall be in the HLAobjectClassBasedCount array of the HLAmanager.HLAfederate.HLAreport.HLAreportReflectionsReceived interaction for that transportation type.

Add the suggested clarifying text.

In table 17, the HLAreturnedArguments parameter is erroneously listed as singular ("HLAreturnedArgument") instead of plural. In order to be consistent with Table 7, the MOM parameter table, this parameter should be named "HLAreturnedArguments

Change the spelling of this argument in Table 17 to be plural.

: MOM Table 17: use of HLAinteractionCounts array datatype in zero-value HLAinteractionCount cases. In all MOM interactions that have a parameter of type HLAinteractionCounts, if an HLAinteractionCount element of the HLAinteractionCounts array would have a value (interaction class, 0), the HLAinteractionCount element shall not be present in the HLAinteractionCounts array. In other words, only HLAinteractionCount elements that have positive counts shall be present in an HLAinteractionCounts array. From this, it follows that if all interaction class counts have a zero value, then the HLAinteractionCounts array shall not have any elements in it; it shall be an empty HLAinteractionCounts array. This interpretation affects the following MOM interactions:
· HLAmanager.HLAfederate.HLAreport.HLAreportInteractionsSent
· HLAmanager.HLAfederate.HLAreport.HLAreportInteractionsReceived

Add the suggested text.

MOM Table 17: use of HLAobjectClassBasedCounts array datatype in zero-value HLAobjectClassBasedCount cases. In all MOM interactions that have a parameter of type HLAobjectClassBasedCounts, if an HLAobjectClassBasedCount element of the HLAobjectClassBasedCounts array would have a value (object class, 0), the HLAobjectClassBasedCount element shall not be present in the HLAobjectClassBasedCounts array. In other words, only HLAobjectClassBasedCount elements that have positive counts shall be present in an HLAobjectClassBasedCounts array. From this, it follows that if all object class counts have a zero value, then the HLAobjectClassBasedCounts array shall not have any elements in it; it shall be an empty HLAobjectClassBasedCounts array. This interpretation affects the following MOM interactions:
· HLAmanager.HLAfederate.HLAreport.HLAreportObjectInstancesThatCanBeDeleted
· HLAmanager.HLAfederate.HLAreport.HLAreportObjectInstancesUpdated
· HLAmanager.HLAfederate.HLAreport.HLAreportObjectInstancesReflected
· HLAmanager.HLAfederate.HLAreport.HLAreportUpdatesSent HLAmanager.HLAfederate.HLAreport.HLAreportReflectionsReceived

Add the suggested text.

The definition of the HLAservice parameter says "Name of the service interaction that had a problem or raised an exception." In the case in which the HLAreportMOMexception interaction is sent by the RTI because a service interaction (an interaction that imitates a federate's invocation of an HLA service) was sent and not all of the service's pre-conditions are met, the value of this parameter is straightforward. However, it is not clear what the value of this parameter should be in the case in which the HLAreportMOMexception interaction is sent by the RTI because a MOM interaction without all of the necessary parameters was sent.

It is recommended that text be added clarifying that in the case in which the HLAreportMOMexception interaction is sent by the RTI because a service interaction (an interaction that imitates a federate's invocation of an HLA service) was sent and not all of the service's pre-conditions are met, the value of this parameter shall be the name of the HLAinteractionRoot.HLA.Manager.HLAfederate.HLAservice interaction that was sent. In the case in which the HLAreportMOMexception interaction is sent by the RTI because a MOM interaction without all of the necessary parameters was sent, the value of this parameter shall be the name of the class of the interaction that was sent.

see above

The introductory text says, “The returned joined federate designator shall be
unique for the lifetime of the federation execution.” However, during a restore
operation, when the Initiate Federate Restore + service is invoked at a federate,
one of the supplied arguments is a joined federate designator, with the result that
the Initiate Federate Restore + service could cause a joined federate’s designator
to change from the value supplied by the Join Federation Execution service. This
means that while a restore is in progress at one or more federates, it is possible
that two different federates could have the same joined federate designator, one
federate having the designator that was supplied to it by the Join Federation
Execution service and one federate having the designator that was supplied to it by
the Initiate Federate Restore + service. Therefore, the introductory text of the
Join Federation Execution service should be amended to say that “The returned
joined federate designator shall be unique for the lifetime of the federation
execution, as long as a restore is not in progress at any federate.”

Add the text suggested in the issue statement.

The Confirm Divestiture service (7.6) shall also raise the following exception: NoAcquisitionPending

see above

The name of the interaction class provided shall always be fully qualified, as defined in the OMT, so as to avoid potential ambiguities.

Add text explaining this requirement

As pre-condition (c) of the Start Registration For Object Class service (clause 5.10) is now worded, the Start Registration For Object Class service could be received at a publishing federate even if it were the case that if that publishing federate were to register an instance of the specified class, no other federate in the federation execution would discover the object instance. This does not appear to meet the stated intent of the Start Registration For Object Class service to "notify the joined federate that registration of new object instances of the specified object class is advised". Precondition (c) should be amended to specify that the object class at which the subscribing federate is actively subscribed to the attribute must be the subscribing federate's candidate discovery class of an object instance registered at the specified object class.

see above

The service description of Subscribe Object Class Attributes (clause 5.6) needs to more completely describe the intended effect of the optional passive subscription indicator. It needs to explain what should happen with regard to the active/passive nature of a subscription in the event that a subscription is made for a class attribute that is not already subscribed. Furthermore, the text does not make clear whether the active/passive characteristic applies on a per-attribute or a per-class basis.

see above

The way the definition of "in-scope" is currently worded, it is not possible for federates to receive Attributes In Scope callbacks for any instance attributes corresponding to pre-defined MOM object class attributes. Item (b) of the in-scope definition should be changed to "The instance attribute is owned either by another joined federate or by the RTI, and". This will allow MOM instance attributes to come into scope, MOM object instances to be discovered, and MOM instance attributes to be reflected.

see above

As pre-condition (d) of the Stop Registration For Object Class service (clause 5.11) is now worded, the Stop Registration For Object Class service could be received at a publishing federate even if it were the case that if that publishing federate were to register an instance of the specified class, some other federate in the federation execution would discover the object instance. This does not appear to meet the stated intent of the Stop Registration For Object Class service to "notify the joined federate that registration of new object instances of the specified object class is not advised". Precondition (d) should be amended to specify that none of the class attributes that the joined federate is publishing at the specified object class is actively subscribed to by any other joined federate in the federation execution at what would be the subscribing federate's candidate discovery class of an object instance registered at the specified object class.

see above

The way that pre-condition (d) of this service is now worded, it is not possible for a federate to discover MOM object instances. This pre-condition should instead say that class attribute "att's corresponding instance attribute that is part of the specified object instance is either owned by another joined federate or owned by the RTI". A corresponding change is also required in clause 6.1 where the conditions for the invocation of the Discover Object Instance † are defined. The first sub-bullet of item b in this definition should read, "either another joined federate (not F) or the RTI owns i, and

see above

According to this service description, "the handle provided to the joined federate which registers the object instance shall be the same handle provided to all joined federates which discover the object instance."

The phrase "the same handle" is meant to refer to handle equality rather than handle identity. The handles provided to each federate must be equal, but they do not have to be the same programming language object. Two handles are considered to be the same if, according to the comparison operator in each of the APIs (for example, according to the "equals" method in the Java API) the handles would be determined to be equal. The handles must also have equality between federates that are using different language APIs. The handles may be communicated between federates via instance attributes or interaction parameters.

Add text clarifying the meaning of “the same handle”

Many services in 1516.1 have preconditions and exceptions that are worded simply "Save in progress" or "Save not in progress". However, these states do not appear to be well-defined in the standard. It should be made clear that these are meant to refer to the "Federate Save in Progress" state as shown in the statechart in Figure 3. A save is considered to be in progress at a given federate if the federate is in the "Federate Save in Progress" state.

The definition of these pre-conditions should be clarified.

Part (a) of definition 3.1.66, the definition of "published", does not say that in order to be considered to be published, an object class has to have been an argument to the Publish Object Class Attributes service along with an at least one attribute that is available at that object class. In order to be consistent with the rest of the standard, it should read (changes shown in boldface) "pertaining to an object class such that, from the perspective of a given joined federate, there is at least one attribute available at that object class that, along with the object class, was an argument to a Publish Object Class Attributes service invocation that was not subsequently unpublished at that object class via the Unpublish Object Class Attributes service."

see above

Use of the phrase "joined federate-owned" in pre-condition (e) of the Unpublish Object Class Attributes service (clause 5.3) implies that a federate could invoke the Attribute Ownership Acquisition service or the Attribute Ownership Acquisition If Available service on an instance attribute that the federate already owns. However, that would be inconsistent with the rest of the 1516.1 standard. The phrase "joined federate-owned" should be deleted from this precondition.

Delete the phrase “joined federate-owned” from this precondition.

The introductory text for the Publish Object Class Attributes service (clause 5.2) says that one of the ways that a joined federate may become the owner of an instance attribute is

• By using ownership management services to acquire instance attributes of object instances. The joined federate may acquire only those instance attributes for which the joined federate is publishing the corresponding class attributes.
  Because this text does not mention at what class the joined federate must be publishing the corresponding class attributes, it is not consistent with the rest of the standard, which asserts that the joined federate mush be publishing the corresponding class attributes at the known class of the object instance.

Add clarifying text.

When a federate receives an Initiate Federate Restore † callback, one of the supplied arguments of this service is a joined federate designator. So, as a result of the invocation of the Initiate Federate Restore † service, a joined federate's designator could change. This means that while a federate is in the Federate Restore In Progress state, its identity is basically undefined. Given that a precondition of the invocation of the Query Federation Restore Status service (clause 4.24) is that a restore is in progress, it is not clear what list of joined federate designators would be reported while a restore is in progress, nor is it necessarily clear at which federate the Federation Restore Status Response † service should be invoked. In fact, it is not clear that any meaningful information about the list of joined federates in the federation execution could be reported via the Federation Restore Status Response † service while a restore is in progress.

It should be pointed out that the behavior of this service is not testable.

The history transition on the right side of Figure 11: Class Attribute (i, HLAprivilegeToDeleteObject), which is now labeled "Publish (i,{}) or Unpublish(i,{})", is inconsistent with the rest of the 1516.1 standard. This history transition should instead be labeled, "Subscribe(i,{}) or Unsubscribe (i,{})".

Modify the label on this history transition so that it is correct.

The history transition on the right side of Figure 10: Class Attribute (i,j), which is now labeled "Publish (i,{}) or Unpublish(i,{})", is inconsistent with the rest of the 1516.1 standard. This history transition should instead be labeled, "Subscribe(i,{}) or Unsubscribe (i,{})".

Modify the label on this history transition so that it is correct.

Many services in 1516.1 have preconditions and exceptions that are worded simply "Restore in progress" or "Restore not in progress". These states, like the "Save in progress" "Save not in progress" states, need to be well-defined. It is recommended that text be added that clarifies that a restore is considered to be in progress at a given federate if the federate is in the "Federate Restore in Progress" state.

The definition of these pre-conditions should be clarified.

On the left hand side of the statechart in Figure 12: Interaction Class (m), the transitions between the "Unpublished (m)" state and the "Published (m)" state should read "Publish (m)" and "Unpublish (m)", rather than simply "Publish" and "Unpublish".

Modify the statechard labels accordingly.

96. Issue Title: Table 17: interaction subclass HLAmanager.HLAfederate.HLAreport.HLAreportUpdatesSent: no updates sent
Page: 243
Nature of Issue: Clarification/Enhancement/Revision
Severity of Issue: Minor/Significant/Critical
Full Description of the Issue:

It is not clear what interactions should be expected if no updates of instance attributes of any object instances of a given class or of any class for a given transportation type have been sent.

Clarifying text should be added that makes clear that if no updates of instance attributes of any object instances of a given class or of any class for a given transportation type have been sent then the RTI shall send a HLAmanager.HLAfederate.HLAreport.HLAreportUpdatesSent interaction for that transportation type. However, no HLAobjectClassBasedCount elements at all should appear in the HLAobjectClassBasedCount array for that interaction of that transportation type. In other words, the HLAreportUpdatesSent interaction that is sent for that transportation type will have an empty HLAobjectClassBasedCount array. (This is illustrated by interaction 2 in the example below.)

If no updates of instance attributes of any object instances of a given class for a given transportation type have been sent, then no HLAobjectClassBasedCount element for that object class should be in the HLAobjectClassBasedCount array of the HLAmanager.HLAfederate.HLAreport.HLAreportUpdatesSent interaction for that transportation type.

Add the suggested clarifying text.

Table 17: interaction subclass HLAmanager.HLAfederate.HLAreport.HLAreportUpdatesSent: how defined: With regard to the definition of the HLAupdateCounts parameter in the HLAReportUpdatesSent interaction subclass given in Table 17 it is not clear whether the number of updates is defined as the number of times the Update Attribute Values service was invoked by the federate for all object instances of a given object class, or the number of instance attribute updates that were accomplished by the federate for all object instances of a given object class.

Text should be added that clarifies that the number of updates is defined as the number of instance attribute updates. That is, if a federate has invoked the Update Attribute Values service only once, and in this service invocation were arguments for an object instance of class A and n instance attributes of type reliable and m instance attributes of type best-effort, then in response to an interaction of class Manager.Federate.Request.RequestUpdatesSent, two Manager.Federate.Report.ReportUpdatesSent interactions should be sent: one for transportation type reliable with an update count of n and one for transportation type best-effort with an update count of m. If that federate then invokes the Update Attribute Values service for an object instance of class A and one of the same instance attributes that was updated in the previous update of type reliable, then in response to an interaction of class Manager.Federate.Request.RequestUpdatesSent, two Manager.Federate.Report.ReportUpdatesSent interactions should be sent: one for transportation type reliable with an update count of n+1 and one for transportation type best-effort with an update count of m.

Add the suggested clarifying text.

Table 17: interaction subclass HLAmanager.HLAfederate.HLAreport.HLAreportReflectionsReceived: how defined. As currently worded, the text is not clear as to whether the number of reflections received is defined as the number of times the Reflect Attribute Values † service was invoked at the federate for all object instances of a given object class, or the number of instance attribute value reflections by the federate for all object instances of a given object class.

It is recommended that text be added to clarify that the number of reflections is defined as the number of instance attribute value reflections. That is, if a federate has received the Reflect Attribute Values † service invocation twice, and in one of these service invocations were arguments for an object instance of class A and n instance attributes of type reliable, and in another of these service invocations were arguments for an object instance of class A and m instance attributes of type best-effort, then in response to an interaction of class Manager.Federate.Request.RequestReflectionsReceived, two Manager.Federate.Report.ReportReflectionsReceived interactions should be sent: one for transportation type reliable with a reflect count of n for object class A, and one for transportation type best-effort with a reflection count of m for object class A. Furthermore, if that federate receives an additional Reflect Attribute Values † service invocation for an object instance of class A that contains a single attribute/value pair as argument, and the attribute is a reliable attribute that had also had a value reflected previously, then in response to an interaction of class Manager.Federate.Request.RequestReflectionsReceived, two Manager.Federate.Report.ReportReflectionsReceived interactions should be sent: one for transportation type reliable with a reflect count of n + 1 for object class A, and one for transportation type best-effort with a reflection count of m for object class A

Add the suggested clarifying text.

These attributes are defined as the wall-clock time duration that the federate has spent in a given state since the last time the attributes were updated. It does not specify what the value of these attributes should be if they have not yet been updated. Clarifying text should be added to indicate that the first time that the HLAtimeGrantedTime and the HLAtimeAdvancingTime attributes are updated, their values shall be zero to indicate that they have never before been updated.

Add the suggested clarifying text.

Clarifying text should be added to indicate that the value of the HLAobjectInstancesDiscovered attribute shall include multiple invocations of the Discover Object Instance † service for a given object instance that may occur as a result of invocation of the Local Delete Object Instance service at a federate.

Add the suggested clarifying text.

According to the attribute definitions in Table 16, the HLAlastSaveTime value shall not be defined if no timed saves have occurred, but it is not clear what is meant by "not defined". It is recommended that text be added that clarifies that the expectation is that the attribute/value pair set will be present in the reflect, but the value will be an empty (zero-length) HLAlogicalTime array.

Add the suggested clarifying text.

It is not clear whether the HLAupdates Sent attribute should have as value the total number of times the Update Attribute Values † service has successfully been invoked by the joined federate or the number of instance attribute values that have been updated by the joined federate. It is recommended that the following clarifying text be provided:

The HLAupdatesSent attribute shall have as value the total number of times the Update Attribute Values † service has successfully been invoked by the joined federate (as opposed to the number of instance attribute values that have been updated by the joined federate).

Add the suggested clarifying text.

Clarifying text should be added to indicate that the HLAobjectInstancesDeleted attribute shall be defined as the total number of times that the Delete Object Instance service was successfully invoked by the joined federate since the federate joined the federation.

Add the following to 1.4.9:

Clarifying text should be added to indicate that the HLAobjectInstancesUpdated attribute shall be defined as the total number of object instances for which the joined federate has successfully invoked the Update Attribute Values service.

Add the word “successfully” to the text.

If the most recent save was not a timed save, then, according to how the text is currently written, the value of the HLAlastSaveName attribute would not correspond to the value of the HLAlastSaveTime attribute. To correct this, it is recommended that text be added to indicate that the HLAlastSaveTime attribute shall have the value of the time of the last save, not of the last timed save. If the last save was not a timed save, then the HLAlastSaveTime attribute value shall be an empty HLAlogicalTime array to indicate that the value of the HLAlastSaveTime attribute is undefined.

Add the recommended text.

It is not clear what the value of the HLAreportPeriod should be if no interaction of class HLAmanager.HLAfederate.HLAadjust.HLAsetTiming has been sent. It is recommended that text be added that clarifies that if no interaction of class HLAmanager.HLAfederate.HLAadjust.HLAsetTiming has been sent, then no periodic updates of MOM attribute values shall be generated and the value of the HLAreportPeriod is not defined and should be represented as zero.

Add the suggested explanatory text.

According to the attribute definitions in Table 16, the HLAnextSaveTime value shall not be defined if no timed saves are scheduled. However, it is not clear what is meant by "not defined". Text should be added to clarify that the expectation is that the attribute/value pair set will be present in the reflect, but the value will be an empty (zero-length) HLAlogicalTime array.

Add the suggested clarifying text.

Clarifying text should be added to indicate that the HLAobjectInstancesRegistered attribute shall be defined as the total number of times that the Register Object Instance service and the Register Object Instance With Region service were successfully invoked by the joined federate since the federate joined the federation.

Add the suggested clarifying text.

If there are no federates in the federation execution that are in the
"Acquisition Pending" or "Willing to Acquire" state with respect to the specified instance attribute, the federate that owns the instance attribute shall be prohibited from invoking the Confirm Divestiture service for that instance attribute. If the owning federate were to be allowed to invoke the Confirm Divestiture service under these circumstances, this would result in the instance attribute becoming unowned by all federates, which shall never be allowed to happen as a result of a negotiated divestiture. Therefore, the owning federate shall be prevented from invoking the Confirm Divestiture service under these circumstances. To enforce this prohibition, the following changes need to be made to this service description:

There shall be an additional pre-condition to this service that says:

There is at least one federate in the federation that is in either the "Acquisition Pending" or the "Willing to Acquire" state with respect to the specified instance attribute.

There shall be an additional exception to this service that says:

There is no joined federate that has an acquisition pending or that is willing to acquire the instance attribute.

There shall be additional introductory text that says, if a federate invokes the Confirm Divestiture service and, as a result, an exception is thrown indicating that there is no joined federate that has an acquisition pending or that is willing to acquire the instance attribute, then that federate shall transition from the Completing Divestiture state with regard to that instance attribute into the Waiting for a New Owner to be Found state with regard to that instance attribute.

see above

The following additional pre-condition should be added to this service, "The joined federate is not in either the "Acquiring" or the "Willing to Acquire" state for this instance attribute." This additional pre-condition is already a requirement as expressed by the guard on the Request Attribute Ownership Assumption transition in the statechart in Figure 15. It should be present in the pre-conditions for clarity and consistency.

Add the suggested pre-condition.

Text in this section currently states, "The RTI shall be responsible for attempting to find an owner for instance attributes that are left unowned (either via registration, federate resignation, or some form of divestiture). The RID provided to an RTI may allow the federation to control how often or for how long an RTI will attempt to find an owner for unowned instance attributes." It should be pointed out that the standard does not require that the RTI try to find an owner within a certain amount of time.

rejected, see above

It should be noted in conjunction with this service that the standard is silent regarding what will happen in the case in which a federate attempts to take ownership of an instance attribute of an object instance for which another federate has already scheduled a timed deletion. That is, if a federate schedules the deletion of an object instance for a time in the future, that object instance may still be discovered by other federates, and updates to instance attributes of that object instance may still be received by other federates, until their logical times are greater than or equal to the specified time of the deletion. If those other federates are allowed to take ownership of any of the instance attributes owned by the federate that scheduled the delete, then it would be possible for strange things to occur within the federation execution, such as a federate that owns the HLAprivilegeToDelete instance attribute of an object instance receiving a Remove Object Instance † callback for that object instance. The standard does not specify the RTI's behavior in such circumstances.

Add text that addresses this issue.

This section explains that the user-supplied tags that are present in some federate-invoked services shall be present in the specified resulting RTI-invoked services. It does not explain, however, what the user-supplied tags should be in those RTI-invoked services that are not the result of a federate-invoked service. The text should be clarified to indicate that if an RTI-invoked service is not the result of a federate-invoked service, but the RTI-invoked service has a user-supplied tag as a mandatory argument, the user-supplied tag shall be empty. For example, in the Java API, the tag should be an empty (zero-length) array.

Clarify the text as suggested.

If one or more joined federates are in either the "Acquiring" or "Willing to Acquire" state with respect to the specified instance attribute, it is not clear whether the RTI is obligated to try to identify other joined federates that are willing to own the instance attribute. Clarifying text should be added that makes clear that if any joined federate is in either the "Acquiring" or "Willing to Acquire" state with respect to the specified instance attribute, the RTI may, but is not obligated to, try to identify other joined federates that are willing to own the instance attribute. The mechanism that the RTI shall use to try to identify other joined federates that are willing to own the instance attribute is invocation of the Request Attribute Ownership Assumption † service at all joined federates that are both eligible to own the instance attribute and not in either the "Acquiring" or "Willing to Acquire" state with respect to the specified instance attribute.

Add the suggested clarifying text.

As the statechart is now depicted, it is not clear what should happen if a federate invokes the Attribute Ownership Acquisition service for an instance attribute that is already in the "Acquisition Pending" state. The following change should be made to the statechart to indicate that the instance attribute's state shall remain unchanged: there shall be a history state added within the Acquisition Pending state, and there shall be a self-transition from this history state to itself, labeled "Attribute Ownership Acquisition".

Add the suggested history state and the suggested self-transition to figure 15.

If there are no federates in the federation execution that are in the
"Acquisition Pending" or "Willing to Acquire" state with respect to the specified instance attribute, the federate that owns the instance attribute shall be prohibited from invoking the Confirm Divestiture service for that instance attribute. If the owning federate were to be allowed to invoke the Confirm Divestiture service under these circumstances, this would result in the instance attribute becoming unowned by all federates, which shall never be allowed to happen as a result of a negotiated divestiture. Therefore, the owning federate shall be prevented from invoking the Confirm Divestiture service under these circumstances. This prohibition needs to be incorporated into the statechart in Figure 15 in the following way: the transition from the Completing Divestiture state into the Able to Acquire state that currently has as the label "Confirm Divestiture", should have its label modified to read, "Confirm Divestiture (successful)".

Change the label on the transition in Figure 15, as suggested.

This service description now reads, "The invoking joined federate shall continue its update responsibility for the specified instance attributes until it divests ownership via the Confirm Divestiture service." This implies that the only manner in which the federate can divest ownership is by invoking the Confirm Divestiture service, which is not true. This sentence should be changed to read simply, "The invoking joined federate shall continue its update responsibility for the specified instance attributes until it divests ownership

Change the text as suggested.

As the statechart is now depicted, it is permissible for an owning federate that is in the Waiting for a New Owner to be Found state to receive a Request Attribute Ownership Release † callback. However, if a federate is in the Waiting for a New Owner to be Found state and another federate invokes the Attribute Ownership Acquisition service, the owning federate should receive a Request Divestiture Confirmation † callback; the owning federate should not receive a Request Attribute Ownership Release † callback. Therefore, to make this prohibition clear, a guard shall be added to the existing Request Attribute Ownership Release † history transition in the Owned state. The guard shall be: [not in "Waiting for a New Owner to be Found"].

see above

As the statechart is now depicted, it is not clear what should happen if a federate invokes the Attribute Ownership Acquisition If Available service for an instance attribute that is already in the "Willing to Acquire" state. The following change should be made to the statechart to indicate that the instance attribute's state shall remain unchanged: there shall be an additional transition added that is a self-transition from the Willing to Acquire state to itself that is labeled "Attribute Ownership Acquisition If Available [not in 'Acquisition Pending']".

Add the suggested self-transition to Figure 15.

If there are no federates in the federation execution that are in the
"Acquisition Pending" or "Willing to Acquire" state with respect to the specified instance attribute, the federate that owns the instance attribute shall be prohibited from invoking the Confirm Divestiture service for that instance attribute. If the owning federate were to be allowed to invoke the Confirm Divestiture service under these circumstances, this would result in the instance attribute becoming unowned by all federates, which shall never be allowed to happen as a result of a negotiated divestiture. Therefore, the owning federate shall be prevented from invoking the Confirm Divestiture service under these circumstances. This prohibition needs to be incorporated into the statechart in Figure 15 by adding a transition from the Completing Divestiture state into the Waiting for a New Owner to be Found state that has as a label "[Confirm Divestiture and NoAcquisitionPending exception thrown]".

Add the suggested transition to the statechart in Figure 15.

The second sentence of this service description reads, "The interaction parameters shall only be those in the specified class and all super-classes, as defined in the FDD." This statement should be clarified by indicating that only parameters that are available at that interaction class may be sent in a given interaction, but a federate is not required to send all available parameters of the interaction class with the interaction.

Clarify the text as suggested.

The introductory text to the Attribute Ownership Acquisition service says, "If a
specified instance attribute is owned by another joined federate, the RTI shall
invoke the Request Attribute Ownership Release † service for that instance
attribute at the owning joined federate."

This text should be replace with the following, "If a specified instance attribute
is owned by another joined federate, and that owning federate is in the "Not
Divesting" state with respect to the instance attribute, the RTI shall invoke the
Request Attribute Ownership Release † service for that instance attribute at the
owning joined federate. If a specified instance attribute is owned by another
joined federate, and that owning federate is in the "Waiting for a New Owner to be
Found" state with respect to the instance attribute, the RTI shall not invoke the
Request Attribute Ownership Release † service for that instance attribute at the
owning joined federate, but it shall invoke the Request Divestiture Confirmation †
service for that instance attribute at the owning joined federate."

Rationale: The text as originally written implies that if an owning federate is in
the "Waiting for a New Owner to be Found" state and another federate invokes the
Attribute Ownership Acquisition service, the owning federate will receive both a
Request Attribute Ownership Release † and a Request Divestiture Confirmation †
callback. Furthermore, a potentially large number of eligible federates could
invoke the Attribute Ownership Acquisition service. If many federates invoke the
Attribute Ownership Acquisition service, the owning federate will receive a
corresponding large number of Request Attribute Ownership Release † callbacks while
in the “Completing Divestiture” state, and these Request Attribute Ownership
Release † callbacks are useless. The expectation that the owning federate would
receive both the Request Divestiture Confirmation † callback and numerous useless
Request Attribute Ownership Release † callbacks is non-sensical. It requires
additional processing by both the RTI and the federate without providing any added
value. Furthermore, the standard already prohibits the mirror image of this
situation, which involves the question of whether a federate that is already in the
“Willing to Acquire” or “Acquisition Pending” state should receive equally useless
invocations of the Request Attribute Ownership Assumption † callback. Therefore, in
order for the “Owned” state of ownership management to be consistent with the
“Unowned” state of ownership management, and to eliminate unecessary inefficiency,
the text should be
changed as described above.

Furthermore, if this issue is accepted, the Request Attribute Ownership Release
transition in the statechart in Figure 15 needs to have a guard added to it that
says, “ [not in "Waiting for a New Owner to be Found" ^ not in "Completing
Divestiture"]”.

see above

The use of valuetypes for time in the DistributedSimulation IDL require
a user of this cap to provide matching implementations of LogicalTime
and LogicalTimeInterval for both the client federate and RTI. This
would require coordinated efforts to match implementations (perhaps in
different implementation languages) for federates and the RTI. Since a
user of the IDL interface will only be writing code on the client
(federate) side, this approach adds unnecessary complexity. It is
recommended that the abstract valuetype for logical time and logical
time interval be replaced with a double in the section headed “Logical
time, time stamps, and lookahead”, and that the IDL also be changed
analogously, with the forward reference to LogicalTimeInterval being
removed and the definitions of abstract valuetypes LogicalTimeFactory
and LogicalTimeIntervalFactory being removed.

Simplify by replacing the abstract valuetype for logical time with a double.

According to 9.1.2 (d), "Each dimension in the FDD shall have either a default range specified in terms of [0, the dimension's upper bound) or shall have…". To clarify, the default range shall be specified in terms of the bounds [0, the dimension's upper bound); it is not necessary that the default range cover the entire dimension.

Clarify the text as suggested

If the Set Range Bounds service is not called for a given dimension of a region, or the Commit Region Modifications service is not called after the Set Range Bounds service has been invoked for every dimension of that region, then the region will contain one or more dimensions that do not have ranges set, and there will be no way to use this region meaningfully. If some of a region's dimensions do not have ranges, then there is no way to determine whether or not the region overlaps with other regions. The text needs to make clear that the creation of a region specification is accomplished using a sequence of service calls, and all of these service calls must be invoked successfully, in sequence, in order to successfully create a region specification . The following clarifying text is suggested:

If a federate invokes the Create Region service but does not subsequently successfully invoke the Set Range Bounds service for every dimension in the region, followed by a successful invocation of the Commit Region Modifications service for the region, then the federate has not created a region specification. In particular:

· If a federate invokes the Create Region service, followed by an invocation of the Set Range Bounds service for none or some, but not for all, of the dimensions that were specified when the region was created, followed by an invocation of the Commit Region Modifications service for that region, the Commit Region Modifications service shall throw the "Invalid region" exception, because each region designator that is passed to the Commit Region Modifications service is required to have had the Set Range Bounds service invoked at least once for all of its dimensions. The effects of the Set Range Bounds service invocations that were made, if any, are still pending. They will take affect if and when the Set Range Bounds service has been invoked at least once for all of the dimensions of the region, followed by the invocation of the Commit Region Modifications service for that region.

· If a federate invokes the Create Region service, followed by at least one Set Range Bounds service invocation for every one of the dimensions that were specified when the region was created, but does not invoke the Commit Region Modifications service, the region continues to be only a region template, but not a region specification. The effects of the Set Range Bounds service invocations are still pending and will take effect if and when the Commit Region Modifications service is successfully invoked for that region.

The effects of invocation of the Set Range Bounds service for a given region (template or specification) will remain pending until the Commit Region Modifications service is subsequently invoked for that region. If a federate invokes the Set Range Bounds service repeatedly for a given dimension of a given region before invoking the Commit Region Modifications service for that region, the range values provided in the most recent invocation of the Set Range Bounds service will become the range values for that dimension of that region specification.

Add the suggested clarifying text.

When a federate receives the Attribute Ownership Unavailable† callback for an instance attribute, it is no longer in the "Willing to Acquire" state with respect to that instance attribute. Therefore, it is permissible for the federate to stop publishing that instance attribute's corresponding class attribute at the known class of the object instance, providing that there are no other corresponding instance attributes at that same known class that the federate is either "Willing to Acquire", or for which the federate has an "Acquisition Pending". If there is at least one other such instance attribute that the federate is "Willing to Acquire" or for which the federate has an "Acquisition Pending", then the federate must be prohibited from unpublishing the corresponding class attribute of that instance attribute at the known class of the object instance. To reflect this, post-condition (b) of the Attribute Ownership Unavailable † service, like post-condition (b) of the Attribute Ownership Acquisition Notification †, should be amended to say,

"b) The joined federate may stop publishing the corresponding class attributes at the known class of the specified object instance if there are no corresponding instance attributes for which the joined federate has either:…"

Change the text of post-condition (b) of this service as suggested.

A federate that owns an instance attribute and is in the process of divesting it has the option of staying in the "Completing Divestiture" state indefinitely. Therefore, it is not the case that a federate that invokes the Attribute Ownership Acquisition If Available service will necessarily receive either an Attribute Ownership Acquisition Notification † service invocation or a corresponding Attribute Ownership Unavailable † service invocation. If the owning federate stays in the "Completing Divestiture" state indefinitely, the federate that invoked the Attribute Ownership Acquisition If Available service will receive neither a corresponding Attribute Ownership Acquisition Notification † service invocation nor a corresponding Attribute Ownership Unavailable † service invocation. To reflect this state of events, the introductory text to the Attribute Ownership Acquisition If Available service that says, "For each of the specified instance attributes, the joined federate shall receive either a corresponding Attribute Ownership Acquisition Notification † service invocation or a corresponding Attribute Ownership Unavailable † service invocation" needs to be changed to read, "For each of the specified instance attributes, the joined federate may receive only a corresponding Attribute Ownership Acquisition Notification † service invocation or a corresponding Attribute Ownership Unavailable † service invocation."

Change the text of the service description as suggested.

Contrary to what is said in clause 9.1.3.1 (b), modifying a region does not determine the specified dimensions of a region realization. Item (b) should have "or modified" deleted from its end. That is, the specified dimensions of the region shall be the dimensions that are explicitly provided when the Create Region service is invoked to create that region. Invocation of neither the Set Range Bounds service nor the Commit Region Modifications service for a particular region has any effect on what the specified dimensions of that region are.

{Summary of how the issue was proposed to be resolved

According to clause 9.1.1 (c), "A region specification shall be a set of ranges." Whereas according to clause 9.1.3.1 (a), "A region specification may be created using the Create Region service." These two statements are contradictory, because the Create Region service only determines what dimensions will be in a region, not the ranges of those dimensions. The nomenclature should be clarified by clearly defining three distinct terms: region template, region specification, and region realization. A region specification is a set of ranges and, furthermore, the only way that a region specification can be created is by a federate successfully invoking the following services, in order:

1. Invoke the Create Region service (DDM Service 9.2) to create a region template with a specific set of dimensions;
2. Invoke the Set Range Bounds service (Support Service 10.32) for every dimension that was explicitly specified when that region template was created, to set the lower and upper bounds of the range of that dimension for that region template;
3. Invoke Commit Region Modifications (DDM Service 9.3) to inform the RTI about the changes to the ranges of the dimensions specified in the preceding series of Set Range Bounds service invocations, thereby resulting in the creation of a region specification.

A region template is created when a federate invokes the Create Region service. The region designator argument that is returned as a result of the Create Region service is a designator of a region template only. It is not the designator of a region specification, because the range bounds have not yet been set for all of the dimensions of the region template followed by a successful invocation of the Commit Region Modifications service for this region. Only after the Set Range Bounds service has been successfully invoked for every dimension in the region, followed by a successful invocation of the Commit Region Modifications service, is that region designator the designator of a region specification.

When a federate invokes the Register Object Instance With Region, Associate Regions For Updates, Subscribe Object Class Attributes With Regions, Subscribe Interaction Class With Regions, Send Interaction With Regions, or Request Attribute Value Update With Regions service with that region specification designator as an argument, one or more region realizations is created. These region realizations, however, do not have designators.

Clarify the text as suggested.

The introductory text to the Attribute Ownership Acquisition service says, "If a specified instance attribute is owned by another joined federate, the RTI shall invoke the Request Attribute Ownership Release † service for that instance attribute at the owning joined federate." This means that if an owning federate is in the "Waiting for a New Owner to be Found" state and another federate invokes the Attribute Ownership Acquisition service, the owning federate will receive both a Request Attribute Ownership Release † and a Request Divestiture Confirmation † callback. The expectation that the owning federate would receive both of these callbacks, in either order, poses problems. If the RTI were to invoke both the Request Attribute Ownership Release † callback and the Request Divestiture Confirmation † callback at the owning federate, incorrect behavior could result. If the Request Attribute Ownership Release † callback is received first and the federate responds to it, say, by invoking Attribute Ownership Divestiture If Wanted, then it is inappropriate for the owning federate to receive the Request Divestiture Confirmation † callback. Likewise, if the Request Divestiture Confirmation † callback were received first and the owning federate were to respond to it by invoking the Confirm Divestiture service, it would be inappropriate for the owning federate to receive the Request Attribute Ownership Release † callback.

Therefore, to prevent such problems, the following text should be added to this service description, "If the owning federate is in the "Waiting for a New Owner to be Found" state and another federate invokes the Attribute Ownership Acquisition service, the owning federate should receive only a Request Divestiture Confirmation † callback; it should not receive a Request Attribute Ownership Release † callback.

see above

As currently written, it is not clear what should happing if a federate invokes the Attribute Ownership Acquisition service for an instance attribute that is already in the "Acquisition Pending" state. This text should be clarified to indicate that if a federate invokes the Attribute Ownership Acquisition service for an instance attribute that is already in the "Acquisition Pending" state, that instance attribute's state shall remain unchanged. In other words, if a federate invokes the Attribute Ownership Acquisition service for an instance attribute that is in the "Acquiring" state, that instance attribute shall continue to be in the "Acquiring" state and the federate that owns the instance attribute shall not receive a corresponding Request Attribute Ownership Release † callback. If there are additional instance attributes in the attribute set that is an argument to the Attribute Ownership Acquisition service, those instance attributes shall enter the "Acquiring" state, assuming that they meet all of the pre-conditions of the Attribute Ownership Acquisition service and they are not already in the "Acquiring" or the "Trying to Cancel Acquisition" state, and the federate that owns these instance attributes shall receive a corresponding Request Attribute Ownership Release † callback.

Likewise, if a federate invokes the Attribute Ownership Acquisition service for an instance attribute that is in the "Trying to Cancel Acquisition" state, that instance attribute shall continue to be in the "Trying to Cancel Acquisition" state and the federate that owns the instance attribute shall not receive a corresponding Request Attribute Ownership Release † callback. If there are additional instance attributes in the attribute set that is an argument to the Attribute Ownership Acquisition service, those instance attributes shall enter the "Acquiring" state, assuming that they meet all of the pre-conditions of the Attribute Ownership Acquisition service and they are not already in the "Acquiring" or the "Trying to Cancel Acquisition" state, and the federate that owns these instance attributes shall receive a corresponding Request Attribute Ownership Release † callback.

Clarify the text as suggested.

The introductory text in this service description is self-contradicting. Lines 4-12 now read,
The RTI shall advance the joined federate's logical time to the smallest of the following:

• the specified logical time
• the joined federate's GALT value
• the smallest time stamp of all TSO messages delivered by the RTI in response to this invocation of the Flush Queue Request service.
  If the joined federate will not receive any additional TSO messages with time stamps less than the specified logical time, the joined federate shall be advanced to the specified logical time. Otherwise, the RTI shall advance the joined federate's logical time as far as possible (i.e., to the joined federate's GALT).

Lines 9-12 should be deleted, so that the above text now reads simply,
The RTI shall advance the joined federate's logical time to the smallest of the following:

• the specified logical time
• the joined federate's GALT value
• the smallest time stamp of all TSO messages delivered by the RTI in response to this invocation of the Flush Queue Request service.

Delete the suggested portion of the text.

Two of the service names on the transition from the "Idle" to the "Time Advancing" state are not correct. "Next Event Request" should instead be "Next Message Request" and "Next Event Request Available" should be "Next Message Request Available".

Change the service names as described.

Post-condition (b) of this service incorrectly implies that a federate could invoke the Attribute Ownership Acquisition service or the Attribute Ownership Acquisition If Available service on an instance attribute that the federate already owns. The first sentence of (b) should be changed to say, "The joined federate may stop publishing the corresponding class attributes at the known class of the specified object instance if there are no corresponding instance attributes…".

Change post-condition (b) as suggested.

As currently specified, it is not clear what should happen if a federate invokes the Attribute Ownership Acquisition If Available service for an instance attribute that is already in the "Willing to Acquire" state. Text should be added that clarifies that if a federate invokes the Attribute Ownership Acquisition If Available service for an instance attribute that is already in the "Willing to Acquire" state, that instance attribute's state shall remain unchanged. In other words, if a federate invokes the Attribute Ownership Acquisition If Available service for an instance attribute that is in the "Willing to Acquire" state, that instance attribute shall continue to be in the "Willing to Acquire" state. If there are additional instance attributes in the attribute set that is an argument to the Attribute Ownership Acquisition If Available service, those instance attributes shall enter the "Willing to Acquire" state, assuming that they meet all of the pre-conditions of the Attribute Ownership Acquisition If Available service and they are not already in the "Willing To Acquire" state.

Add the suggested clarifying text.

Post-condition (b) of this service, like post-condition (b) of both the Attribute Ownership Acquisition Notification † service and the Attribute Ownership Unavailable † service, should say,

"b) The joined federate may stop publishing the corresponding class attributes at the known class of the specified object instance if there are no corresponding instance attributes for which the joined federate has either:…"

Change post-condition (b) of this service as suggested.

Contrary to what is said in clause 9.1.3.1 (d), the Commit Region Modifications service cannot be used to create a region realization from a region specification. The Commit Region Modifications service can only either:
· create a region specification from a region template, or
· modify the range bounds of an existing region specification and thereby also modify the range bounds of all existing region realizations that are derived from that region specification.

see above