Issues for Distributed Simulation V2.0 Finalization Task Force mailing list

To comment on any of these issues, send email to dss2ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5109: Definition 3.1.66: published (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Minor
Summary:

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."

Resolution: see above
Revised Text: Add the following to 1.4.2: Definition 3.1.66: published Interpretation 1 Part (a) of this definition reads, "pertaining to an object class such that, from the perspective of a given joined federate, there is at least one attribute of the object class that was an argument to a Publish Object Class Attributes service invocation that was not subsequently unpublished via the Unpublish Object Class Attributes service." Part (a) of this definition should instead read (changes 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." Rationale: Because it is possible to invoke the Publish Object Class service with an object class and an empty set of attributes, it should be made clear that an object class is not considered to be "published" unless at least one of the attributes available at that class was published along with the object class. An object class can only be considered to be published if at least one of the attributes available at that class was an argument to the Publish Object Class Attributes service along with the object class. A pre-condition of the Register Object Instance service is that "the joined federate is publishing the object class". Because of the definition of "published" above, this means that the federate must have invoked the Publish Object Class Attributes service for both that object class and for at least one available attribute of that object class. A federate that only invokes the Publish Object Class Attributes service with an object class and an empty set of attributes (without first invoking the Publish Object Class Attributes service with that object class and a non-empty set of attributes and not subsequently invoking the Unpublish Object Class Attributes service for that object class and those attributes) will not be allowed to register instances of that class.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Discussion:

In order to be consistent with the rest of the standard, this definition should be changed
accordingly.

Issue 5110: Figure 3: Lifetime of a Federate: Meaning of Save In Progress (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: The definition of these pre-conditions should be clarified.
Revised Text: Add the following to 1.4.2: Figure 3: Lifetime of a Federate Interpretation 1 Many services in 1516.1 have preconditions and exceptions that are worded simply �Save in progress� or �Save not in progress�. In all cases, the phrase �save in progress� is intended 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5111: Figure 2: Lifetime of a Federate: Meaning of Restore In Progress (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: The definition of these pre-conditions should be clarified.
Revised Text: Add the following to 1.4.2: Figure 3: Lifetime of a Federate Interpretation 2 Many services in 1516.1 have preconditions and exceptions that are worded simply �Restore in progress� or �Restore not in progress�. In all cases, the phrase �restore in progress� is intended to refer to the �Federate Restore in Progress� state as shown in the statechart in Figure 3. A restore is considered to be in progress at a given federate if the federate is in the �Federate Restore in Progress� state.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5112: Service 4.24: Query Federation Restore Status (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: It should be pointed out that the behavior of this service is not testable.
Revised Text: The behavior of the Query Federation Restore Status service and its companion Federation Restore Status Response � service will not be tested. Rationale: 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 one or more federate is in the Federate Restore In Progress state, it is possible that two different federates could have the same federate ID: one federate having its pre-restore ID and the other federate having its post-restore ID. Given that a precondition of the invocation of the Query Federation Restore Status service 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, the pre-restore IDs, the post-restore IDs, or a mixture. 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5113: Figure 10: Class Attribute (i, j) (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Significant
Summary:

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,{})".

Resolution: Modify the label on this history transition so that it is correct.
Revised Text: Add the following to 1.4.3: Figure 10: Class Attribute (i,j) Interpretation 1 The history transition on the right side of this diagram should be labeled "Subscribe(i,{}) or Unsubscribe (i,{})", as opposed to its current labeling of "Publish (i,{}) or Unpublish(i,{})".
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5114: Figure 11: Class Attribute (i, HLAprivilegeToDeleteObject) (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Significant
Summary:

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,{})".

Resolution: Modify the label on this history transition so that it is correct.
Revised Text: Add the following to 1.4.3: Figure 11: Class Attribute (i, HLAprivilegeToDeleteObject) Interpretation 1 The history transition on the right side of this diagram should be labeled "Subscribe(i,{}) or Unsubscribe (i,{})", as opposed to its current labeling of "Publish (i,{}) or Unpublish(i,{})".
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5115: Figure 12: Interaction Class (m) (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Minor
Summary:

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".

Resolution: Modify the statechard labels accordingly.
Revised Text: Add the following to 1.4.3: Figure 12: Interaction Class (m) Interpretation 1 On the left hand side of this statechart, 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".
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5116: Service 5.2: Publish Object Class Attributes (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: Add clarifying text.
Revised Text: Add the following to 1.4.3: Service 5.2 Publish Object Class Attributes Interpretation 1 The introductory text for this service 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. To be more precise, this text should instead read - 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 at the known class of the specified object instance.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5117: Service 5.3: Unpublish Object Class Attributes (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: Delete the phrase �joined federate-owned� from this precondition.
Revised Text: Add the following to 1.4.3: Service 5.3: Unpublish Object Class Attributes Interpretation 1 Pre-condition (e) of this service 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. Pre-condition (e) says: For each class attribute of the specified class that is published by the joined federate and is to be unpublished by this service invocation, there are no joined federate-owned corresponding instance attributes for which the joined federate has either 1) invoked the Attribute Ownership Acquisition service, and has not yet received a corresponding invocation of either the Confirm Attribute Ownership Acquisition Cancellation � service or the Attribute Ownership Acquisition Notification � service, or 2) invoked the Attribute Ownership Acquisition If Available service, and has not yet received a corresponding invocation of either the Attribute Ownership Unavailable � service or the Attribute Ownership Acquisition Notification � service, or 3) invoked the Attribute Ownership Acquisition If Available service and has subsequently invoked the Attribute Ownership Acquisition service [after which condition 1) applies]. The phrase, "joined federate-owned" should be deleted from the first sentence of above text, and replaced by text that refers instead to attributes that are unowned by the joined federate. The above pre-condition should instead read, "For each class attribute of the specified class that is published by the joined federate and is to be unpublished by this service invocation, there are no corresponding instance attributes that are unowned by this joined federate and for which the joined federate has either�"
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5118: Service 5.6: Subscribe Object Class Attributes (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Enhancement
Severity: Significant
Summary:

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.

Resolution: see above
Revised Text: Add the following to 1.4.3: Service 5.6: Subscribe Object Class Attributes Interpretation 1 This service description needs to more completely describe the intended effect of the optional passive subscription indicator. It says, "If a subscription is provided for a class attribute that is already subscribed by the joined federate, then the subscription shall take on the effect of the optional passive subscription indicator from the most recent Subscribe Object Class Attributes service invocation." It does not say what should happen in the event that a subscription is provided 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. The use of the optional passive subscription indicator is expected to work as follows: Each subscribed class attribute is subscribed either actively or passively (but not both actively and passively) at a given object class; and two class attributes that are subscribed at the same object class may be subscribed differently from each other: one active and one passive. Each class attribute specified in a given invocation of the Subscribe Object Class Attributes service will take on the effect of the optional passive/active subscription indicator supplied (or not supplied) with that service invocation. Invoking the Subscribe Object Class Attributes service with an empty set of class attributes shall not change the active/passive subscription nature of any of the attributes that are subscribed at the specified object class. Each use of the Subscribe Object Class Attributes service shall add to the subscriptions specified to the RTI in any previous Subscribe Object Class Attributes service invocation for the same object class and may change the active/passive nature of previous class attribute subscriptions for that object class. Rationale: The expected behavior is for invocations of the Subscribe Object Class Attributes service for any given object class to be cumulative with respect to the set of attributes subscribed at that class, but substitutive with respect to whether each attribute is subscribed actively or passively. If the current invocation of the Subscribe Object Class Attributes service includes a given attribute as an argument, the property of active versus passive for that attribute is substituted according to the value (or absence) of the optional passive subscription indicator argument to the current invocation of the Subscribe Object Class Attributes service.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Discussion:

Add clarifying text to explain the effects of the optional passive subscription
indicator.

Issue 5119: Service 5.10: Start Registration For Object Class (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Enhancement
Severity: Significant
Summary:

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.

Resolution: see above
Revised Text: Add the following to 1.4.3: Service 5.10: Start Registration For Object Class � Interpretation 1 Pre-condition (c) of this service should say, "At least one other joined federate in the federation execution is actively subscribed to at least one of the class attributes that the joined federate is publishing at the specified object class, and the object class at which the subscribing federate is actively subscribed to that attribute is the subscribing federate's candidate discovery class of an object instance registered at the specified object class." Rationale: The purpose of the Start Registration for Object Class � service is to notify a publishing federate that registration of new object instances of the specified object class is advised. In other words, if only DM and not DDM is used in a federation execution, then it is the intention that receipt of the Start Registration For Object Class � service at a federate indicates to that federate that if it were to register an object instance at the specified class, then at least one other federate in the federation execution would discover that object instance and receive reflects for at least one instance attribute of that object instance. The way that pre-condition (c) is currently worded, this intention is not met because it specifies only that at least one other federate must be actively subscribed to at least one published attribute at the specified class or at a superclass of the specified class. This condition is not sufficient to ensure that the subscribing federate would discover the object instance. In fact, the subscribing federate must be subscribed to at least one published attribute at the candidate discovery class of an object instance in order for the subscribing federate to discover the object instance. Consider the following example: Fed1 publishes object class A.B (attribute X). Fed2 subscribes to object class A.B (attribute Y) and to object class A(attribute X). If Fed1 were to register an object instance of class A.B, Fed2 2 would not discover that object instance because Fed2 is not subscribed to attribute X (the only attribute that Fed1 is publishing) at the candidate discovery class of the object instance (class A.B). According to the way that pre-condition (c) is currently worded, however, Fed1 would receive a Start Registration For Object Class � service invocation for object class A.B. According to the way that pre-condition (c) would be worded under this interpretation, Fed1 would not receive a Start Registration For Object Class � service invocation.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
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.

Issue 5120: Service 5.11: Stop Registration For Object Class (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Enhancement
Severity: Significant
Summary:

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.

Resolution: see above
Revised Text: Add the following to 1.4.3: Service 5.11: Stop Registration For Object Class � Interpretation 1 Pre-condition (d) of this service should say, "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." Rationale: The purpose of the Stop Registration for Object Class � service is to notify a publishing federate that registration of new object instances of the specified object class is not advised. In other words, it is the intention that receipt of the Stop Registration For Object Class � service at a federate indicates to that federate that if it were to register an object instance at the specified object class, then there is no other federate in the federation execution that would discover that object instance. Although the wording of pre-condition (d) meets this intention, it is overly restrictive, such that there could be instances in which registration of new object instances is not advised, even though precondition (d) is not met. As long as a subscribing federate is not subscribed to any of the published class attributes at the candidate discovery class, the subscribing federate will not discover a registered object instance, even if the federate is subscribed to one or more of the published class attributes at a super-class of the specified class. Consider the following example: Fed1 publishes object class A.B (attribute X). Fed2 subscribes to object class A.B (attributes X and Y). Fed 1 receives a Start Registration For Object Class � callback for object class A.B. Fed2 subscribes to object class A (attribute X). Fed2 unsubscribes to object class A.B (attribute X) (so Fed2 is still subscribed to object class A.B (attribute Y). If Fed1 were to register an object instance of class A.B, Fed2 would not discover that object instance because Fed2 is not subscribed to attribute X (the only attribute that Fed1 is publishing) at the candidate discovery class of the object instance (class A.B). According to the way that pre-condition (d) is currently worded, however, Fed1 would not receive a Stop Registration For Object Class � service invocation for object class A.B, because Fed2 is subscribed to attribute X at class A. According to the way that precondition (d) would be worded under this interpretation, Fed1 would receive a Stop Registration For Object Class � service invocation, because Fed2 is not subscribed to attribute X at the candidate discovery class of an object instance registered at class A.B.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed isue

Discussion:

Resolution:
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.

Issue 5121: Section 6.1: Object Management Overview (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: see above
Revised Text: Add the following to 1.4.4: OMG Issue Section 6.1: Overview of Object Management Interpretation 1 According to this text, An instance attribute of an object instance shall be in scope for joined federate F if a) The object instance is known to the joined federate, b) The instance attribute is owned by another joined federate, and c) either � The instance attribute�s corresponding class attribute is a subscribed attribute of the known class of the ob-ject instance, or � The instance attribute�s corresponding class attribute is a subscribed attribute of the known class of the object instance with regions, and the update region set of the instance attribute overlaps the subscription region set of the instance attribute�s corresponding class attribute at the known class of the instance attribute at the subscribing joined federate. Item (b) above shall be changed to �The instance attribute is owned either by another joined federate or by the RTI, and�. Rationale: Note that there are three possible states of ownership of any given instance attribute: it may be owned by a federate, owned by the RTI, or not owned. Instance attributes of pre-defined attributes of MOM object instances are owned by the RTI, rather than being owned by another federate. This interpretation is required in order to allow a federate that is subscribed to a pre-defined class attribute of a MOM object class to receive the Attributes In Scope � callback for an instance attribute of a MOM object instance at that class. Without this interpretation, it would not be possible for any federates to receive Attributes In Scope � callbacks for any instance attributes corresponding to pre-defined MOM object class attributes.
Actions taken:
April 9, 2002: received issue
October 23, 2002: close issue

Discussion:

Resolution:
Change item (b) of the in-scope definition to allow MOM instance attributes to come into
scope, MOM object instances to be discovered, and MOM instance attributes to be
reflected.

Issue 5122: Service 6.4: Register Object Instance (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: Add text clarifying the meaning of �the same handle�
Revised Text: Add the following to 1.4.4: Service 6.4: Register Object Instance Interpretation 1 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. 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. Rationale: The handles provided to each federate must be equal, but they do not have to be the same programming language object.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5123: Service 6.5: Discover Object Instance (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: see above
Revised Text: Add the following to 1.4.4: Service 6.5: Discover Object Instance Interpretation 1 Pre-condition (d) of this service states that class attribute �att�s corresponding instance attribute that is part of the specified object instance is owned by another joined federate�. 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�. Rationale: Note that there are three possible states of ownership of any given instance attribute: it may be owned by a federate, owned by the RTI, or not owned. Instance attributes of pre-defined attributes of MOM object instances are owned by the RTI, rather than being owned by another federate. This interpretation is required in order to allow a federate that is subscribed to a pre-defined class attribute of a MOM object class to discover MOM object instances at that class. Without this interpretation, it would not be possible for any federates to discover MOM object instances.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Revise the pre-condition to make it possible for MOM object instances to be
discovered. Also fix similar text in clause 6.1.

Issue 5124: Service 6.8: Send Interaction (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution: Clarify the text as suggested.
Revised Text: Add the following to 1.4.4: Service 6.8: Send Interaction Interpretation 1 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 shall be understood to mean 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5125: Service 6.10: Delete Object Instance (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: Add text that addresses this issue.
Revised Text: Add the following to 1.4.4: Service 6.10: Delete Object Instance Interpretation 1 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5126: Section 7.1: Overview of Ownership Management (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: rejected, see above
Revised Text:
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
There is another comment that related to this same text, and resolution of that comment
involved deleting the above quoted sentences from the standard altogether. That comment
was accepted, so this comment, which suggests that the text in question be augmented is
being rejected. The RTI will only be responsible for attempting to find an owner for
instance attributes that are left unowned as a result of explicit ownership management
service invocations or directives; it shall not be responsible for finding an owner for
instance attributes that are left unowned via registration or unpublication. Furthermore,
the standard should not discuss the RID, as it is implementation-specific.

Issue 5127: Figure 15: New Transition (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Critical
Summary:

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]".

Resolution: Add the suggested transition to the statechart in Figure 15.
Revised Text: Add the following to 1.4.5: Figure 15: Establishing Ownership of Instance Attribute (i, k, j) Interpretation 1 There shall be an additional 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]�. Rationale: This new transition corresponds to interpretation 1 of Service 7.6: Confirm Divestiture.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5128: Figure 15: Modified Transition Label (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Critical
Summary:

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)".

Resolution: Change the label on the transition in Figure 15, as suggested.
Revised Text: Add the following to 1.4.5: Figure 15: Establishing Ownership of Instance Attribute (i, k, j) Interpretation 2 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)�. Rationale: This new transition corresponds to interpretation 1 of Service 7.6: Confirm Divestiture.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5129: Figure 15: New State (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Significant
Summary:

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".

Resolution: Add the suggested history state and the suggested self-transition to figure 15.
Revised Text: Add the following to 1.4.5: Figure 15: Establishing Ownership of Instance Attribute (i, k, j) Interpretation 3 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�. Rationale: This new transition corresponds to interpretation 1 of Service 7.8: Attribute Ownership Acquisition.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5130: Figure 15: New Self-transition (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Significant
Summary:

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']".

Resolution: Add the suggested self-transition to Figure 15.
Revised Text: Add the following to 1.4.5: Figure 15: Establishing Ownership of Instance Attribute (i, k, j) Interpretation 4 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�]�. Rationale: This new transition corresponds to interpretation 1 of Service 7.9: Attribute Ownership Acquisition If Available.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5131: Figure 15: New Guard (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Significant
Summary:

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"].

Resolution: see above
Revised Text:
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
This issue is very similar to issue 5298. In fact, the changes requested in this issue are a
subset of the changes requested in issue 5298. It was decided to accept the more complete
set of changes proposed in issue 5298 and to list issue 5131 as a duplicate. This duplicate
issue 5131 is related to the other duplicate issue 5140, because issue 5131 is an attempt to
make the statechart in Figure 15 consistent with the changes proposed in issue 5140.
Issue 5298, which was accepted instead of issues 5131 and 5140 involves both making a
superset of the changes requested in 5140 and making the statechart in Figure 15
consistent with these changes.

Issue 5133: Section 7.1.4: User-supplied Tags (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: Clarify the text as suggested.
Revised Text: Add the following to 1.4.5: Section 7.1.4: User-supplied tags Interpretation 1If 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 usersupplied tag shall be present in the service invocation, but empty. For example, in the Java API, the tag should be an empty (zero-length) array. Rationale: 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. For example, according to clause 7.1.4, the user-supplied tag present in the Negotiated Attribute Ownership Divestiture service shall be present in any resulting Request Attribute Ownership Assumption � service invocations. However, the RTI may invoke the Request Attribute Ownership Assumption � service at a federate in an attempt to find an owner for an unowned instance attribute. In this case, the Request Attribute Ownership Assumption � service invocation is not the result of a Negotiated Attribute Ownership Divestiture service invocation by another federate. In this case, it is not clear what the content of the user-supplied tag in the Request Attribute Ownership Assumption � service should be. The user-supplied tag, however, is a mandatory argument of the Request Attribute Ownership Assumption � service. Therefore, if the Request Attribute Ownership Assumption � service is not the result of a previous corresponding Negotiated Attribute Ownership Divestiture service invocation, the user-supplied tag shall be present in the Request Attribute Ownership Assumption � service, but it shall be empty. Other examples in which this interpretation is relevant are: � Attribute Ownership Acquisition Notification �: If an Attribute Ownership Acquisition Notification � service invocation is received at a federate as a result of an owning federate invoking the Unconditional Attribute Ownership Divestiture service, the Attribute Ownership Divestiture If Wanted service, or the Unpublish Object Class Attributes service, or as a result of the owning federate resigning, the user-supplied tag that shall be present in the Attribute Ownership Acquisition Notification � service shall be empty. � Provide Attribute Value Update �: If a Provide Attribute Value Update � service invocation is received at a federate as a result of the Auto-Provide Switch being enabled, the content of the user-supplied tag that shall be present in the Provide Attribute Value Update � service shall be empty. � Request Attribute Ownership Assumption �: If a Request Attribute Ownership Assumption � service invocation is received at a federate as a result of the owning federate invoking the Unconditional Attribute Ownership Divestiture service, the Unpublish Object Class Attributes service, or as a result of the owning federate resigning, the user-supplied tag that shall be present in the Request Attribute Ownership Assumption � service invocation shall be empty.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5134: Service 7.3: Negotiated Attribute Ownership Divestiture: finding owners (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.5: Service 7.3: Negotiated Attribute Ownership Divestiture Interpretation 1 The following text should be added to the introductory paragraphs for 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, but is not required 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 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. Rationale: This makes clear the mechanism that the RTI is expected to use to try to find federates that are willing to accept ownership of the instance attributes that the owning federate is trying to divest. For each instance attribute that is trying to be divested, if there are no federates that are trying to acquire that instance attribute, then the RTI must use the Request Attribute Ownership Assumption � service as the mechanism for offering ownership of that instance attribute to federates that are eligible to own it. If there is one or more federate that is already trying to acquire that instance attribute, then the RTI may simply invoke the Request Divestiture Confirmation � service at the divesting federate to inform it that a federate that is willing to accept ownership of the instance attribute has been located. It is also acceptable in this situation for the RTI to use the Request Attribute Ownership Assumption � service to offer ownership of that instance attribute to other eligible federates (ones that are not already trying to acquire it) before invoking the Request Divestiture Confirmation � service at the divesting federate to inform it that a federate that is willing to accept ownership of the instance attribute has been located.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5135: Service 7.3: Negotiated Attribute Ownership Divestiture: divesting (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: Change the text as suggested.
Revised Text: Add the following to 1.4.5: Add the following to 1.4.5: Service 7.3: Negotiated Attribute Ownership Divestiture Interpretation 2 The sentence in the Negotiated Attribute Ownership Divestiture service description that 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." should be changed to read simply: "The invoking joined federate shall continue its update responsibility for the specified instance attributes until it divests ownership." Rationale: The invoking joined federate needs to continue its update responsbility for all instance attributes that it owns for as long as it owns them and until it divests them. The manner in which it divests them is irrelevant. By including the words �via the Confirm Divestiture service� at the end of the above sentence, the text as it currently appears in the standard implies that if the federate were to divest ownership by some other means, such as unpublishing, invoking the Unconditional Attribute Ownership Divestiture service, or invoking the Attribute Ownership Divestiture If Wanted service, then the federate would still continue its update responsibility for the instance attributes, even though the federate would no longer be the owner of the instance attributes. This implication is incorrect and contradicts other portions of the specification which prevent a federate from updating an instance attribute if it is not the owner of that instance attribute. Removing the phrase �via the Confirm Divestiture Service� eliminates the incorrect implication.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5136: Service 7.4: Request Attribute Ownership Assumption (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: Add the suggested pre-condition.
Revised Text: Add the following to 1.4.5: Service 7.4: Request Attribute Ownership Assumption � Interpretation 1 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." Rationale: This additional pre-condition is already a requirement as expressed by the guard on the Request Attribute Ownership Assumption transition in the statechart in Figiure 15.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5137: Service 7.6: Confirm Divestiture (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: see above
Revised Text: Add the following to 1.4.5: Service 7.6: Confirm Divestiture Interpretation 1 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. Rationale: 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Add the suggested pre-condition, exception, and introductory text to this service
description.

Issue 5138: Service 7.7: Attribute Ownership Acquisition Notification (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Significant
Summary:

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�".

Resolution: Change post-condition (b) as suggested.
Revised Text: Add the following to 1.4.5: Service 7.7: Attribute Ownership Acquisition Notification � Interpretation 1 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. Post-condition (b) says: b) The joined federate may stop publishing the corresponding class attributes at the known class of the specified object instance if it does not own any corresponding instance attributes for which the joined federate has either: 1. invoked the Attribute Ownership Acquisition service, and has not yet received a corresponding invocation of either the Confirm Attribute Ownership Acquisition Cancellation � service or the Attribute Ownership Acquisition Notification � service, or 2. invoked the Attribute Ownership Acquisition If Available service, and has not yet received a corresponding invocation of either the Attribute Ownership Unavailable � service or the Attribute Ownership Acquisition Notification � service, or 3. invoked the Attribute Ownership Acquisition If Available service and has subsequently invoked the Attribute Ownership Acquisition service [after which condition 1) applies]..... The first sentence of above text should read (changes shown in boldface), "The joined federate may stop publishing the corresponding class attributes at the known class
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5139: Service 7.8: Attribute Ownership Acquisition invoked twice (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: Clarify the text as suggested.
Revised Text: Add the following to 1.4.5: Service 7.8: Attribute Ownership Acquisition Interpretation 1 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, if appropriate (see the next interpretation for when it is appropriate). 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 preconditions 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, if appropriate.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5140: Service 7.8: Attribute Ownership Acquisition prohibited (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Enhancement
Severity: Critical
Summary:

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.

Resolution: see above
Revised Text:
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
This issue is very similar to issue 5298. In fact, the changes requested in this
issue are a subset of the changes requested in issue 5298. It was decided to
accept the more complete set of changes proposed in issue 5298 and to list
issue 5140 as a duplicate.

Issue 5141: Service 7.9: Attribute Ownership Acquisition If Available: self-transition (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.5: Service 7.9: Attribute Ownership Acquisition If Available Interpretation 1 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5142: Service 7.9: Attribute Ownership Acquisition If Available: response not gua (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Critical
Summary:

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."

Resolution: Change the text of the service description as suggested.
Revised Text: Add the following to 1.4.5: Service 7.9: Attribute Ownership Acquisition If Available Interpretation 2 The introductory text to the Attribute Ownership Acquisition If Available service 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." This text should 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." Rationale: Although it was the case that in the 1.3 (Non-IEEE) version of the HLA Interface Specification the Attribute Ownership Acquisition If Available service was always guaranteed to result in either a corresponding Attribute Ownership Acquisition Notification � callback or a corresponding Attribute Ownership Unavailable � callback, this is no longer the case in the IEEE HLA 1516.1-2000 standard. Because 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, 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5143: Service 7.10: Attribute Ownership Unavailable (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Significant
Summary:

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:�"

Resolution: Change the text of post-condition (b) of this service as suggested.
Revised Text: Add the following to 1.4.5: Service 7.10: Attribute Ownership Unavailable � Interpretation 1 Post-condition (b) of this service, like post-condition (b) of the Attribute Ownership Acquisition Notification � service (as amended by these Interpretations), 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: 1. invoked the Attribute Ownership Acquisition service, and has not yet received a corresponding invocation of either the Confirm Attribute Ownership Acquisition Cancellation � service or the Attribute Ownership Acquisition Notification � service, or 2. invoked the Attribute Ownership Acquisition If Available service, and has not yet received a corresponding invocation of either the Attribute Ownership Unavailable � service or the Attribute Ownership Acquisition Notification � service, or 3. invoked the Attribute Ownership Acquisition If Available service and has subsequently invoked the Attribute Ownership Acquisition service [after which condition 1) applies]. Rationale: 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. Stipulations 1, 2, and 3 above ensure that there are no other such instance attributes that the federate is "Willing to Acquire" or for which the federate has an "Acquisition Pending".
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5144: Service 7.15: Confirm Attribute Ownership Acquisition Cancellation (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Revision
Severity: Significant
Summary:

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:�"

Resolution: Change post-condition (b) of this service as suggested.
Revised Text: Add the following to 1.4.5: Service 7.15: Confirm Attribute Ownership Acquisition Cancellation � Interpretation 1 Post-condition (b) of this service, like post-condition (b) of both the Attribute Ownership Acquisition Notification � service and the Attribute Ownership Unavailable � service (both as amended by these Interpretations), 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: 1. invoked the Attribute Ownership Acquisition service, and has not yet received a corresponding invocation of either the Confirm Attribute Ownership Acquisition Cancellation � service or the Attribute Ownership Acquisition Notification � service, or 2. invoked the Attribute Ownership Acquisition If Available service, and has not yet received a corresponding invocation of either the Attribute Ownership Unavailable � service or the Attribute Ownership Acquisition Notification � service, or 3. invoked the Attribute Ownership Acquisition If Available service and has subsequently invoked the Attribute Ownership Acquisition service [after which condition 1) applies]. Rationale: The rationale for this interpretation is the same as for service 7.10 above.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5145: Figure 16: Temporal State statechart (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan@mitre.org)
Nature: Clarification
Sever