Benjamin Pelletier

There may be many Subscriptions with the same callback URL, but that callback URL only needs to be invoked once. [The SubscriberToNotify structure](https://github.com/astm-utm/Protocol/blob/cb7cf962d3a0c01b5ab12502f5f54789624977bf/utm.yaml#L382) contains a list of Subscriptions that are...

An intermediate step could be to document all the places where the database version should be changed when it is incremented in development.

Starting a deployment changelog seems like a good idea, especially for the changes we have coming up. kacl seems abandoned though, and we may not need automated enforcement. If we...

> The request will contain the entire operation data, including an end_time in the past, which will illicit a 400 "OperationalIntents may not end in the past" response from DSS....

> it sounds like in Step 3 above, if there are appropriate off-nominal volumes included in that update (encompassing the non-conforming behavior of flying around after the end time of...

A list of places the database version needs to be updated may be found in [build/deploy/db_schemas/README.md](https://github.com/interuss/dss/blob/master/build/deploy/db_schemas/README.md).

I just noticed that the allOf workaround causes types to no longer be displayed in parentheses in ReDoc -- e.g., if I have ``` FooOperationURL: description: Endpoint that provides the...

Additional note: using `anyOf` instead of `allOf` causes ReDoc to generate documentation that is closer to correct, so I'm using that workaround currently. I think it would be nice for...

> When we have a few 'Contingent' Operational Intents that update each time the UAV changes position The general expectation is that off-nominal volumes should be added to encompass the...

Certainly I agree this race condition can occur with operational intents of many different states, and I agree it is a real world scenario. The term "tactical" I'm using here...