Change:
5.2.9. <del> This enumerated property specifies which kind of access network interface, e.g., WiFi, Ethernet, or LTE, to prefer over others for this Connection, in case they are available.  In general, Interface Types should be used only with the "Prefer" and "Prohibit" preference level.  Specifically, using the "Require" preference level for Interface Type may limit path selection in a way that is detrimental to connectivity.  The default is to use the default interface configured in the system policy. </del> <ins> Type: Tuple (Enumeration, Preference) This property specifies which kind of access network interface, e.g., WiFi, Ethernet, or LTE, to prefer over others for this Connection, in case they are available.  In general, Interface Types should be used only with the "Prefer" and "Prohibit" preference level. Specifically, using the "Require" preference level for Interface Type may limit path selection in a way that is detrimental to connectivity.  The default is to use the default interface configured in the system policy.  The valid values for the access network interface kinds are implementation specific. </ins> 5.2.10. <del> This enumerated property specifies the application's expectation of the dominating traffic pattern for this Connection.  The Capacity Profile should only be used with the "Prefer" preference level; other preference levels make no sense for profiles.  The following values are valid for Capacity Profile: </del> <ins> Type: Enumeration This property specifies the application's expectation of the dominating traffic pattern for this Connection.  This implies that the transport system should optimize for the capacity profile specified.  This can influence path and protocol selection.  The following values are valid for Capacity Profile: </ins> The application makes no representation about its expected capacity profile.  No special optimizations of the tradeoff

Discussion:
This commit fixes bug by making transport parameter types explicit. It also fixes Path- and Protocol Selection Properties from "binary + preference" to preferences type. With the old boolean properties, one could do things like "prohibit Reliable Transport false" - is that the same as "prefer Reliable Transport true"?
To the questions in NAME review summary: For the general case: I believe there will be boolean properties (that are not preferences). The way I understand "Excessive Retransmit Notifications" and "ICMP soft error message", I think booleans are the more appropriate type. Not for -00, but for -01: I want to define all types more rigorously in -01 --- we have Boolean, Enumeration, Boolean in the Transport Parameters right now, we also have some Integers in the Send Parameters. I am not sure that the frontmatter of this section is the right place to do so.
General clarification: This pull request changed "preference" to a data type a value can have rather than being something weakly defined that can be specified along with every Transport Parameter. So we go from a Key / Preference / Value tripel where Preference or Value is pointless for (n-1) cases to a Key / Value pair with typed values. The only Transport Parameter (including the Intents in the Appendix) that uses a parameter and a preference is the "Interface Type". I would like to land this for -00 as this is good enough for discussion while the old state is confusing. ToDos for -01: Explain types clearly make "Interface Type" easier in -01 discuss extendability
If we're doing booleans, the document needs to define a concise and generally applicable rule for how booleans interact with preferences. ISTM that boolean True == preference Prefer and boolean False == preference Avoid (in which case, why not just say Prefer and Avoid instead of True and False?) I might be wrong here though. Will defer to NAME
also NAME Please file everything in the comments on this PR that should be addressed in -01 as an issue (if you haven't already)... thanks!
Ok - now I got your point. These properties (Notification of excessive retransmissions and Notification of ICMP soft error message arrival) are actually doing two things: Enable sending these events Indicate that we prefer protocols stacks that can send these events The question is which one is more important.

As I think the former is more important, I leave it boolean an add remarks to the individual properties that this implies preferring protocols that can provide these events for now. As this does not hide things, this should provide the better feedback for -00
This should be ready for landing. – NAME please merge if you agree Open Issues for Milestone itef-01: Restructure Transport Parameters Section Explain data types explicitly Rewrite Interface Types to be useful and implementable
Transport and Send Parameter have different data types. These types are used in the document in a more or less intuitive way but are never defined explicitly. May need a new section next to the pseudocode definition.
This has been addressed in PR
This is a fork of Issue – The part of it that does not need discussion. Annotate "data type" for each Transport Parameter Change "boolean" Protocol and Path Selection Parameters to type "Preference" Remove editing artifacts
still not convinced by the boolean argument, but it's time to ship it.