[scd] Expose manager in Subscription and and SubscriberToNotify

[RustedBones]

Is your feature request related to a problem? Please describe.
The astm-utm CSTM0085 requirement states the following

A USS performing the Constraint Management role shall (CSTM0085) send a notification to the authorized con-
straint provider of each instance where it could not successfully send the details of a constraint to a relevant USS within UnableToDeliverConstraintDetails seconds, 95 % of the time.

When the constraint management updates a constraint, the DSS returns the notifications as SubscriberToNotify with

• list of subscription ids / index
• base url

In 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

• In the Subscription itself (rid Subscription contains owner)
• In the SubscriberToNotify

[mickmis]

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?

[BenjaminPelletier]

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.