grumpyoldtroll / ietf-taps-yang Goto Github PK

Maybe the model should include constraints or negative tests.
Specifically, a model instance should always include at least one endpoint, either local or remote.

Maybe the model should include transport property profiles, see Appendix of API draft (hopefully in -05).

We probably want a model for the actual connection candidates that the transport system creates.
We already have a portable input (model of the Preconnection and endpoints) -- this way we could also have a portable output, and then a portable test suite could compare whether a specific input leads to a similar output on multiple TAPS implementations.

As a first step, this model could include the Endpoint, Interface, and Protocol, see Section 4 of the Implementation draft.

Maybe it would be helpful to model which protocol offers which transport feature.
Then, the validation could check if the instance includes an "impossible" combination of transport properties, which no current transport protocol offers. An example might be the combination of "Reliability: Prohibit" and "Preservation of data ordering: Require".