A few questions and some minor language/formatting issues

[garethsb]

Interoperability

Any references to terms and JSON Schemas defined in BCP-004-01 relate to version 1.0.0.

Probably reasonable to mention the version number, but I suggest v1.0 rather than v1.0.0.

http://hostname/x-nmos/...

I suggest e.g. http://api.example.com/x-nmos/... like other parts of the NMOS specs. (example.com is reserved for examples by IANA.)

The Flow Compatibility Management API should be

There are at least two instances of lowercase "should". If they are intended to be conformance key words they SHOULD be in uppercase. :-)

I suggest some more articles in a few places, e.g.

> when set of Inputs/Outputs associated with the Sender/Receiver is changed, or when Status of Sender/Receiver is updated
---
< when the set of Inputs/Outputs associated with the Sender/Receiver is changed, or when the Status of a Sender/Receiver is updated

Data Model: Identity Mapping

Output ID
[...]
SHOULD change if:
[...]
A different upstream counterpart is connected to the same interface

If I've understood correctly, that should be downstream?

Behaviour: Server Side

Non-empty constraint_sets array MUST be treated as unordered unless at least

"Treated" by which actor? The Sender? Or a Controller?

Also, I suggest "of equal preference" rather than "unordered".

Once a Sender accepts proposed Active Constraints, this Sender, the Flow and the Connection API /transportfile resource (if used) associated with this Sender and the Source associated with this Flow MUST satisfy the Active Constraints when the Sender is active.

I'm just checking... does "satisfy the Active Constraints" mean "satisfy at least one of the Constraint Sets in the Active Constraints"? If so, why does it help for the Sender to have multiple Constraint Sets associated with it?

In the section on different states, does the relative precedence of Active Constraints Violation and No Signal need to be indicated?

I think the use of capitalized space-separated strings for enum values may be inconsistent with other NMOS specs. If a human-readable string is required that should be a separate property, such as description.

I suggest lowercase, underscore separated, for example:

"enum": {
  "unconstrained",
  "constrained",
  "active_constraints_violation",
  "no_signal",
  "awaiting_signal"
}

Behaviour: Client Side

If multiple Receivers have equal Constraint Sets, NMOS Controller MUST take only one of them. If they differ only in urn:x-nmos:cap:meta:preference, then one with the highest priority MUST be taken.

What does it mean for the Controller to "take" a constraint set?

[N-Nagorny]

The most of the questions/suggestions makes sense to me so I tried to apply them in #89.

Non-empty constraint_sets array MUST be treated as unordered unless at least

I checked https://specs.amwa.tv/bcp-004-01/releases/v1.0.0/APIs/schemas/with-refs/constraint_set.html and recalled that preference has default value set to zero. Do we need this paragraph at all?

I'm just checking... does "satisfy the Active Constraints" mean "satisfy at least one of the Constraint Sets in the Active Constraints"? If so, why does it help for the Sender to have multiple Constraint Sets associated with it?

Right. It helps to configure an Input and determine whether Source, Flow and transport file, which properties may change at any moment, satisfy Active Constraints.

In the section on different states, does the relative precedence of Active Constraints Violation and No Signal need to be indicated?

What do you mean? active_constraints_violation means there is signal from an Input, but it can't be streamed due to the violation.

[garethsb]

What do you mean? active_constraints_violation means there is signal from an Input, but it can't be streamed due to the violation.

Ah, I see, OK.