Original text:
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 <del> protocols. </del>  In the following cases, failure should be detected during pre- establishment: section is the algorithm defining which of these options to try, when, and in what order. <del> 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. </del>  4.1. highest available capacity, based on the observed maximum throughput. <del> 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. </del>  The available protocols and paths on a specific system and in a specific context can change; therefore, the result of sorting and the

Reviewer comments:
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:

Revised text:
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  <ins> protocols (see Section 6.2 of I-D.ietf-taps-interface for the definition of property preferences). </ins> In the following cases, failure should be detected during pre- establishment: section is the algorithm defining which of these options to try, when, and in what order.  <ins> 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. </ins> 4.1. highest available capacity, based on the observed maximum throughput.  <ins> 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. </ins> The available protocols and paths on a specific system and in a specific context can change; therefore, the result of sorting and the