Open issmith1 opened 5 years ago
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.
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.
Better title for this is "should USS-API offer POST Operation?"
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:
case2:
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:
Should USS Spec add date-time validation for ContingencyPlan?