Distributed Simulation Systems Avatar
  1. OMG Specification

Distributed Simulation Systems — Closed Issues

  • Acronym: DSS
  • Issues Count: 112
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DSS2-112 Simplify representation of order and transportation types DSS 1.1 DSS 2.0 Resolved closed
DSS2-111 Simplify representation of Handle Types DSS 1.1 DSS 2.0 Resolved closed
DSS2-109 Attribute Ownership Acquisition: increased prohibition DSS 1.1 DSS 2.0 Resolved closed
DSS2-110 Simplify representation of Logical Time DSS 1.1 DSS 2.0 Resolved closed
DSS2-108 Join Federation Execution DSS 1.1 DSS 2.0 Resolved closed
DSS2-107 Unconditional Attribute Ownership Divestiture DSS 1.1 DSS 2.0 Resolved closed
DSS2-106 Resign Federation Execution DSS 1.1 DSS 2.0 Resolved closed
DSS2-105 Overview of Ownership Management: RTI responsibilities DSS 1.1 DSS 2.0 Resolved closed
DSS2-104 All APIs: Service 7.6 DSS 1.1 DSS 2.0 Resolved closed
DSS2-101 MOM Table 17: HLAreportServiceInvocation: HLAreturnedArguments parameter DSS 1.1 DSS 2.0 Resolved closed
DSS2-102 MOM Table 17: HLAreportMOMexception: HLAservice parameter DSS 1.1 DSS 2.0 Resolved closed
DSS2-100 MOM Table 17: use of HLAinteractionCounts array datatype DSS 1.1 DSS 2.0 Resolved closed
DSS2-103 MOM Table 17: HLAreportMOMexception: fully-qualified names DSS 1.1 DSS 2.0 Resolved closed
DSS2-96 Table 17: interaction subclass DSS 1.1 DSS 2.0 Resolved closed
DSS2-99 MOM Table 17: use of HLAobjectClassBasedCounts array datatype DSS 1.1 DSS 2.0 Resolved closed
DSS2-98 Table 17: interaction subclass (issue3) DSS 1.1 DSS 2.0 Resolved closed
DSS2-97 Table 17: interaction subclass, another issue DSS 1.1 DSS 2.0 Resolved closed
DSS2-95 Table 17: interaction subclass HLAmanager.HLAfederate... DSS 1.1 DSS 2.0 Resolved closed
DSS2-91 Table 16: MOM attribute definitions table: HLAobjectInstancesRegistered DSS 1.1 DSS 2.0 Resolved closed
DSS2-90 Table 16: MOM attribute definitions table: HLAobjectInstancesDeleted DSS 1.1 DSS 2.0 Resolved closed
DSS2-94 Table 17: MOM parameter definitions table: HLAreportPeriod DSS 1.1 DSS 2.0 Resolved closed
DSS2-92 Table 16: MOM attribute definitions table: HLAobjectInstancesDiscovered DSS 1.1 DSS 2.0 Resolved closed
DSS2-93 T16: MOM attribute definitions table: HLAtimeGrantedTime and HLAtimeAdvanci DSS 1.1 DSS 2.0 Resolved closed
DSS2-87 Table 16: MOM attribute definitions table:HLAlastSaveTime: last save untime DSS 1.1 DSS 2.0 Resolved closed
DSS2-88 Table 16: MOM attribute definitions table: HLAnextSaveTime DSS 1.1 DSS 2.0 Resolved closed
DSS2-89 Table 16: MOM attribute definitions table: HLAobjectInstancesUpdated DSS 1.1 DSS 2.0 Resolved closed
DSS2-85 Table 16: MOM attribute definitions table: HLAupdatesSent DSS 1.1 DSS 2.0 Resolved closed
DSS2-86 Table 16: MOM attribute definitions table: HLAlastSaveTime: undefined DSS 1.1 DSS 2.0 Resolved closed
DSS2-84 Table 16: MOM attribute definitions table: HLAreflectionsReceived DSS 1.1 DSS 2.0 Resolved closed
DSS2-81 Table 15: Mom interaction class definitions table: HLAreportObjectInstances DSS 1.1 DSS 2.0 Resolved closed
DSS2-83 Table 16: MOM attribute definitions table: HLAFDDID DSS 1.1 DSS 2.0 Resolved closed
DSS2-80 Table 15: MOM interaction class definitions table: HLArequestSubscriptions DSS 1.1 DSS 2.0 Resolved closed
DSS2-82 Mom interaction class definitions table: HLArequestSynchronizationPointSta DSS 1.1 DSS 2.0 Resolved closed
DSS2-78 Section 11.4.1: Normal RTI MOM administration: federate-sent parameters DSS 1.1 DSS 2.0 Resolved closed
DSS2-79 Table 6: MOM attribute table: HLAfederateState DSS 1.1 DSS 2.0 Resolved closed
DSS2-77 Section 11.4.1: Normal RTI MOM administration: null values DSS 1.1 DSS 2.0 Resolved closed
DSS2-75 Section 11.4.1: Normal RTI MOM administration: item (g) DSS 1.1 DSS 2.0 Resolved closed
DSS2-76 Section 11.4.1: Normal RTI MOM administration: item (d) DSS 1.1 DSS 2.0 Resolved closed
DSS2-72 Service 10.31: Get Range Bounds: invalid region DSS 1.1 DSS 2.0 Resolved closed
DSS2-73 Get Range Bounds: created or conveyed DSS 1.1 DSS 2.0 Resolved closed
DSS2-74 MOM Overview DSS 1.1 DSS 2.0 Resolved closed
DSS2-71 Service 10.30: Get Dimension Handle Set DSS 1.1 DSS 2.0 Resolved closed
DSS2-70 Service 10.9: Get Parameter Name DSS 1.1 DSS 2.0 Resolved closed
DSS2-69 Section 10.1.2: Advisory Switches DSS 1.1 DSS 2.0 Resolved closed
DSS2-67 DDM Typos: declaration DSS 1.1 DSS 2.0 Resolved closed
DSS2-66 Service 9.13: Request Attribute Value Update With Regions DSS 1.1 DSS 2.0 Resolved closed
DSS2-65 Service 9.12: Send Interaction With Regions: invalid region DSS 1.1 DSS 2.0 Resolved closed
DSS2-68 DDM Typos: handle DSS 1.1 DSS 2.0 Resolved closed
DSS2-61 Service 9.11:Unsubscribe Interaction Class With Regions: interaction receip DSS 1.1 DSS 2.0 Resolved closed
DSS2-64 Service 9.12: Send Interaction With Regions: which parameters are sent DSS 1.1 DSS 2.0 Resolved closed
DSS2-60 Service 9.10: Subscribe Interaction Class With Regions: invalid region DSS 1.1 DSS 2.0 Resolved closed
DSS2-63 Service 9.11: Unsubscribe Interaction Class With Regions: invalid region DSS 1.1 DSS 2.0 Resolved closed
DSS2-62 Service 9.11: Unsubscribe Interaction Class With Regions: error DSS 1.1 DSS 2.0 Resolved closed
DSS2-59 Service 9.10: Subscribe Interaction Class With Regions: passive indicator DSS 1.1 DSS 2.0 Resolved closed
DSS2-58 Service 9.9: Unsubscribe Object Class Attributes With Regions: invalid regi DSS 1.1 DSS 2.0 Resolved closed
DSS2-57 Service 9.9: Unsubscribe Object Class Attributes With Regions: discover DSS 1.1 DSS 2.0 Resolved closed
DSS2-56 Service 9.8: Subscribe Object Class Attributes With Regions: invalid region DSS 1.1 DSS 2.0 Resolved closed
DSS2-55 Service 9.8: Subscribe Object Class Attributes With Regions: passive indica DSS 1.1 DSS 2.0 Resolved closed
DSS2-50 Register Object Instance With Regions: invalid region DSS 1.1 DSS 2.0 Resolved closed
DSS2-54 Service 9.7: Unassociate Regions For Updates: invalid region DSS 1.1 DSS 2.0 Resolved closed
DSS2-52 Service 9.6: Associate Regions For Updates: invalid region DSS 1.1 DSS 2.0 Resolved closed
DSS2-51 Service 9.6: Associate Regions For Updates DSS 1.1 DSS 2.0 Resolved closed
DSS2-49 Register Object Instance With Regions: unique names DSS 1.1 DSS 2.0 Resolved closed
DSS2-53 Service 9.7: Unassociate Regions For Updates: irrelevant attributes DSS 1.1 DSS 2.0 Resolved closed
DSS2-46 Section 9.1.7: Convey Region Designator Sets Switch: use in support DSS 1.1 DSS 2.0 Resolved closed
DSS2-47 Service 9.3: Commit Region Modifications DSS 1.1 DSS 2.0 Resolved closed
DSS2-48 Service 9.4: Delete Region DSS 1.1 DSS 2.0 Resolved closed
DSS2-45 Section 9.1.7: Convey Region Designator Sets Switch: copies conveyed DSS 1.1 DSS 2.0 Resolved closed
DSS2-43 "Invalid Region" exceptions DSS 1.1 DSS 2.0 Resolved closed
DSS2-42 Section 9.1.2: Default Ranges DSS 1.1 DSS 2.0 Resolved closed
DSS2-44 Section 9.1.7: Convey Region Designator Sets Switch: when conveyed DSS 1.1 DSS 2.0 Resolved closed
DSS2-39 DDM Overview: determining specified dimensions DSS 1.1 DSS 2.0 Resolved closed
DSS2-40 DDM Overview: Commit Region Modifications DSS 1.1 DSS 2.0 Resolved closed
DSS2-38 DDM Overview: nomenclature DSS 1.1 DSS 2.0 Resolved closed
DSS2-41 DDM Overview: Steps to Create a Region Specification DSS 1.1 DSS 2.0 Resolved closed
DSS2-37 Service 8.12: Flush Queue Request DSS 1.1 DSS 2.0 Resolved closed
DSS2-36 Figure 16: Temporal State statechart DSS 1.1 DSS 2.0 Resolved closed
DSS2-32 Service 7.9: Attribute Ownership Acquisition If Available: self-transition DSS 1.1 DSS 2.0 Resolved closed
DSS2-34 Service 7.10: Attribute Ownership Unavailable DSS 1.1 DSS 2.0 Resolved closed
DSS2-35 Service 7.15: Confirm Attribute Ownership Acquisition Cancellation DSS 1.1 DSS 2.0 Resolved closed
DSS2-31 Service 7.8: Attribute Ownership Acquisition prohibited DSS 1.1 DSS 2.0 Resolved closed
DSS2-33 Service 7.9: Attribute Ownership Acquisition If Available: response not gua DSS 1.1 DSS 2.0 Resolved closed
DSS2-30 Service 7.8: Attribute Ownership Acquisition invoked twice DSS 1.1 DSS 2.0 Resolved closed
DSS2-29 Service 7.7: Attribute Ownership Acquisition Notification DSS 1.1 DSS 2.0 Resolved closed
DSS2-28 Service 7.6: Confirm Divestiture DSS 1.1 DSS 2.0 Resolved closed
DSS2-27 Service 7.4: Request Attribute Ownership Assumption DSS 1.1 DSS 2.0 Resolved closed
DSS2-26 Service 7.3: Negotiated Attribute Ownership Divestiture: divesting DSS 1.1 DSS 2.0 Resolved closed
DSS2-25 Service 7.3: Negotiated Attribute Ownership Divestiture: finding owners DSS 1.1 DSS 2.0 Resolved closed
DSS2-23 Figure 15: New Guard DSS 1.1 DSS 2.0 Resolved closed
DSS2-24 Section 7.1.4: User-supplied Tags DSS 1.1 DSS 2.0 Resolved closed
DSS2-22 Figure 15: New Self-transition DSS 1.1 DSS 2.0 Resolved closed
DSS2-21 Figure 15: New State DSS 1.1 DSS 2.0 Resolved closed
DSS2-19 Figure 15: New Transition DSS 1.1 DSS 2.0 Resolved closed
DSS2-20 Figure 15: Modified Transition Label DSS 1.1 DSS 2.0 Resolved closed
DSS2-18 Section 7.1: Overview of Ownership Management DSS 1.1 DSS 2.0 Resolved closed
DSS2-16 Service 6.8: Send Interaction DSS 1.1 DSS 2.0 Resolved closed
DSS2-13 Section 6.1: Object Management Overview DSS 1.1 DSS 2.0 Resolved closed
DSS2-17 Service 6.10: Delete Object Instance DSS 1.1 DSS 2.0 Resolved closed
DSS2-14 Service 6.4: Register Object Instance DSS 1.1 DSS 2.0 Resolved closed
DSS2-15 Service 6.5: Discover Object Instance DSS 1.1 DSS 2.0 Resolved closed
DSS2-12 Service 5.11: Stop Registration For Object Class DSS 1.1 DSS 2.0 Resolved closed
DSS2-10 Service 5.6: Subscribe Object Class Attributes DSS 1.1 DSS 2.0 Resolved closed
DSS2-11 Service 5.10: Start Registration For Object Class DSS 1.1 DSS 2.0 Resolved closed
DSS2-9 Service 5.3: Unpublish Object Class Attributes DSS 1.1 DSS 2.0 Resolved closed
DSS2-8 Service 5.2: Publish Object Class Attributes DSS 1.1 DSS 2.0 Resolved closed
DSS2-5 Figure 10: Class Attribute (i, j) DSS 1.1 DSS 2.0 Resolved closed
DSS2-7 Figure 12: Interaction Class (m) DSS 1.1 DSS 2.0 Resolved closed
DSS2-4 Service 4.24: Query Federation Restore Status DSS 1.1 DSS 2.0 Resolved closed
DSS2-6 Figure 11: Class Attribute (i, HLAprivilegeToDeleteObject) DSS 1.1 DSS 2.0 Resolved closed
DSS2-1 Definition 3.1.66: published DSS 1.1 DSS 2.0 Resolved closed
DSS2-3 Figure 2: Lifetime of a Federate: Meaning of Restore In Progress DSS 1.1 DSS 2.0 Resolved closed
DSS2-2 Figure 3: Lifetime of a Federate: Meaning of Save In Progress DSS 1.1 DSS 2.0 Resolved closed

Issues Descriptions

Simplify representation of order and transportation types

  • Key: DSS2-112
  • Legacy Issue Number: 5303
  • Status: closed  
  • Source: DMSO ( Michael Shadid)
  • 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); }

    ;

  • Reported: DSS 1.1 — Thu, 16 May 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Simplify representation of Handle Types

  • Key: DSS2-111
  • Legacy Issue Number: 5302
  • Status: closed  
  • Source: DMSO ( Michael Shadid)
  • 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); \ }

    ;

  • Reported: DSS 1.1 — Thu, 16 May 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Replace valuetype definitions of handles with IDL interfaces.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attribute Ownership Acquisition: increased prohibition

  • Key: DSS2-109
  • Legacy Issue Number: 5298
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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"]”.

  • Reported: DSS 1.1 — Wed, 15 May 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Simplify representation of Logical Time

  • Key: DSS2-110
  • Legacy Issue Number: 5301
  • Status: closed  
  • Source: DMSO ( Michael Shadid)
  • 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.

  • Reported: DSS 1.1 — Thu, 16 May 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Join Federation Execution

  • Key: DSS2-108
  • Legacy Issue Number: 5297
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.”

  • Reported: DSS 1.1 — Wed, 15 May 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the text suggested in the issue statement.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unconditional Attribute Ownership Divestiture

  • Key: DSS2-107
  • Legacy Issue Number: 5236
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 30 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Delete the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Resign Federation Execution

  • Key: DSS2-106
  • Legacy Issue Number: 5235
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 30 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Overview of Ownership Management: RTI responsibilities

  • Key: DSS2-105
  • Legacy Issue Number: 5234
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 30 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Delete the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

All APIs: Service 7.6

  • Key: DSS2-104
  • Legacy Issue Number: 5213
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • Summary:

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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOM Table 17: HLAreportServiceInvocation: HLAreturnedArguments parameter

  • Key: DSS2-101
  • Legacy Issue Number: 5210
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOM Table 17: HLAreportMOMexception: HLAservice parameter

  • Key: DSS2-102
  • Legacy Issue Number: 5211
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOM Table 17: use of HLAinteractionCounts array datatype

  • Key: DSS2-100
  • Legacy Issue Number: 5209
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOM Table 17: HLAreportMOMexception: fully-qualified names

  • Key: DSS2-103
  • Legacy Issue Number: 5212
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • Summary:

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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add text explaining this requirement

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 17: interaction subclass

  • Key: DSS2-96
  • Legacy Issue Number: 5205
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOM Table 17: use of HLAobjectClassBasedCounts array datatype

  • Key: DSS2-99
  • Legacy Issue Number: 5208
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 17: interaction subclass (issue3)

  • Key: DSS2-98
  • Legacy Issue Number: 5207
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 17: interaction subclass, another issue

  • Key: DSS2-97
  • Legacy Issue Number: 5206
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 17: interaction subclass HLAmanager.HLAfederate...

  • Key: DSS2-95
  • Legacy Issue Number: 5204
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 16: MOM attribute definitions table: HLAobjectInstancesRegistered

  • Key: DSS2-91
  • Legacy Issue Number: 5200
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 16: MOM attribute definitions table: HLAobjectInstancesDeleted

  • Key: DSS2-90
  • Legacy Issue Number: 5199
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the following to 1.4.9:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 17: MOM parameter definitions table: HLAreportPeriod

  • Key: DSS2-94
  • Legacy Issue Number: 5203
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested explanatory text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 16: MOM attribute definitions table: HLAobjectInstancesDiscovered

  • Key: DSS2-92
  • Legacy Issue Number: 5201
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

T16: MOM attribute definitions table: HLAtimeGrantedTime and HLAtimeAdvanci

  • Key: DSS2-93
  • Legacy Issue Number: 5202
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 16: MOM attribute definitions table:HLAlastSaveTime: last save untime

  • Key: DSS2-87
  • Legacy Issue Number: 5196
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the recommended text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 16: MOM attribute definitions table: HLAnextSaveTime

  • Key: DSS2-88
  • Legacy Issue Number: 5197
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 16: MOM attribute definitions table: HLAobjectInstancesUpdated

  • Key: DSS2-89
  • Legacy Issue Number: 5198
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the word “successfully” to the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 16: MOM attribute definitions table: HLAupdatesSent

  • Key: DSS2-85
  • Legacy Issue Number: 5194
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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).

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 16: MOM attribute definitions table: HLAlastSaveTime: undefined

  • Key: DSS2-86
  • Legacy Issue Number: 5195
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 16: MOM attribute definitions table: HLAreflectionsReceived

  • Key: DSS2-84
  • Legacy Issue Number: 5193
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 15: Mom interaction class definitions table: HLAreportObjectInstances

  • Key: DSS2-81
  • Legacy Issue Number: 5190
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the word “successfully” to the table entry.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 16: MOM attribute definitions table: HLAFDDID

  • Key: DSS2-83
  • Legacy Issue Number: 5192
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 15: MOM interaction class definitions table: HLArequestSubscriptions

  • Key: DSS2-80
  • Legacy Issue Number: 5189
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mom interaction class definitions table: HLArequestSynchronizationPointSta

  • Key: DSS2-82
  • Legacy Issue Number: 5191
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add text clarifying the specified case, as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.4.1: Normal RTI MOM administration: federate-sent parameters

  • Key: DSS2-78
  • Legacy Issue Number: 5187
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 6: MOM attribute table: HLAfederateState

  • Key: DSS2-79
  • Legacy Issue Number: 5188
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.4.1: Normal RTI MOM administration: null values

  • Key: DSS2-77
  • Legacy Issue Number: 5186
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.4.1: Normal RTI MOM administration: item (g)

  • Key: DSS2-75
  • Legacy Issue Number: 5184
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • Summary:

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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Change the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.4.1: Normal RTI MOM administration: item (d)

  • Key: DSS2-76
  • Legacy Issue Number: 5185
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 10.31: Get Range Bounds: invalid region

  • Key: DSS2-72
  • Legacy Issue Number: 5181
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested new pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Get Range Bounds: created or conveyed

  • Key: DSS2-73
  • Legacy Issue Number: 5182
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested new pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOM Overview

  • Key: DSS2-74
  • Legacy Issue Number: 5183
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Explain the meaning of “null”, as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 10.30: Get Dimension Handle Set

  • Key: DSS2-71
  • Legacy Issue Number: 5180
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested new pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 10.9: Get Parameter Name

  • Key: DSS2-70
  • Legacy Issue Number: 5179
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • Summary:

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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the “not” as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10.1.2: Advisory Switches

  • Key: DSS2-69
  • Legacy Issue Number: 5178
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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)

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDM Typos: declaration

  • Key: DSS2-67
  • Legacy Issue Number: 5176
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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)…"

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.13: Request Attribute Value Update With Regions

  • Key: DSS2-66
  • Legacy Issue Number: 5175
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the new pre-condition as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.12: Send Interaction With Regions: invalid region

  • Key: DSS2-65
  • Legacy Issue Number: 5174
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested new pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDM Typos: handle

  • Key: DSS2-68
  • Legacy Issue Number: 5177
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • Summary:

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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.11:Unsubscribe Interaction Class With Regions: interaction receip

  • Key: DSS2-61
  • Legacy Issue Number: 5170
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Revise the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.12: Send Interaction With Regions: which parameters are sent

  • Key: DSS2-64
  • Legacy Issue Number: 5173
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Clarify the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.10: Subscribe Interaction Class With Regions: invalid region

  • Key: DSS2-60
  • Legacy Issue Number: 5169
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested new pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.11: Unsubscribe Interaction Class With Regions: invalid region

  • Key: DSS2-63
  • Legacy Issue Number: 5172
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested new pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.11: Unsubscribe Interaction Class With Regions: error

  • Key: DSS2-62
  • Legacy Issue Number: 5171
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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."

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.10: Subscribe Interaction Class With Regions: passive indicator

  • Key: DSS2-59
  • Legacy Issue Number: 5168
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.9: Unsubscribe Object Class Attributes With Regions: invalid regi

  • Key: DSS2-58
  • Legacy Issue Number: 5167
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested new pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.9: Unsubscribe Object Class Attributes With Regions: discover

  • Key: DSS2-57
  • Legacy Issue Number: 5166
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Revise this sentence as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.8: Subscribe Object Class Attributes With Regions: invalid region

  • Key: DSS2-56
  • Legacy Issue Number: 5165
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested new pre-condition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.8: Subscribe Object Class Attributes With Regions: passive indica

  • Key: DSS2-55
  • Legacy Issue Number: 5164
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Register Object Instance With Regions: invalid region

  • Key: DSS2-50
  • Legacy Issue Number: 5159
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.7: Unassociate Regions For Updates: invalid region

  • Key: DSS2-54
  • Legacy Issue Number: 5163
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested new pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.6: Associate Regions For Updates: invalid region

  • Key: DSS2-52
  • Legacy Issue Number: 5161
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.6: Associate Regions For Updates

  • Key: DSS2-51
  • Legacy Issue Number: 5160
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Change the service description as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Register Object Instance With Regions: unique names

  • Key: DSS2-49
  • Legacy Issue Number: 5158
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.7: Unassociate Regions For Updates: irrelevant attributes

  • Key: DSS2-53
  • Legacy Issue Number: 5162
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.1.7: Convey Region Designator Sets Switch: use in support

  • Key: DSS2-46
  • Legacy Issue Number: 5155
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Change the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.3: Commit Region Modifications

  • Key: DSS2-47
  • Legacy Issue Number: 5156
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 9.4: Delete Region

  • Key: DSS2-48
  • Legacy Issue Number: 5157
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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."

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Change the second sentence of the service description as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.1.7: Convey Region Designator Sets Switch: copies conveyed

  • Key: DSS2-45
  • Legacy Issue Number: 5154
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Invalid Region" exceptions

  • Key: DSS2-43
  • Legacy Issue Number: 5152
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.1.2: Default Ranges

  • Key: DSS2-42
  • Legacy Issue Number: 5151
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Clarify the text as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.1.7: Convey Region Designator Sets Switch: when conveyed

  • Key: DSS2-44
  • Legacy Issue Number: 5153
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDM Overview: determining specified dimensions

  • Key: DSS2-39
  • Legacy Issue Number: 5148
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    {Summary of how the issue was proposed to be resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDM Overview: Commit Region Modifications

  • Key: DSS2-40
  • Legacy Issue Number: 5149
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDM Overview: nomenclature

  • Key: DSS2-38
  • Legacy Issue Number: 5147
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Clarify the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDM Overview: Steps to Create a Region Specification

  • Key: DSS2-41
  • Legacy Issue Number: 5150
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 8.12: Flush Queue Request

  • Key: DSS2-37
  • Legacy Issue Number: 5146
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.
  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Delete the suggested portion of the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 16: Temporal State statechart

  • Key: DSS2-36
  • Legacy Issue Number: 5145
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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".

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Change the service names as described.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.9: Attribute Ownership Acquisition If Available: self-transition

  • Key: DSS2-32
  • Legacy Issue Number: 5141
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.10: Attribute Ownership Unavailable

  • Key: DSS2-34
  • Legacy Issue Number: 5143
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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:…"

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.15: Confirm Attribute Ownership Acquisition Cancellation

  • Key: DSS2-35
  • Legacy Issue Number: 5144
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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:…"

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.8: Attribute Ownership Acquisition prohibited

  • Key: DSS2-31
  • Legacy Issue Number: 5140
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.9: Attribute Ownership Acquisition If Available: response not gua

  • Key: DSS2-33
  • Legacy Issue Number: 5142
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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."

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Change the text of the service description as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.8: Attribute Ownership Acquisition invoked twice

  • Key: DSS2-30
  • Legacy Issue Number: 5139
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Clarify the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.7: Attribute Ownership Acquisition Notification

  • Key: DSS2-29
  • Legacy Issue Number: 5138
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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…".

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Change post-condition (b) as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.6: Confirm Divestiture

  • Key: DSS2-28
  • Legacy Issue Number: 5137
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.4: Request Attribute Ownership Assumption

  • Key: DSS2-27
  • Legacy Issue Number: 5136
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested pre-condition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.3: Negotiated Attribute Ownership Divestiture: divesting

  • Key: DSS2-26
  • Legacy Issue Number: 5135
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Change the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 7.3: Negotiated Attribute Ownership Divestiture: finding owners

  • Key: DSS2-25
  • Legacy Issue Number: 5134
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15: New Guard

  • Key: DSS2-23
  • Legacy Issue Number: 5131
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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"].

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.4: User-supplied Tags

  • Key: DSS2-24
  • Legacy Issue Number: 5133
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Clarify the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15: New Self-transition

  • Key: DSS2-22
  • Legacy Issue Number: 5130
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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']".

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested self-transition to Figure 15.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15: New State

  • Key: DSS2-21
  • Legacy Issue Number: 5129
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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".

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15: New Transition

  • Key: DSS2-19
  • Legacy Issue Number: 5127
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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]".

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add the suggested transition to the statechart in Figure 15.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15: Modified Transition Label

  • Key: DSS2-20
  • Legacy Issue Number: 5128
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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)".

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1: Overview of Ownership Management

  • Key: DSS2-18
  • Legacy Issue Number: 5126
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    rejected, see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 6.8: Send Interaction

  • Key: DSS2-16
  • Legacy Issue Number: 5124
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Clarify the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6.1: Object Management Overview

  • Key: DSS2-13
  • Legacy Issue Number: 5121
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 6.10: Delete Object Instance

  • Key: DSS2-17
  • Legacy Issue Number: 5125
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add text that addresses this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 6.4: Register Object Instance

  • Key: DSS2-14
  • Legacy Issue Number: 5122
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add text clarifying the meaning of “the same handle”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 6.5: Discover Object Instance

  • Key: DSS2-15
  • Legacy Issue Number: 5123
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 5.11: Stop Registration For Object Class

  • Key: DSS2-12
  • Legacy Issue Number: 5120
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 5.6: Subscribe Object Class Attributes

  • Key: DSS2-10
  • Legacy Issue Number: 5118
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 5.10: Start Registration For Object Class

  • Key: DSS2-11
  • Legacy Issue Number: 5119
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 5.3: Unpublish Object Class Attributes

  • Key: DSS2-9
  • Legacy Issue Number: 5117
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 5.2: Publish Object Class Attributes

  • Key: DSS2-8
  • Legacy Issue Number: 5116
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.
  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Add clarifying text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 10: Class Attribute (i, j)

  • Key: DSS2-5
  • Legacy Issue Number: 5113
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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,{})".

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 12: Interaction Class (m)

  • Key: DSS2-7
  • Legacy Issue Number: 5115
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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".

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    Modify the statechard labels accordingly.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service 4.24: Query Federation Restore Status

  • Key: DSS2-4
  • Legacy Issue Number: 5112
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 11: Class Attribute (i, HLAprivilegeToDeleteObject)

  • Key: DSS2-6
  • Legacy Issue Number: 5114
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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,{})".

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition 3.1.66: published

  • Key: DSS2-1
  • Legacy Issue Number: 5109
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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."

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 2: Lifetime of a Federate: Meaning of Restore In Progress

  • Key: DSS2-3
  • Legacy Issue Number: 5111
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    The definition of these pre-conditions should be clarified.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 3: Lifetime of a Federate: Meaning of Save In Progress

  • Key: DSS2-2
  • Legacy Issue Number: 5110
  • Status: closed  
  • Source: MITRE ( Susan Symington)
  • 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.

  • Reported: DSS 1.1 — Tue, 9 Apr 2002 04:00 GMT
  • Disposition: Resolved — DSS 2.0
  • Disposition Summary:

    The definition of these pre-conditions should be clarified.

  • Updated: Fri, 6 Mar 2015 20:58 GMT