Draft: draft-ietf-taps-impl

Commentary: Quoting from the end of the Section 4 overview , the earliest point in the Implementation Draft where Preference Levels are explicitly mentioned : While the capitalization of " Prohibit " and " Require " does somewhat help to indicate their role as a special term , the sentence does not scan particularly well to any reader that is yet unfamiliar with the notion of Preference Levels from the API draft . At the very least it would help to better contextualize the sentence . Suggestion 1 : It could also help to not explicitly refer to any Preference Levels yet . Suggestion 2 : This could be sufficient for the Section 4 overview , since Section 4.1.3 " Sorting Branches " later goes into more detail about the different properties and their handling , even if the wording is a bit terse :
Paragraph (version A):
The Transport Services system should have a list of supported
protocols available, which each have transport features reflecting
the capabilities of the protocol.  Once an application specifies its
Transport Properties, the transport system matches the required and
prohibited properties against the transport features of the available
protocols.
Paragraph (version B):
The Transport Services system should have a list of supported
protocols available, which each have transport features reflecting
the capabilities of the protocol.  Once an application specifies its
Transport Properties, the transport system matches the required and
prohibited properties against the transport features of the available
protocols (see Section 6.2 of I-D.ietf-taps-interface for the
definition of property preferences).
Paragraph (version A):
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 B):
During Candidate Gathering, an implementation prunes and sorts
branches according to the Selection Property preferences (Section 6.2
of I-D.ietf-taps-interface.  It first excludes all protocols and
paths that match a Prohibit property or do not match all Require
properties.  Then it will sort branches according to Preferred
properties, Avoided properties, and possibly other criteria.
Paragraph (version A):
Implementations process the 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 the branches according to the
preferred properties, and finally use any avoided properties as a
tiebreaker.  When ordering branches, an implementation can give more
weight to properties that the application has explicitly set, than to
the properties that are default.
Paragraph (version B):
Implementations process the Properties (Section 6.2 of I-D.ietf-taps-
interface) 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
the branches according to the preferred properties, and finally use
any avoided properties as a tiebreaker.  When ordering branches, an
implementation can give more weight to properties that the
application has explicitly set, than to the properties that are
default.