Draft: draft-ietf-taps-interface

Commentary: In the , people found the normative language in too restrictive and agreed with the original suggestion in . Therefore , this PR moves the selection algorithm text to the implementation draft and removes some normative language in the interface draft . We still want to provide consistency to applications when possible , so there 's a sentence in the implementation draft on this now as well . 
 LGTM modulo the suggestion from which I would accept as - is Great with one minor knit .
Paragraph (version A):
The implementation MUST ensure a consistent outcome given the same
Selection Properties.  Internally, it MUST exclude all protocols and
paths that match a Prohibit and exclude all protocols and paths that
do not match a Require.  It MUST then sort candidates according to
Preferred properties, and then use Avoided properties as a
tiebreaker.
Paragraph (version A):
Note that the protocols and paths which are available on a specific
system may vary, such that application preferences may conflict with
each other.  For example, if an application indicates a preference
for a specific path by specifying an interface, but also a preference
for a protocol, a situation might occur in which the preferred
protocol is not available on the preferred path.  In such cases,
implementations MUST ensure a deterministic outcome by prioritizing
Selection Properties that select paths over those that select
protocols.  Therefore, the transport system MUST try the path first,
ignoring the protocol preference if the protocol does not work on the
path.
Paragraph (version B):
The implementation MUST ensure an outcome that is consistent with
application requirements as expressed using Require and Prohibit.
While preferences expressed using Prefer and Avoid influence protocol
and path selection as well, outcomes may vary given the same
Selection Properties, as the available protocols and paths may vary
across systems and contexts.  However, implementations are
RECOMMENDED to aim to provide a consistent outcome to an application,
given the same Selection Properties.
Paragraph (version B):
Note that application preferences may conflict with each other.  For
example, if an application indicates a preference for a specific path
by specifying an interface, but also a preference for a protocol, a
situation might occur in which the preferred protocol is not
available on the preferred path.  In such cases, implementations
SHOULD prioritize Selection Properties that select paths over those
that select protocols.  Therefore, the transport system SHOULD race
the path first, ignoring the protocol preference if the protocol does
not work on the path.
Paragraph (version B):
During Candidate Gathering, an implementation first excludes all
protocols and paths that match a Prohibit or do not match all Require
properties.  Then, the implementation will sort branches according to
Preferred properties, Avoided properties, and possibly other
criteria.
Paragraph (version A):
Implementations should process properties in the following order:
Prohibit, Require, Prefer, Avoid.  If Selection Properties contain
any prohibited properties, the implementation should first purge
branches containing nodes with these properties.  For required
properties, it should only keep branches that satisfy these
requirements.  Finally, it should order branches according to
preferred properties, and finally use avoided properties as a
tiebreaker.
Paragraph (version B):
Implementations should process properties in the following order:
Prohibit, Require, Prefer, Avoid.  If Selection Properties contain
any prohibited properties, the implementation should first purge
branches containing nodes with these properties.  For required
properties, it should only keep branches that satisfy these
requirements.  Finally, it should order branches according to
preferred properties, and finally use avoided properties as a
tiebreaker.  When ordering branches, an implementation may give more
weight to properties that the application has explicitly set than to
properties that are default.
Paragraph (version B):
As the available protocols and paths on a specific system and in a
specific context may vary, the result of sorting and the outcome of
racing may vary even given the same Selection and Connection
Properties.  However, an implementation ought to aim to provide a
consistent outcome to applications, e.g., by preferring protocols and
paths that existing Connections with similar Properties are already
using.