clarify USS Spec 'for date-time in the past' validation

[issmith1]

NASA is dropping USS date-time-past requirement from the tcl4 participation requirement.
which is

"For an update to an Operation, date-time fields that are in the past MUST NOT be modified."
https://github.com/nasa/utm-apis/blob/v4-draft/uss-api/swagger.yaml#L598

case1:
1. USS-under-test is in grid and successfully announced to USSb.
2. USSut's Op has 3 volumes. USSut is now Active in opvol[1] such that opvol[1].begin time is in the past.
3. USSut does OpMod state change from Active to and does PUT Op to USSb with http-request Operation mutating only the Op.state property.
4. USSb's validator infers this is OpMod. USSb calculates now() time and rejects USSb's opmod
due to opvol[1].begintime is in the past.

case2:
1. USSut is the grid and announced to USSb who is in its LUN. However, this data exchange never got to USSb.
2. same
3. same
4. USSb's validator infers this is a new Op, so skips the date validation.

In case1, USSut's validator could do property-to-property matching of the previous Op to the current and conclude that only Op.state is mutating, and thus skip the datetime check.

Should the spec be modified to include New Op also? If not, then we have lost coverage for Case3:

1. USS-under-test is announcing new Op to USSb. USSut's data has opvol[0] begin_time and endtime in the past.
2. USSb accepts this data.

Should USS Spec add date-time validation for ContingencyPlan?

[issmith1]

Note that, in any case, an announcing USS would never set opVol.begin to exactly now(), rather, it would offset opVol.begin into the future to cover data exchange latency.

See USS Specification section 13.3 for overview of OpMod during Contingencies.

[issmith1]

Joey (UTM Chief Engineer) Today at 7:33 AM
@here Note that we saw issues in NV with USSs submitting Operation plan updates within the USS Network, but neglecting to refresh the update_time field. This was a lesson learned sent to the TX team. We will be actively monitoring this issue and pinging offending USSs to get that fixed.

2 replies

Joey (UTM Chief Engineer) 27 minutes ago
@rao @Priya Venkatesan if you see issues with this, please call them out in this channel and then with the individual USSs.

irene - NASA < 1 minute ago
Note that the written USS Spec for OpMod begin-time validation has open issue gh 158. This validation was dropped for TCL4 Event requirement.
The validation is complex due to catch-22 ordering of the check. Since USS-API offers only PUT and not both PUT and POST, the timestamps are used to infer whether the client's intent is 'new' vs 'opMod'. However for clean implementation the inference check and the timestamp validation checks both need to be done first.

[issmith1]

Better title for this is "should USS-API offer POST Operation?"