Unclear how NETN-ORG attribute updates should be handled by subscribers

[bergtwvd]

Beyond the existence of the object, how should NETN-ORG attribute updates be handled?

1. If the Superior ID changes, is that an implicit order to task reorganize?
2. If the Force ID changes, is that an implicit order to move the asset to a new force?
3. If the Federate name changes, is that an implicit order to transfer control to another simulation?
4. If the location changes, is that an implicit order to perform a magic move of the entity?
5. If the logistics changes, is that an implicit order to change log values?
6. Does the ORBAT server use the MRM interactions to Divide/Merge/Aggregate/Disaggregate or does it make those requests using attribute updates on the NETN-ORG objects?

This is related to how the subscriber should "Latch" onto the data and how to interpret changes in those objects. See #63.

Should the NETN-ORG publisher dynamically interact with the given simulation scenario, retask units, activate/deactivate, split/merge OR is that a capability elsewhere? Or is the publication of NETN-ORG data intended as simple scenario injector/snapshot.

One complication does arise if the SIMs do task reorganize due to game play. Those new NETN-Aggregates might not be seen in the NETN-ORG object list and now it ambiguous as to what it means. Should the new Aggregate be deleted OR is this a natural evolution of the SIMs and the ORBAT server will snapshot the NETN-MRM objects? Or is action only taken when an object delete occurs?

In any case, NETN-ORG should be supplemented with a "concept of operations".