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: Several small updates, mostly to clean things up a bit, and align property names and such.
NAME - I think you're wrong: my understanding (and also the way the text is written - otherwise we'd have to change it in the API draft) was that Connection Properties can (and should) also be set on Preconnections, to give as much input as possible for Connection establishment. In the API draft, the Selection Properties in Section 5.2 can only be used on Preconnections: you can't ask for congestion control after establishment. You can't say that you'd rather have multistreaming support after establishment. But that doesn't exclude Connection properties from being usable earlier. Required minimum checksum coverage could influence choosing UDP-Lite vs. UDP. Bounds on Send or Receive Rate could influence the interface choice. The capacity profile could influence various things (and no, there isn't a matching Selection Property now - there is a per-Message override). So... I think that either you're wrong, or I'm missing something and the API draft heavily lags behind a decision that was made. I hope not!
NAME The API drafts says: I interpret this as only the Selection Properties influence selection and the Connection properties are used to further configure the connections according to user preferences. Otherwise what is the difference between them?
If you interpret it as you do, I think the text isn't clear enough (indeed it isn't super clear - in particular, "eventually established" is misleading IMO). Though, note that it says that Connection properties can also be used later. Regarding the difference between them: Selection Properties only make sense for Preconnections.
NAME - sorry lost this thread. But I saw that you have started cleaning up some Connection properties that had mixed Connection and Selection properties up in the API draft. Does it mean that we are now in synch and agree that only Selection properties are used in the selection and Connection properties are used for configuration (both during establisment and also after the connection setup).
NAME the other PR means nothing about what I said here: it only tried to address issue which is about a wording inconsistency in a specific property. You say that Connection properties can also be used during establishment - if you agree with allowing this, then why not allow to configure them as early as possible and allow them to influence selection?