Code change:
with higher rankings represent connection attempts that will be raced first.  Implementations should order the branches to reflect the preferences expressed by the application for its new connection, <del> including Protocol and Path Selection Properties, which are specified in I-D.ietf-taps-interface. </del> <ins> including Selection Properties, which are specified in I-D.ietf-taps- interface. </ins> In addition to the properties provided by the application, an implementation may include additional criteria such as cached performance estimates, see performance-caches, or system policy, see <del> role-of-system-policy, in the ranking.  Two examples of how the Protocol and Path Selection Properties may be used to sort branches are provided below: </del> <ins> role-of-system-policy, in the ranking.  Two examples of how Selection and Connection Properties may be used to sort branches are provided below: </ins> <del> Interface Type: If the application specifies an interface type to be preferred or avoided, implementations should 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> <ins> "Interface Instance or Type": If the application specifies an interface type to be preferred or avoided, implementations should 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. </ins> <del> Capacity Profile: An implementation may use the Capacity Profile </del> <ins> "Capacity Profile": An implementation may use the Capacity Profile </ins> to prefer paths optimized for the application's expected traffic pattern according to cached performance estimates, see performance-caches: <del> Interactive/Low Latency: Prefer paths with the lowest expected Round Trip Time Constant Rate: Prefer paths that can satisfy the requested Stream Send or Stream Receive Bitrate, based on observed maximum throughput </del> <ins> Scavenger: Prefer paths with the highest expected available bandwidth, based on observed maximum throughput </ins> <del> Scavenger/Bulk: Prefer paths with the highest expected available bandwidth, based on observed maximum throughput </del> <ins> Low Latency/Interactive: Prefer paths with the lowest expected Round Trip Time </ins> <del> [Note: See branch-sorting-non-consensus for additional examples related to Properties under discussion.] </del> <ins> Constant-Rate Streaming: Prefer paths that can satisfy the requested Stream Send or Stream Receive Bitrate, based on observed maximum throughput </ins> Implementations should process properties in the following order: <del> Prohibit, Require, Prefer, Avoid.  If Protocol or Path 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 </del> <ins> 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 </ins> preferred properties, and finally use avoided properties as a tiebreaker. <del> For Require and Avoid, Path Selection Properties take precedence over Protocol Selection Properties.  For example, if the application has indicated both a preference for WiFi over LTE and for a feature only available in SCTP, branches will be first sorted accord to the Path Selection Property, with WiFi at the top.  Then, branches with SCTP will be sorted to the top within their subtree according to the Protocol Selection Property.  However, if the implementation has cached the information that SCTP is not available on the path over WiFi, there is no SCTP node in the WiFi subtree.  Here, the path over WiFi will be tried first, and, if connection establishment succeeds, TCP will be used.  So the Path Selection Property of preferring WiFi takes precedence over the Protocol Selection Property of preferring SCTP. </del> 4.4. The primary goal of the Candidate Racing process is to successfully

Related discussion:
text: What's bad about having more information available that can guide the selection process?
NAME the problem is that the Connection properties are not expressed in a way suitable for selection. If they should also be used for Selection they would have to be reworked to be of type Preference. Otherwise I do not know what they mean for selection. What does it mean if I pick say a particular connection group transmission scheduler? Is it required or preferred? Most connection properties also do not look very useful to me for selection so in case there are some we need I think it would be simpler to just define a matching selection property.
NAME we're only discussing whether it's allowed to use them as additional input or not. I agree, some (like the scheduler choice) don't seem useful, but some do... generally we may not have good guidance on how they should be used by an implementation, but giving the system freedom to use as many inputs as possible is probably a good thing. Regarding the type, require/prefer//ignore/avoid/prohibit obviously works fine for a "wishlist" of boolean character: having something, or not having it. The selection properties are generally like that - except "Interface Instance or Type" and "Provisioning Domain Instance or Type" which are, well... wishlist-collections. Consider the capacity profile. Surely configuring this early can be useful input - e.g. if someone picks low latency / interactive, you may even want to put this traffic on a specific network interface! But if you'd want to make a copy of the capacity profile as a "proper" selection property, how would you do it? Apply require/prefer/ignore/avoid/prohibit for each of its values? Then I could say "prefer" low latency/non-interactive but "avoid" low latency/non-interactive, which would surely be odd. Apply the qualifier to the whole thing? Then it's about, e.g. "avoiding" to use a capacity profile at all. That's odd as well. I think it's in the nature of the current selection properties that they merely say "I want to be able to do this, and this is how important it is to me", which is different from configuring something. That's also why, as written, they simply wouldn't work for later connection configuration.