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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)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(at)mitre.org)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: Change the service names as described.
Revised Text: Add the following to 1.4.6: Figure 16: Temporal State statechart 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".
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5146: Service 8.12: Flush Queue Request (dss2ftf)

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

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.

Resolution: Delete the suggested portion of the text.
Revised Text: Add the following to 1.4.6: Service 8.12 Flush Queue Request Interpretation 1 Lines 4-8 and lines 9-11 of the introductory text to this service conflict with each other: Lines 4-8 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. Lines 9-11 now read: 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-11 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5147: DDM Overview: nomenclature (dss2ftf)

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

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.

Resolution: Clarify the text as suggested.
Revised Text: Add the following to 1.4.7: Section 9.1: DDM Overview Interpretation 1 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. A region specification is a set of ranges. The only way that a region specification can be created is by a federate successfully invoking the following services, in order: 4. Invoke the Create Region service (DDM Service 9.2) to create a region with a specific set of dimensions; 5. Invoke the Set Range Bounds service (Support Service 10.32) for every dimension that was explicitly specified when that region was created, to set the lower and upper bounds of the range of that dimension for that region; 6. 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. 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5148: DDM Overview: determining specified dimensions (dss2ftf)

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

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.

Resolution: {Summary of how the issue was proposed to be resolved
Revised Text: Add the following to 1.4.7: Section 9.1: DDM Overview Interpretation 2 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5149: DDM Overview: Commit Region Modifications (dss2ftf)

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

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.

Resolution: see above
Revised Text: Add the following to 1.4.7: Section 9.1: DDM Overview Interpretation 3 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Delete �, or Commit Region Modifications� from 9.1.3.1 (d) and add clarifying text
regarding what the Commit Region Modifications service is used for.

Issue 5150: DDM Overview: Steps to Create a Region Specification (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.7: Section 9.1: DDM Overview Interpretation 4 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. Rationale: 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. In summary, although the creation of a region specification is accomplished using a sequence of service calls, all of these service calls must be invoked successfully, in sequence, in order to successfully create a region specification .
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5151: Section 9.1.2: Default Ranges (dss2ftf)

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

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.

Resolution: Clarify the text as suggested
Revised Text: Add the following to 1.4.7: Section 9.1.2: Default Ranges Interpretation 1 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.
Actions taken:
April 9, 2002: receieved issue
October 23, 2002: closed issue

Issue 5152: "Invalid Region" exceptions (dss2ftf)

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

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.

Resolution: Add clarifying text.
Revised Text: Add the following to 1.4.7: DDM: "Invalid Region" exceptions Interpretation 1 Some DDM services require that the region designator used as an argument be the designator of a region specification, whereas other DDM services 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. For all services that can be used to create a region realization from a region specification, the region designator argument shall be the designator of a region specification. Specifically, the following services, which result in the creation of region realizations from region specifications, require that the region designator argument be the designator of a 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 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 region designator argument for the Delete Region service shall be the designator of either a region template or a region specification. There are also three Support Services that take a region designator as argument: � The region designator argument for the Get Range Bounds service shall be the designator of either a region specification or a region realization. � The region designator argument for the Get Dimension Handle Set service shall be the designator of a region template, a region specification, or a region realization. � The region designator argument for the Set Range Bounds service shall be the designator of either a region template or a region specification.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5153: Section 9.1.7: Convey Region Designator Sets Switch: when conveyed (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.7: Section 9.1.7: Convey Region Designator Sets Switch Interpretation 1 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 words �as appropriate� should be understood to mean that 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. Rationale: In Clause 6.7 of IEEE 1516.1-2000, it is made clear that if the specified instance attributes have available dimensions and the Convey Region Designator Sets Switch is enabled, the set of sent region designators argument of the Reflect Attribute Values � service shall contain the update region set, if any, that was used for update of the instance attributes at the joined federate which invoked the corresponding Update Attribute Values service. In clause 6.9 it is made clear that if the specified interaction has available dimensions and the Convey Region Designator Sets Switch is enabled, the set of sent region designators argument of the Receive Interaction � service shall contain the update region set, if any, that was supplied to the corresponding Send Interaction With Regions service invocation by the sending joined federate. The Convey Region Designator Sets Switch is a federation-wide switch, and therefore affects all federates in the federation, regardless of whether or not they are using DDM.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5154: Section 9.1.7: Convey Region Designator Sets Switch: copies conveyed (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.7: Section 9.1.7: Convey Region Designator Sets Switch Interpretation 2 According to clause 6.1.4, when the Convey Region Designator Sets Switch is enabled and a Reflect Attribute Values � callback is received, all of the instance attribute/value pairs in that Reflect Attribute Values � service invocation must have the same set of sent region designators. The set of sent region designators conveyed is not a set of designators of region specifications or a set of designators of region realizations. It is, 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. Consider the following example: Assume the following FDD information: Dimension d1 [0, 1000) default range [1, 100) Dimension d2 [0, 1000) default range [1, 100) Dimension d3 [0, 1000) default range [1, 100) Dimension d4 [0, 1000) default range [1, 100) Object Class C Attribute X dimensions d1, d3 Attribute Y dimensions d1, d4 Attribute Z dimensions d2 Now assume the following service invocations: Create Region ({d1}) return (designator R) Create Region ({d2}) return (designator G) At this point, R and G are the designators of region templates only. Set Range Bounds(R, d1, 2, 45) Commit Region Modifications (R) Set Range Bounds (G, d2, 5, 15) Commit Region Modifications (G) At this point, R and G are the designators of region specifications. Register Object Instance(object class C, �object1�) Associate Regions For Updates (object1, ({X, Y}, {R})) After the above Associate Regions For Updates (object1, ({X, Y}, {R})) service invocation, R is still the designator of a region specification; however, as a result of the Associate Regions For Updates (object1, ({X, Y}, {R})) service invocation, two region realizations were created: one associated with X, and one associated with Y. The federate that created the region specification R, however, has no designator that refers to either of these region realizations uniquely. The region realization that is associated with X has specified dimension d1 and unspecified dimension d3. The region realization that is associated with Y has specified dimension d1 and unspecified dimension d4. Associate Regions For Updates (object1, ({Z}, {G})) Use a MOM interaction to enable the Convey Region Designator Sets Switch. Update Attribute Values (object1, {(X, 44), (Y, 53), (Z, 66)}, �user tag�) At this point, all federates that are subscribed to X, Y and Z at the appropriate object class will receive three separate reflects: one that includes only an attribute/value pair for X, one that includes only an attribute/value pair for Y, and another that includes only an attribute/value pair for Z. Note that although the region realization associated with X and the region realization associated with Y are derived from the same region specification (region specification R), the region realization associated with X differs from the region realization associated with Y because the range values of the unspecified dimensions of each of the region realizations differ. This passelization of a single update into three different reflects is required by the fact that different region realizations were associated with X,Y, and Z. The reflect for X will contain a Set of Sent Region Designators consisting of one designator, R1, which has range values for dimensions d1 (2, 45) and d3 (1,100); the reflect for Y will contain a Set of Sent Region Designators consisting of one designator, R11, which has range values for dimensions d1 (2, 45) and d4 (1,100); and the reflect for Z will contain a Set of Sent Region Designators consisting of one designator, G1, which has range values for only dimension d2 (5, 15). If the reflecting federate were to invoke Get Dimension Handle Set (R1) while the Reflect Attribute Values service were still in progress and before it is allowed to complete, it would get back a response of {d1, d3}, because R1 is a copy of a region realization consisting of specified dimension d1 and unspecified dimension d3. If the reflecting federate were to invoke Get Range Bounds (R1, d1) it would get return values of: lower bound 2; upper bound 45. If the reflecting federate were to invoke Get Range Bounds (R1, d3) it would get return values of: lower bound 1; upper bound 100. However, once the Reflect Attribute Values service invocation completes at the reflecting federate, the reflecting federate is no longer guaranteed that the values returned by Get Range Bounds (R1, d1) will still be 2 and 45. For the second part of this example, suppose that the updating federate were to invoke the following: Update Attribute Values (object1, {(X, 100)}, �user tag�). The reflecting federate would receive a reflect with an attribute/value pair for (X, 100) in it, and a conveyed region set consisting of one designator, R2. R2 may or may not be equal to R1. That is an implementation detail. If the reflecting federate were to invoke Get Range Bounds (R2, d1) before the Reflect Attribute Values service invocation were allowed to complete, it would get return values of: lower bound 2; upper bound 45. Suppose the updating federate were to invoke Set Range Bounds(R, d1, 10, 20), followed by Commit Region Modifications (R) while the previous Reflect Attribute Values service invocation is still in progress at the reflecting federate. If the reflecting federate were to invoke Get Range Bounds (R2, d1) it would still get return values of: lower bound 2; upper bound 45, because the Reflect Attribute Values service invocation that contains the region realization copy with these range values has not yet completed. Suppose the updating federate were to invoke Update Attribute Values (object1, {(X, 200)}, �user tag�) after the previous Reflect Attribute Values service invocation had completed. The reflecting federate would receive a reflect with an attribute/value pair for (X, 200) in it, and a conveyed region set consisting of one designator, R3. (R3 may or may not be equal to R1 or R2; that is an implementation detail.)
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5155: Section 9.1.7: Convey Region Designator Sets Switch: use in support (dss2ftf)

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

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.

Resolution: Change the text as suggested.
Revised Text: Add the following to 1.4.7: Section 9.1.7: Convey Region Designator Sets Switch Interpretation 3 Section 9.1.7, last sentence: 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5156: Service 9.3: Commit Region Modifications (dss2ftf)

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

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.

Resolution: Add the suggested text.
Revised Text: Add the following to 1.4.7: Service 9.3 Commit Region Modifications Interpretation 1 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. Rationale: The purpose of the Commit Region Modifications service is to either create a region specification from a region template or 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5157: Service 9.4: Delete Region (dss2ftf)

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

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

Resolution: Change the second sentence of the service description as suggested.
Revised Text: Add the following to 1.4.7: Service 9.4: Delete Region Interpretation 1 The second sentence of this service description should say, �A region in use for subscription or update shall not be deleted.� If a federate invokes the Delete Region service using as an argument the designator of a region that is in use for subscription or update, the Delete Region service shall not complete successfully and the �Region is in use for update or subscription� exception shall be thrown at that federate. Rationale: 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 interpretation that deletions of regions that are in use shall not be allowed.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5158: Register Object Instance With Regions: unique names (dss2ftf)

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

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.

Resolution: see above
Revised Text: Add the following to 1.4.7: Service 9.5: Register Object Instance With Regions Interpretation 1 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). With regard to the behavior described in this paragraph, the Register Object Instance With Regions service shall 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. Rationale: 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Add text stipulating that whether an object instance is registered with or without
regions, the naming of that object instance should work the same.

Issue 5159: Register Object Instance With Regions: invalid region (dss2ftf)

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

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.

Resolution: Add the suggested pre-condition.
Revised Text: Add the following to 1.4.7: Service 9.5: Register Object Instance With Regions Interpretation 2 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. Rationale: 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5160: Service 9.6: Associate Regions For Updates (dss2ftf)

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

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.

Resolution: Change the service description as suggested.
Revised Text: Add the following to 1.4.7: Service 9.6: Associate Regions For Updates Interpretation 1 This service description says that, "This service shall add the specified regions to the set of associations of each specified instance attribute." 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. Rationale: See 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5161: Service 9.6: Associate Regions For Updates: invalid region (dss2ftf)

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

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.

Resolution: Add the suggested pre-condition.
Revised Text: Add the following to 1.4.7: Service 9.6: Associate Regions For Updates Interpretation 2 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. Rationale: 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.
Actions taken:
April 9, 2002: received issue
October 23, 2002: closed issue

Issue 5162: Service 9.7: Unassociate Regions For Updates: irrelevant attributes (dss2ftf)

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

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

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.7: Service 9.7: Unassociate Regions For Updates Interpretation 1 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.� 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5163: Service 9.7: Unassociate Regions For Updates: invalid region (dss2ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution: Add the suggested new pre-condition.
Revised Text: Add the following to 1.4.7: Service 9.7: Unassociate Regions For Updates Interpretation 2 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. Rationale: 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5164: Service 9.8: Subscribe Object Class Attributes With Regions: passive indica (dss2ftf)

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

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.

Resolution: Add text that explains the effects of the optional passive subscription indicator.
Revised Text: Add the following to 1.4.7: Service 9.8: Subscribe Object Class Attributes With Regions Interpretation 1 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. The use of the optional passive subscription indicator is expected to work on the triple basis, which is as follows: Each subscribed attribute of a class with region is subscribed either actively or passively (but not both actively and passively) at that given object class and with that particular region. Two different class attributes that are subscribed with regions at the same object class and with the same region may be subscribed differently from each other: one active and one passive, and a class attribute that is subscribed with regions at a given object class but with more than one region may be subscribed differently (either actively or passively) with each region. That is, the active/passive characteristic is a property of a subscription to a class attribute at a given object class with a given region. Each (object class, class attribute, region) triple specified in a given invocation of the Subscribe Object Class Attributes With Regions service will take on the effect of the optional passive/active subscription indicator supplied (or not supplied) with that service invocation. Furthermore, if there is an existing (object class, class attribute, region) subscription that has the same object class, class attribute, and region value as those specified in the current invocation of the Subscribe Object Class Attributes With Regions service, this existing subscription will take on the effect of the optional active/passive subscription indicator supplied (or not supplied) with the current service invocation. Invoking the Subscribe Object Class Attributes With Regions service with an (object class, class attribute, region set) triple such that the region set is empty shall not change the active/passive subscription nature of any of the (object class, class attribute, region) triples that are already subscribed. Each use of the Subscribe Object Class Attributes With Regions service shall add the specified regions to the set of subscriptions of the specified class attributes at that object class, if they are not already in this set; and may change the active/passive nature of existing subscriptions if they are. Rationale: The intent is for invocations of the Subscribe Object Class Attributes With Regions service for any given object class, class attribute, and region to be cumulative with respect to the set of subscribed regions of a given class attribute, but substitutive with respect to whether each (object class, class attribute, region) subscription is subscribed actively or passively. If the current invocation of the Subscribe Object Class Attributes With Regions service includes an (object class, class attribute, region) subscription that already exists, the property of active versus passive for that (object class, class attribute, region) subscription will be substituted according to the value (or absence) of the optional passive subscription indicator argument to the current invocation of the Subscribe Object Class Attributes With Regions service.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5165: Service 9.8: Subscribe Object Class Attributes With Regions: invalid region (dss2ftf)

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

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.

Resolution: Add the suggested new pre-condition
Revised Text: Add the following to 1.4.7: Service 9.8: Subscribe Object Class Attributes With Regions Interpretation 2 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. Rationale: 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5166: Service 9.9: Unsubscribe Object Class Attributes With Regions: discover (dss2ftf)

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

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.

Resolution: Revise this sentence as suggested.
Revised Text: Add the following to 1.4.7: Service 9.9: Unsubscribe Object Class Attributes With Regions Interpretation 1 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 sentence should be understood to mean, 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. Rationale: The purpose of the Unsubscribe Object Class Attributes With Regions service is to remove subscriptions with regions such that � Those subscriptions will no longer be part of the calculation regarding whether or not the subscription region set for the class attribute at the candidate discovery class at the subscribing joined federate overlaps the update region set of the instance attribute at the owning federate (for purposes of determining whether the subscribing federate should discover the object instance), and � Those subscriptions will no longer be part of the calculation regarding whether or not the subscription region set for the class attribute at the known class of the object instance at the subscribing joined federate overlaps the update region set of the instance attribute at the owning federate at the time of update (for purposes of determining whether the subscribing federate should receive a Reflect Attribute Values � callback when the instance attribute is updated). Here is an example: Suppose that federate 1 has a given object class and class attribute subscribed with two different regions, R1 and R2. Suppose that federate 2 owns a corresponding instance attribute of an object instance that it has registered at the given class and that federate 2 has associated region R3 with that instance attribute for updates. Suppose also that region R3 overlaps region R1 and region R3 also overlaps region R2. If federate 1 invokes the Unsubscribe Object Class Attributes With Regions service for that object class, class attribute, and region R1, then federate 1 would still expect to reflect attribute updates for the instance attribute, because it is still subscribed to the corresponding class attribute with region R2. If federate 1 also invokes the Unsubscribe Object Class Attributes With Regions service for that object class, class attribute, and region R2, then federate 1 would not expect to reflect attribute value updates for the instance attribute.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5167: Service 9.9: Unsubscribe Object Class Attributes With Regions: invalid regi (dss2ftf)

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

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.

Resolution: Add the suggested new pre-condition.
Revised Text: Add the following to 1.4.7: Service 9.9: Unsubscribe Object Class Attributes With Regions Interpretation 2 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. Rationale: 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5168: Service 9.10: Subscribe Interaction Class With Regions: passive indicator (dss2ftf)

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

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.

Resolution: Add text explaining the use of the optional passive subscription indicator.
Revised Text: Add the following to 1.4.7: Service 9.10: Subscribe Interaction Class With Regions Interpretation 1 The use of the optional passive subscription indicator is expected to work as follows: Each subscribed interaction class with regions is subscribed either actively or passively with a given region, but not both. Two different interaction classes that are subscribed at the same region may be subscribed differently from each other: one active and one passive, and the same interaction class that is subscribed with two different regions may be subscribed differently (either actively or passively) with each region. Each (interaction class, region) pair specified in a given invocation of the Subscribe Interaction Class With Regions service will take on the effect of the optional active/passive subscription indicator supplied (or not supplied) with that service invocation. Furthermore, if there is an existing (interaction class, region) subscription that has the same interaction class and region values as those specified in the current invocation of the Subscribe Interaction Class With Regions service, it will take on the effect of the optional passive/active subscription indicator supplied (or not supplied) with the service invocation. Invoking the Subscribe Interaction Class With Regions service with an (interaction class, region set) pair such that the region set is empty shall not change the active/passive subscription nature of any of the (interaction class, region) pairs that are already subscribed. Each use of the Subscribe Interaction Class With Regions service shall add the specified regions to the set of subscriptions of the specified interaction class, if they are not already in this set; and may change the active/passive nature of existing subscriptions if they are. Rationale: 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5169: Service 9.10: Subscribe Interaction Class With Regions: invalid region (dss2ftf)

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

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.

Resolution: Add the suggested new pre-condition.
Revised Text: Add the following to 1.4.7: Service 9.10: Subscribe Interaction Class With Regions Interpretation 2 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. Rationale: 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.
Actions taken:
April 10, 2002: rceived issue
October 23, 2002: closed issue

Issue 5170: Service 9.11:Unsubscribe Interaction Class With Regions: interaction receip (dss2ftf)

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

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.

Resolution: Revise the text as suggested.
Revised Text: Add the following to 1.4.7: Service 9.11: Unsubscribe Interaction Class With Regions Interpretation 1 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 sentence should be understood to mean, 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. Rationale: The purpose of the Unsubscribe Interaction Class With Regions service is to remove subscriptions with regions for a given interaction class such that those subscriptions with regions will no longer be part of the calculation regarding whether or not the update region set of a sent interaction overlaps the subscription region set for that interaction class. Here is an example: Suppose that federate 1 has a given interaction class subscribed with two different regions, R1 and R2. Suppose that federate 2 sends an interaction of the given class with region R3. Suppose also that region R3 overlaps region R1 and region R3 also overlaps region R2. If federate1 invokes the Unsubscribe Interaction Class With Regions service for that object class and region R1, federate 1 would still expect to receive an interaction of that class that is sent with region R3 because federate 1 is still subscribed to the interaction class with region R2. If federate 1 also invokes the Unsubscribe Interaction Class With Regions service for that object class and region R2, however, federate 1 would not expect to receive an interaction of that class that is sent with region R3.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5171: Service 9.11: Unsubscribe Interaction Class With Regions: error (dss2ftf)

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

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

Resolution: Delete the �not� from the sentence, as suggested.
Revised Text: Add the following to 1.4.7: Service 9.11: Unsubscribe Interaction Class With Regions Interpretation 2 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."
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5172: Service 9.11: Unsubscribe Interaction Class With Regions: invalid region (dss2ftf)

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

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

Resolution: Add the suggested new pre-condition.
Revised Text: Add the following to 1.4.7: Service 9.11: Unsubscribe Interaction Class With Regions Interpretation 3 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. Rationale: 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5173: Service 9.12: Send Interaction With Regions: which parameters are sent (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan(at)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 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.

Resolution: Clarify the text as suggested.
Revised Text: Add the following to 1.4.7: Service 9.12: Send Interaction With Regions Interpretation 1 Clarification: 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." 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 10, 2002: received issue
October 23, 2002: closed issue

Issue 5174: Service 9.12: Send Interaction With Regions: invalid region (dss2ftf)

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

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.

Resolution: Add the suggested new pre-condition.
Revised Text: Add the following to 1.4.7: Service 9.12: Send Interaction With Regions Interpretation 2 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. Rationale: 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5175: Service 9.13: Request Attribute Value Update With Regions (dss2ftf)

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

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.

Resolution: Add the new pre-condition as suggested.
Revised Text: Add the following to 1.4.7: Service 9.13: Request Attribute Value Update With Regions Interpretation 1 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. Rationale: 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5176: DDM Typos: declaration (dss2ftf)

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

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

Resolution: Replace �DM� by �Object Management�, as suggested.
Revised Text: Add the following to 1.4.7: DDM Typos: Interpretation 1 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)�"
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5177: DDM Typos: handle (dss2ftf)

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

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

Resolution: Change the returned argument from �designator� to �handle�.
Revised Text: Add the following to 1.4.7: DDM Typos: Interpretation 2 Service 9.5: Register Object Instance With Regions: The returned argument should be an object instance "handle" (not an object instance "designator").
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5178: Section 10.1.2: Advisory Switches (dss2ftf)

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

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)

Resolution: Add text explaining the initial state of each advisory, as suggested.
Revised Text: Add the following to 1.4.8: Section 10.1.2: Advisory Switches Interpretation 1 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." For purposes of determining whether the conditions covered by each advisory have changed, 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) Rationale: The following two examples demonstrate the use of item 1: Fed1 enables the Object Class Relevance Advisory switch or it is already enabled as a result of settings in the FDD. Fed2 subscribes to object class A.B, attribute Y, denoted A(Y). Fed1 publishes A.B(X). According to item 1 above, before federate 1 began publishing A.B(X), it was in a state such that registration of new object instances of object class A.B was not advised. Upon publishing A.B(X), it remains in a state such that registration of new object instances of object class A.B is not advised. Therefore, fed1 shall not receive a Stop Registration For Object Class advisory because the conditions covering that advisory have not changed at federate 1. Alternatively, Fed1 enables the Object Class Relevance Advisory switch or it is already enabled as a result of settings in the FDD. Fed2 subscribes to A(X). Fed1 publishes A(X). According to item 1 above, before federate 1 began publishing A(X), it was in a state such that registration of new object instances of object class A was not advised. Then, upon publishing A(X), it becomes in a state such that registration of new object instances of object class A is advised. Because the conditions covering the advisory have changed, fed1 receives a Start Registration For Object Class � service invocation for object class A. The following two examples demonstrate the use of item 2: Fed1 enables the Interaction Relevance Advisory switch or it is already enabled as a result of settings in the FDD. Fed2 subscribes to interaction class A.B. Fed1 publishes interaction class A.C. According to item 2 above, before federate 1 began publishing interaction class A.C, it was in a state such that interactions of class A.C were not relevant to any other federate in the federation execution. Then, upon publishing interaction class A.C, it remained in a state such that interactions of class A.C are not relevant to other federates in the federation execution. Therefore, because the conditions covering that advisory have not changed at fed1, fed1 shall not receive a Turn Interactions Off � service invocation for interaction class A.C. Alternatively, Fed1 enables the Interaction Relevance Advisory switch or it is already enabled as a result of settings in the FDD. Fed2 subscribes to interaction class A. Fed1 publishes interaction class A. According to item 2 above, before federate 1 began publishing interaction class A, it was in a state such that interactions of class A were not relevant to other federates in the federation execution. Then, upon publishing interaction class A, it becomes in a state such that interactions of class A are relevant to other federates in the federation execution. Because the conditions covering the advisory have changed, fed1 receives a Turn Interactions On � service invocation for interaction class A. The following is an example of the use of item 3 (ignoring scope for now): Suppose fed1 and fed2 are both publishing and subscribing to A(x), but not A(y). The Attribute Relevance advisory switch is enabled at both federates. Fed1 registers an instance of class A, A1, which fed2 is expected to discover. As a result of registering A1, fed1 owns instance attribute x of A1. (call it A1(x)), but A1(y) is unowned. According to item 3 above, before fed1 became the owner of A1(x) fed1 was in the Updates Turned Off state with regard to both A1(x) and A1(y). Upon becoming the owner of A1(x), fed1 enters the Updates Turned On state with regard to A1(x), and remains in the Updates Turned Off state with regard to A1(y). Because the conditions covering the advisory have changed for A1(x) but not A1(y), fed1 should get a Turn Updates On for A1(x), but it should not get any advisories for A1(y). The following is also an implication of item 3: Continuing with the previous example, fed1 transfers ownership of A1(x) to fed2. According to item 3 above, before fed2 became the owner of A1(x), it was in the Updates Turned Off state with regard to A1(x). Upon becoming the owner of A1(x), fed2 enters the Updates Turned On state with regard to A1(x) and so receives a Turn Updates On � service invocation for A1(x). Fed2 unsubscribes to A(x). Fed2 transfers ownership of A1(x) back to fed1. According to item 3 above, before fed1 became the owner of A1(x) it was in the Turn Updates Off state with respect to A1(x). Upon becoming the owner of A1(x), fed1 is still in the Updates Turned Off state with respect to A1(x) because no other federate is subscribed to A(x). So, even though the last advisory that fed1 had received with respect to A1(x) was Turn Updates On, and now the conditions covering that advisory have changed such that fed1 is now in the Updates Turned Off state with respect to A1(x), according to item 3 above, fed1 will not receive a Turn Updates Off � callback for A1(x). The following is an example of the use of item 4 in which the federate begins to know an object instance: Suppose fed1 and fed2 are both publishing and subscribing to A(x), but not A(y). The Attribute Scope Advisory switch is enabled at both federates. Fed1 registers an instance of this class, A1, which fed2 is expected to discover. According to item 4 above, before fed2 knew about A1, all of the instance attributes of A1 were in the Attributes Out-of-Scope state with regard to fed2; upon A1 becoming known by fed2, instance attribute A1(x) moves into the Attribute-In-Scope state at fed2 and instance attribute A1(y) remains in the Attribute-Out-of-Scope state at fed2, because A1(x) is owned by fed1 but A1(y) is not owned by any federate. Therefore, according to item 4 above, fed2 shall get an Attributes In Scope � callback only for A1(x).
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5179: Service 10.9: Get Parameter Name (dss2ftf)

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

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

Resolution: Add the �not� as suggested.
Revised Text: Add the following to 1.4.8: Service 10.9: Get Parameter Name Interpretation 1 Exception (c) should have a �not� in it. It should read �The parameter is not an available parameter of the interaction class.�
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5180: Service 10.30: Get Dimension Handle Set (dss2ftf)

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

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

Resolution: Add the suggested new pre-condition.
Revised Text: Add the following to 1.4.8: Service 10.30: Get Dimension Handle Set Interpretation 1 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. Rationale: A federate shall not be able to invoke the Get Dimension Handle Set service on a region designator that it received by any means other than as a result of creating the region itself, or having had the region realization (copy) designator passed to it in a conveyed Set of Sent Region Designators argument of either a reflect or a received interaction. It is undefined as to what behavior would be expected if a federate were to receive a region realization designator by any other means and invoke the Get Dimension Handle Set service on it.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5181: Service 10.31: Get Range Bounds: invalid region (dss2ftf)

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

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.

Resolution: Add the suggested new pre-condition.
Revised Text: Add the following to 1.4.8: Service 10.31: Get Range Bounds Interpretation 1 There shall be a precondition of 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. Rationale: 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5182: Get Range Bounds: created or conveyed (dss2ftf)

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

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

Resolution: Add the suggested new pre-condition.
Revised Text: Add the following to 1.4.8: Service 10.31: Get Dimension Range Bounds Interpretation 2 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. Rationale: A federate shall not be able to invoke the Get Range Bounds service on a region specification designator that it received by any means other than as a result of creating the region itself, or having had the region specification (copy) designator passed to it in a conveyed Set of Sent Region Designators argument of either a reflect or a received interaction. It is undefined as to what behavior would be expected if a federate were to receive a region specification designator by any other means and invoke the Get Range Bounds service on it.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5183: MOM Overview (dss2ftf)

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

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.

Resolution: Explain the meaning of �null�, as suggested.
Revised Text: Add the following to 1.4.9: 11.1: MOM Overview Interpretation 1 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5184: Section 11.4.1: Normal RTI MOM administration: item (g) (dss2ftf)

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

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

Resolution: Change the text as suggested.
Revised Text: Add the following to 1.4.9: 11.4.1: Normal RTI MOM administration: item (g) Interpretation 1 Item (g) shall refer to Table 6 instead of Table 4. Rationale: Table 6, not Table 4, is the MOM attribute table.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5185: Section 11.4.1: Normal RTI MOM administration: item (d) (dss2ftf)

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

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.

Resolution: Amend the text to allow for the exceptional cases, as suggested.
Revised Text: Add the following to 1.4.9: 11.4.1: Normal RTI MOM administration: item (g) Interpretation 2 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.� However, there exist the following exceptional cases 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. Rationale: 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. 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5186: Section 11.4.1: Normal RTI MOM administration: null values (dss2ftf)

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

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.

Resolution: Clarify the meaning of the term �null�, as suggested.
Revised Text: Add the following to 1.4.9: 11.4.1: Normal RTI MOM administration: item (g) Interpretation 3 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 expectation is that the parameter/value pair set will be present in the interaction, but the value will be an empty (zero-length) array.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5187: Section 11.4.1: Normal RTI MOM administration: federate-sent parameters (dss2ftf)

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

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.

Resolution: see above
Revised Text: Add the following to 1.4.9: 11.4.1: Normal RTI MOM administration: item (g) Interpretation 4 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. Rationale: While section 11.4.1 specifies what parameters shall be supplied when the RTI sends interactions, it 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. The rationale for why the HLAfederate parameter of the HLAmanager.HLAfederate.HLArequest.HLArequestSynchronizationPoints and the HLAmanager.HLAfederate.HLArequest.HLArequestSynchronizationPointStatus interactions is not required is that these interactions request federation-wide information rather than federate-specific information, so the value of the HLAfederate parameter is not relevant to these interactions.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Add text explaining what parameters a federate is required to supply when it
sends interactions.

Issue 5188: Table 6: MOM attribute table: HLAfederateState (dss2ftf)

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

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.

Resolution: see above
Revised Text: Revised Text: Add the following to 1.4.9: Table 6: MOM attribute table: HLAfederateState Interpretation 1 The HLAfederateState attribute of the HLAmanger.HLAfederate object class is of update type Conditional and its update condition is Service Invocation. This means that if a service invocation occurs that causes the HLAfederateState of a HLAmanger.HLAfederate object instance to change value, then the corresponding instance attribute will be updated. An exception to this occurs when a federate�s state changes from that of Active Federate to that of Federate Restore In Progress. In this case, 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. Rationale: 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. 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Amend the text as suggested to explain the exceptional case having to do with
the Federate Restore In Progress state.

Issue 5189: Table 15: MOM interaction class definitions table: HLArequestSubscriptions (dss2ftf)

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

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.

Resolution: see above
Revised Text: Add the following to 1.4.9: Table 15: MOM interaction class definitions table: HLArequestSubscriptions Interpretation 1 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 should 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. 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. Rationale: The change of the word �published� to �subscribed is a correction of a typographical error. The change that the HLArequestSubscriptions interaction shall result in one interaction of class HLAreportObjectClassSubscriptionfor each different combination of (object class, passive subscription indicator) values that are subscribed by the federate is required in order to enable the information in the HLAreportObjectClass subscription interaction to, as specified in the Table 17 parameter definitions for the HLAnumberofClasses and HLAinteractionClassList parameters, �reflect related DDM usage�. 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 HLAnumberOfClasses parameter shall represent the count of the number of different (object class, active/passive subscription indicator) values being reported because this parameter is used to indicate to the federate how many HLAreportObjectClassSubscription interactions to expect from the RTI.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Change the definition of the
HLAmanager.HLAfederate.HLArequest.HLArequestSubscriptions interaction as
suggested.

Issue 5190: Table 15: Mom interaction class definitions table: HLAreportObjectInstances (dss2ftf)

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

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.

Resolution: Add the word �successfully� to the table entry.
Revised Text: Add the following to 1.4.9: Table 15: MOM interaction class definitions table: HLAreportObjectInstancesUpdated: Interpretation 1 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Discussion:

Issue 5191: Mom interaction class definitions table: HLArequestSynchronizationPointSta (dss2ftf)

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

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.

Resolution: Add text clarifying the specified case, as suggested.
Revised Text: Add the following to 1.4.9: Table 15: MOM interaction class definitions table:HLAreportSynchronizationPointStatus Interpretation 1 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. Rationale: Each HLAmanger.HLAfederate.HLAreport.HLAreportSynchronizationPointStatus interaction reports on the status of only one synchronization point. Because the HLAmanger.HLAfederate.HLArequest.HLArequestSynchronizationPointStatus interaction does not include a HLAsyncPointName parameter that could be used to specify which synchronization point for which a report is requested, one HLAmanger.HLAfederate.HLAreport.HLAreportSynchronizationPointStatus interaction shall be sent for each active synchronization point in the federation execution. A federate is able to use the HLAmanger.HLAfederate.HLArequest.HLArequestSynchronizationPoints interaction to receive a report of all active synchronization points in the federation execution, so if a federate invokes the HLAmanager.HLAfederate.HLArequest.HLArequestSynchronizationPointStatus interaction when there are no active synchronization points, it is allowable for that federate to fail to receive a HLAmanger.HLAfederate.HLAreport.HLAreportSynchronizationPointStatus interaction in response.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Discussion:

Issue 5192: Table 16: MOM attribute definitions table: HLAFDDID (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 16: MOM attribute definitions table: HLAFDDID Interpretation 1 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 pathspecific 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.
Actions taken:
April 10, 2002: rceived issue
October 23, 2002: closed issue

Issue 5193: Table 16: MOM attribute definitions table: HLAreflectionsReceived (dss2ftf)

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

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

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 16: MOM attribute definitions table: HLAreflectionsReceived Interpretation 1 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).
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5194: Table 16: MOM attribute definitions table: HLAupdatesSent (dss2ftf)

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

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

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 16: MOM attribute definitions table: HLAupdatesSent Interpretation 1 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).
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5195: Table 16: MOM attribute definitions table: HLAlastSaveTime: undefined (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 16: MOM attribute definitions table: HLAlastSaveTime Interpretation 1 According to the attribute definitions in Table 16, the HLAlastSaveTime value shall not be defined if no timed saves have occurred. By �not defined� the expectation is that the attribute/value pair set will be present in the reflect, but the value will be an empty (zerolength) HLAlogicalTime array.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5196: Table 16: MOM attribute definitions table:HLAlastSaveTime: last save untime (dss2ftf)

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

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.

Resolution: Add the recommended text.
Revised Text: Add the following to 1.4.9: Table 16: MOM attribute definitions table: HLAlastSaveTime Interpretation 2 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. Rationale: The value of the HLAlastSaveName attribute should correspond to the value of the HLAlastSaveTime attribute. The way the definition of HLAlastSaveTime is worded in the specification, if a timed save occurs, followed by an untimed save, then the value of HLAlastSaveName would not correspond with the value of HLAlastSaveTime, which could prove astonishing to a user. Therefore, in order to ensure that these two values always correspond to the same save, if the last save is an untimed save, then the value of the HLAlastSaveTime attribute will not be defined.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Discussion:

Issue 5197: Table 16: MOM attribute definitions table: HLAnextSaveTime (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 16: MOM attribute definitions table: HLAnextSaveTime Interpretation 1 According to the attribute definitions in Table 16, the HLAnextSaveTime value shall not be defined if no timed saves are scheduled. By �not defined� the expectation is that the attribute/value pair set will be present in the reflect, but the value will be an empty (zerolength) HLAlogicalTime array.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5198: Table 16: MOM attribute definitions table: HLAobjectInstancesUpdated (dss2ftf)

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

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.

Resolution: Add the word �successfully� to the text.
Revised Text: Add the following to 1.4.9: Table 16: MOM attribute definitions table: HLAobjectInstancesUpdated Interpretation 1 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5199: Table 16: MOM attribute definitions table: HLAobjectInstancesDeleted (dss2ftf)

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

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.

Resolution: Add the following to 1.4.9:
Revised Text: Table 16: MOM attribute definitions table: HLAobjectInstancesDeleted Interpretation 1 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5200: Table 16: MOM attribute definitions table: HLAobjectInstancesRegistered (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 16: MOM attribute definitions table: HLAobjectInstancesRegistered Interpretation 1 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5201: Table 16: MOM attribute definitions table: HLAobjectInstancesDiscovered (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 16: MOM attribute definitions table: HLAobjectInstancesDiscovered Interpretation 1 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5202: T16: MOM attribute definitions table: HLAtimeGrantedTime and HLAtimeAdvanci (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 16: MOM attribute definitions table: HLAtimeGrantedTime and HLAtimeAdvancingTime Interpretation 1 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. 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.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5203: Table 17: MOM parameter definitions table: HLAreportPeriod (dss2ftf)

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

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.

Resolution: Add the suggested explanatory text.
Revised Text: Add the following to 1.4.9: Table 17: MOM parameter definitions table: HLAreportPeriod Interpretation 1 If no interaction of class HLAmanager.HLAfederate.HLAadjust.HLAsetTiming has been sent, then no periodic updates of MOM attribute values shall be generated. Rationale: If no interaction of class HLAmanager.HLAfederate.HLAadjust.HLAsetTiming has been sent, then the value of the HLAreportPeriod is not defined. It makes sense to interpret this value to be zero (which means that periodic updates will not occur) unless and until this HLAreportPeriod value is explicitly set by the invocation of a HLAmanager.HLAfederate.HLAadjust.HLAsetTiming interaction.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5204: Table 17: interaction subclass HLAmanager.HLAfederate... (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 17: MOM Interaction subclass HLAmanager.HLAfederate.HLAreport.HLAreportUpdatesSent Interpretation 1 According to the definition of the HLAupdateCounts parameter in the HLAReportUpdatesSent interaction subclass given in Table 17, this parameter consists of a list of update counts, each of which consists of an object class handle and "the number of updates sent of that class". The question of what makes an update be of one class as opposed to another is answered in Table 15 (HLAreportUpdatesSent Interaction class definition): the class of an update is the registered class of the object instance of the update. However, 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. The expectation is 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 besteffort 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. Rationale: The update service is a service that acts on instance attributes, not on object instances. Similarly, transportation type is a property of instance attributes rather than object instances. The fact that updates to several different instance attributes of an object instance can be bundled together in a single Update Attribute Values service invocation is provided as a convenience to the programmer. The value of an update count should not depend on whether or not a federate chooses to combine certain instance attribute value updates together in a single call or perform these updates as separate Update Attribute Values service invocations.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5205: Table 17: interaction subclass (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 17: MOM Interaction subclass HLAmanager.HLAfederate.HLAreport.HLAreportUpdatesSent Interpretation 2 If no updates of instance attributes of any object instances 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. (This is illustrated by interaction 1 below.) Consider the following example: Suppose there are 3 classes defined in the FDD, A, A.B, and A.C. Suppose there are 2 transportation types available for use. Suppose that only the following 2 updates were sent: Update of an object instance of class A, reliable attribute x Update of an object instance of class A.B, reliable attribute x and reliable attribute z. Then, 2 HLAreportUpdatesSent interactions would be sent in response to a HLARequestUpdatesSent interaction, and those interactions would be as follows: 1. An interaction with 2 parameters: transportation type Reliable, and an HLAobjectClassBasedCount array with 2 HLAobjectClassBasedCount elements in it; one HLAobjectClassBasedCount element would be (class A, 1) the other element would be (class A.B, 2). (There would be no HLAobjectClassBasedCount element for class A.C in this array.) 2. An interaction with 2 parameters: transportation type Best effort, and an HLAobjectClassBasedCount array with no elements in it.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5206: Table 17: interaction subclass, another issue (dss2ftf)

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

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

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 17: MOM Interaction subclass HLAmanager.HLAfederate.HLAreport.HLAreportReflectionsReceived Interpretation 1 According to the definition of the HLAreflectCounts parameter in the HLAReportReflectionsReceived interaction subclass, this parameter consists of a list of reflection counts, each of which consists of an object class handle and "the number of reflections received of that class". This wording is ambiguous regarding the question of whether the number of reflections 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. The expectation is 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. Rationale: The rationale for this interpretation is analogous to the rationale for the MOM Table 17: interaction subclass HLAmanager.HLAfederate.HLAreport.HLAreportUpdatesSent interpretation. As with the Update Attribute Values service, the Reflect Attribute Values � service is a service that acts on instance attributes, not on object instances. Similarly, transportation type is a property of instance attributes rather than of object instances.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5207: Table 17: interaction subclass (issue3) (dss2ftf)

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

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.

Resolution: Add the suggested clarifying text.
Revised Text: Add the following to 1.4.9: Table 17: MOM Interaction subclass HLAmanager.HLAfederate.HLAreport.HLAreportReflectionsReceived Interpretation 2 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. (This is illustrated by interaction 2 in the example below.) 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. (This is illustrated by interaction 1 below.) Consider the following example: Suppose there are 3 classes defined in the FDD, A, A.B, and A.C. Suppose there are 2 transportation types available for use. Suppose that only the following 2 reflects were received: Reflect of an object instance of class A, reliable attribute x Reflect of an object instance of class A.B, reliable attribute x and reliable attribute z. Then, 2 HLAreportReflectionsReceived interactions would be sent in response to a HLARequestReflectionsReceived interaction, and those interactions would be as follows: 1. An interaction with 2 parameters: transportation type Reliable, and an HLAobjectClassBasedCount array with 2 HLAobjectClassBasedCount elements in it; one HLAobjectClassBasedCount element would be (class A, 1) the other element would be (class A.B, 2). (There would be no HLAobjectClassBasedCount element for class A.C in this array.) 2. An interaction with 2 parameters: transportation type Best effort, and an HLAobjectClassBasedCount array with no elements in it.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5208: MOM Table 17: use of HLAobjectClassBasedCounts array datatype (dss2ftf)

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

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

Resolution: Add the suggested text.
Revised Text: Add the following to 1.4.9: Table 17: MOM use of HLAobjectClassBasedCounts array datatype in zero-value HLAobjectClassBasedCount cases Interpretation 1 This interpretation is a generalization of each of the Interpretation 2 stated above for the HLAmanager.HLAfederate.HLAreport.HLAreportUpdatesSent and the HLAmanager.HLAfederate.HLAreport.HLAreportReflectionsReceived interactions. 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 (see its Interpretation 2) � HLAmanager.HLAfederate.HLAreport.HLAreportReflectionsReceived (see its Interpretation 2)
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5209: MOM Table 17: use of HLAinteractionCounts array datatype (dss2ftf)

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

: 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

Resolution: Add the suggested text.
Revised Text: Add the following to 1.4.9: Table 17: MOM use of HLAinteractionCounts array datatype in zero-value HLAinteractionCount cases Interpretation 1 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
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5210: MOM Table 17: HLAreportServiceInvocation: HLAreturnedArguments parameter (dss2ftf)

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

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

Resolution: Change the spelling of this argument in Table 17 to be plural.
Revised Text: Add the following to 1.4.9: Table 17: MOM HLAreportServiceInvocation: HLAreturnedArguments parameter Interpretation 1 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�.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5211: MOM Table 17: HLAreportMOMexception: HLAservice parameter (dss2ftf)

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

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.

Resolution: see above
Revised Text: Add the following to 1.4.9: Table 17: MOM HLAreportMOMexception: HLAservice parameter Interpretation 1 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 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. Rationale: In the second case, the case in which the HLAreportMOMexception interaction is sent by the RTI because a MOM interaction without all of the necessary parameters was sent, there is no HLA service interaction involved. Providing the name of the class of interaction that was sent that caused the HLAreportMOMexception invocation at least provides information to the sending federate as to what the offending class of the sent interaction was.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Add text explaining the expected value of this parameter 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.

Issue 5212: MOM Table 17: HLAreportMOMexception: fully-qualified names (dss2ftf)

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

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

Resolution: Add text explaining this requirement
Revised Text: Add the following to 1.4.9: Table 17: MOM HLAreportMOMexception: HLAservice parameter Interpretation 2 The name of the interaction class provided shall always be fully qualified, as defined in the OMT, so as to avoid potential ambiguities.
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Issue 5213: All APIs: Service 7.6 (dss2ftf)

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

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

Resolution: see above
Revised Text: On pages 1-32 to 1-33 of the DSS Specification, the Confirm Divestiture service (7.6) shall be amended as follows so that it now raises the following additional exception: NoAcquisitionPending: void confirm_divestiture ( in ObjectInstanceHandle theObject, in CompositeTypes::AttributeHandleSet theAttributes, in UserSuppliedTag theTag) raises ( ObjectInstanceNotKnown, AttributeNotDefined, AttributeNotOwned, AttributeDivestitureWasNotRequested, FederateNotExecutionMember, SaveInProgress, RestoreInProgress, RTIinternalError NoAcquisitionPending);
Actions taken:
April 10, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Add the additional exception for the Confirm Divestiture service to the CORBA IDL in
the DSS.

Issue 5234: Overview of Ownership Management: RTI responsibilities (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan(at)mitre.org)
Nature: Revision
Severity: Significant
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."  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, {x})
Fed2 invokes Subscribe Object Class Attributes (A, {x, y})
Fed2 invokes Publish Object Class Attributes (A {x, y})
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.

Resolution: Delete the text as suggested.
Revised Text: Add the following to 1.4.5: Section 7.1: Overview of Ownership Management Interpretation 1 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. Rationale: 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. In other interpretations in this document (interpretations for Unconditional Attribute Ownership Divestiture and Resign Federation Execution), text is suggested 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. The second sentence, about the RID, is simply out of place in the standard, as it refers to implementation-specific behavior. Furthermore, it would allow such a wide variety of RTI behavior that it would make testing infeasible.
Actions taken:
April 30, 2002: received issue
October 23, 2002: closed issue

Issue 5235: Resign Federation Execution (dss2ftf)

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

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.

Resolution: Add the suggested text.
Revised Text: Add the following to 1.4.2: Service 4.5: Resign Federation Execution Interpretation 1 If a federate invokes this service with either directive 1, 4, or 5, then for each instance attribute that becomes unowned as a result, 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. Rationale: The Resign Federation Execution service description does not explain or even mention the mechanism by 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). The text in this interpretation describes this mechanism. It makes clear the requirement that the RTI must try to find an owner for unowned instance attributes that become unowned as the result of the explicit use of an ownership management directive. If there are no federates that are trying to acquire an unowned instance attribute, then the RTI must use the Request Attribute Ownership Assumption � service as the mechanism for offering ownership of the unowned instance attribute to federates that are eligible to own it. If there is one or more federate that is trying to acquire an unowned instance attribute, then the RTI may either give ownership of the instance attribute to one of the federates that are trying to acquire it without offering ownership of it to other eligible federates, or it may use the Request Attribute Ownership Assumption � service to offer ownership of the unowned instance attribute to eligible federates before granting ownership of the attribute to a federate that expresses an interest in acquiring it.
Actions taken:
April 30, 2002: received issue
October 23, 2002: closed issue

Issue 5236: Unconditional Attribute Ownership Divestiture (dss2ftf)

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

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.

Resolution: Delete the text as suggested.
Revised Text: Add the following to 1.4.5: Service 7.2: Unconditional Attribute Ownership Divestiture Interpretation 1 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. Rationale: The Unconditional Attribute Ownership Divestiture service description does not explain or even mention the mechanism by 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. The text in this interpretation explains this mechanism. If there are no federates that are trying to acquire an unowned instance attribute, then the RTI must use the Request Attribute Ownership Assumption � service as the mechanism for offering ownership of the unowned instance attribute to federates that are eligible to own it. If there is one or more federate that is trying to acquire an unowned instance attribute, then the RTI may either give ownership of the instance attribute to one of the federates that are trying to acquire it without offering ownership of it to other eligible federates, or it may use the Request Attribute Ownership Assumption � service to offer ownership of the unowned instance attribute to eligible federates before granting ownership of the attribute to a federate that expresses an interest in acquiring it.
Actions taken:
April 30, 2002: received issue
October 23, 2002: closed issue

Issue 5297: Join Federation Execution (dss2ftf)

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

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

Resolution: Add the text suggested in the issue statement.
Revised Text: Add the following to 1.4.2: Service 4.4: Join Federation Execution Interpretation 1 The introductory text says, �The returned joined federate designator shall be unique for the lifetime of the federation execution.� However, it should say, �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.� Rationale: 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 in the federation execution 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 is incorrect as written and needs to be amended as described in the interpretation above in order to be correct.
Actions taken:
May 15, 2002: received issue
October 23, 2002: closed issue

Issue 5298: Attribute Ownership Acquisition: increased prohibition (dss2ftf)

Click here for this issue's archive.
Source: MITRE (Ms. Susan Symington, susan(at)mitre.org)
Nature: Revision
Severity: Minor
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 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"]�.

Resolution: see above
Revised Text: Add the following to 1.4.5: Service 7.8: Attribute Ownership Acquisition Interpretation 2 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 replaced 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. Figure 15: Establishing Ownership of Instance Attribute (i, k, j) Interpretation 1 Modify the statechart in Figure 15 so that the Request Attribute Ownership Release transition has a guard added to it that says, � [not in "Waiting for a New Owner to be Found" ^ not in "Completing Divestiture"]�. Rationale: This guard is required to make the statechart consistent with Intepretation 2 of the Attribute Ownership Acquisition service in this document.
Actions taken:
May 15, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Add the text suggested in the issue statement. Also add a necessary guard to Figure 15 to
make it consistent with this interpretation.

Issue 5301: Simplify representation of Logical Time (dss2ftf)

Click here for this issue's archive.
Source: DMSO (Mr. Michael Shadid, mshadid(at)mitre.org)
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: Simplify by replacing the abstract valuetype for logical time with a double.
Revised Text: The section headed �Logical time, time stamps, and lookahead� on pp. 1-13 to 1-15 should be replaced with the following: Logical time and logical time intervals are represented by a double value. The following changes are made to the IDL: The forward reference to LogicalTimeInterval is removed. The definitions of abstract valuetypes LogicalTime and LogicalTimeInterval are replaced, respectively, with: typedef double LogicalTime; typedef double LogicalTimeInterval; The definitions of abstract valuetypes LogicalTimeFactory and LogicalTimeIntervalFactory are removed.
Actions taken:
May 16, 2002: received issue
October 23, 2002: closed issue

Issue 5302: Simplify representation of Handle Types (dss2ftf)

Click here for this issue's archive.
Source: DMSO (Mr. Michael Shadid, mshadid(at)mitre.org)
Nature: Revision
Severity: Minor
Summary:

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 { \
    boolean equals(in A h); \
    long hash_code(); \
    string to_string(); \
    long encoded_length(); \
    Encoding encode(); \
  }; \
  interface A##Factory { \
    A decode(in Encoding anEncoding) \
      raises(CouldNotDecode, FederateNotExecutionMember); \
  };

Resolution: Replace valuetype definitions of handles with IDL interfaces.
Revised Text: In the section labeled �Handles� from pp 1-9 to 1-10, the word valuetype is everywhere 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� are replaced by �interface�. In the IDL, the HANDLETYPE macro is replaced by the following: #define HANDLETYPE(A) \ interface A { \ boolean equals(in A h); \ long hash_code(); \ string to_string(); \ long encoded_length(); \ Encoding encode(); \ }; \ interface A##Factory { \ A decode(in Encoding anEncoding) \ raises(CouldNotDecode, FederateNotExecutionMember); \ };
Actions taken:
May 16, 2002: received issue
October 23, 2002: closed issue

Issue 5303: Simplify representation of order and transportation types (dss2ftf)

Click here for this issue's archive.
Source: DMSO (Mr. Michael Shadid, mshadid(at)mitre.org)
Nature: Revision
Severity: Minor
Summary:

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 {
    boolean equals(in FederateHandle h);
    long hash_code();
    string to_string();
    long encoded_length();
    Encoding encode();
  };


  interface OrderTypeFactory {
    OrderType decode(in Encoding anEncoding);
  };


  interface TransportationType {
    boolean equals(in FederateHandle h);
    long hash_code();
    string to_string();
    long encoded_length();
    Encoding encode();
  };


  interface TransportationTypeFactory {
    TransportationType decode(in Encoding anEncoding);
  };

Resolution: see above
Revised Text: 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 { boolean equals(in FederateHandle h); long hash_code(); string to_string(); long encoded_length(); Encoding encode(); }; interface OrderTypeFactory { OrderType decode(in Encoding anEncoding); }; interface TransportationType { boolean equals(in FederateHandle h); long hash_code(); string to_string(); long encoded_length(); Encoding encode(); }; interface TransportationTypeFactory { TransportationType decode(in Encoding anEncoding); };
Actions taken:
May 16, 2002: received issue
October 23, 2002: closed issue

Discussion:

Resolution:
Replace the valuetype definitions for order and transportation types with IDL interfaces
for them and corresponding factory interfaces.