Repository navigation
[scd] Expose manager in Subscription and and SubscriberToNotify #1611
Description
Activity
Given that the API in question is the one defined by the standard, and used and implemented independently by USSs, we cannot freely change it. It has happened a few times in quite specific cases (obvious error, additional opt-in feature, but in any case always retro-compatible).
In this case, I don't think an API change is warranted. It is inconvenient sure, but IMO not worth changing the API.
Is this something important on your side?The ASTM standard APIs generally allow for the prototyping of new fields by ensuring backwards compatibility via specifying that unknown fields must be ignored, so hypothetically I think we could add the information of which manager is responsible for each subscription. However, I don't think this information is necessary to meet the requirement. The DSS has said that each SubscriberToNotify is a relevant USS. The client USS is therefore responsible to send the details of the constraint to those subscribers and, per CSTM0085 (and a similar requirement on the SCD side), to send a notification to the authorized constraint provider the client USS is serving when the client USS is unable to send those details to all the relevant USSs successfully. There is no requirement to provide or resolve the identity of each (or any) relevant USS.
The intended user journey is that someone doing special things in the airspace (and therefore authorized to provide constraints) creates a constraint, and this automatically triggers dissemination of the constraint to all relevant USSs (which flow this information down to their operators). So, the constraint provider can be fairly confident relevant operators know about the constraint normally. CSTM0085 ensures that the constraint provider is told when the situation isn't normal -- basically, they'll probably see a message like "Some relevant operators could not be informed of this constraint". How to recover/proceed in that case depends on the nature of the constraint and regulatory regime and is beyond the scope of the standard, but for instance one action could be to proceed with caution knowing that the normal coordination hadn't been successfully achieved. If the identity of the USS managing each subscription were known, hypothetically the constraint-providing USS could follow up with that USS to find out why the notification didn't go through and perhaps notify the operator via some other means. But, the standard doesn't provide enough information to make that workflow effective. For instance, just knowing the USS identity doesn't provide any means to contact that USS. And, if the receiving USS is broken, the problem is unlikely to be resolved tactically in any case. Since the odds of tactical resolution are low, the important piece of information from the perspective of the constraint manager is just that some operator doesn't have the constraint details, not which one doesn't have it.
I would additionally hesitate to add this information to the response because it reveals more information than would normally be available, which has the potential for privacy impacts to operators, users, and/or company trade secrets. It may be the case that this isn't actually a problem in this case (I'm personally not thinking of any reason revealing the managing USS identity would be problematic), but downstream implications are sometimes hard to fully enumerate and I don't think we would want to move ahead of standards-making bodies unless there were a compelling reason.
Reacted by Mickaël MisbachThat makes totally sense in withing the scope of the UTM standard.
The idea behing this feature request was to leverage the identity of notified USSP in the context of a DAR (Dynamic Airspace Reconfiguration) where ATC unit restict uspace access to avoid proximity between manned and unmanned aircraft.The ATC unit would be able to initiate a DAR by publishing a constraint with a specific DAR type (as specified in ED-318 geozones). USSPs are instructed to notify the ATC unit once the restricted portion of the U-space airspace is clear of UAS traffic.
If the identity of the USSP is given back to the constraint provider (in this case, the ATC unit), it would help with:
- directly identify USSP affected by the DAR.
- have the identity to validate USSP notifications of airspace vacated
Without the USSP identity, the ATC unit would have to either map the urls to USSPs to build the list of potentially impacted USSPs or get this information by other means.
Is your feature request related to a problem? Please describe.
The astm-utm CSTM0085 requirement states the following
When the constraint management updates a constraint, the DSS returns the notifications as
SubscriberToNotifywithIn case of USS notification failure, the constraint management can only report calls to base urls that fail to the provider. Identifying 'relevant USS' from the base URL is not ideal.
Describe the solution you'd like
The subscription's manager should be added
owner)