Original text:
"Interface Instance or Type": If the application specifies an interface type to be preferred or avoided, implementations should <del> rank paths accordingly.  If the application specifies an interface type to be required or prohibited, we expect an implementation to not include the non-conforming paths into the three. </del>  <del> "Capacity Profile": An implementation may use the Capacity Profile to prefer paths optimized for the application's expected traffic pattern according to cached performance estimates, see </del>  performance-caches: Scavenger: Prefer paths with the highest expected available <del> bandwidth, based on observed maximum throughput </del>  Low Latency/Interactive: Prefer paths with the lowest expected <del> Round Trip Time Constant-Rate Streaming: Prefer paths that can satisfy the requested Stream Send or Stream Receive Bitrate, based on observed maximum throughput Implementations 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. 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 </del>  consistent outcome to applications, e.g., by preferring protocols and <del> paths that existing Connections with similar Properties are already using. </del>  4.2.

Reviewer comments:
Not intended to change meaning, but intended to improve reading, see issue .
Scavenger: This reads wrong to me, this is unutilised capacity /Highest available bandwidth/available capacity/ Why is /satisfy./ used for CR streaming? To me this implies admission-based QoS. Do we really mean this? Or should we say /expected/ here also? /Implementations process properties/ It would really have helped me to read this if we insert /the/ before properties. /As the available protocols and paths on a specific system and in a specific context may vary,/ would seem better as: /The available protocols and paths on a specific system and in a specific context can vary, therefore/ /, by preferring protocols and paths that existing Connections with similar Properties are already using./ should be something like: /, by preferring protocols and paths that are already used by existing Connections that specified similar Properties./
See PR (which includes text polishing).

Revised text:
"Interface Instance or Type": If the application specifies an interface type to be preferred or avoided, implementations should  <ins> accordingly rank the paths.  If the application specifies an interface type to be required or prohibited, an implementation is expeceted to not include the non-conforming paths. </ins>  <ins> "Capacity Profile": An implementation can use the Capacity Profile to prefer paths that match an application's expected traffic pattern.  This match will use cached performance estimates, see </ins> performance-caches: Scavenger: Prefer paths with the highest expected available  <ins> capacity, based on the observed maximum throughput; </ins> Low Latency/Interactive: Prefer paths with the lowest expected  <ins> Round Trip Time, based on observed round trip time estimates; Constant-Rate Streaming: Prefer paths that can are expected to satisy the requested Stream Send or Stream Receive Bitrate, based on the observed maximum throughput. 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. The available protocols and paths on a specific system and in a specific context can change; therefore, the result of sorting and the outcome of racing may vary, even when using the same Selection and Connection Properties.  However, an implementation ought to provide a </ins> consistent outcome to applications, e.g., by preferring protocols and  <ins> paths that are already used by existing Connections that specified similar Properties. </ins> 4.2.