Change:
Type: Tuple (Enumeration, Preference) <del> 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. </del> <ins> This property allows the application to select which specific network interfaces or categories of interfaces it wants to "Require", "Prohibit", "Prefer", or "Avoid". If a system supports discovery of specific interface identifiers, such as "en0" or "eth0" on Unix-style systems, an implemention should allow using these identifiers to define path preferences.  Note that marking a specific interface as "Required" strictly limits path selection to a single interface, and leads to less flexible and resilient connection establishment. The set of valid interface types is implementation- and system- specific.  For example, on a mobile device, there may be "Wi-Fi" and "Cellular" interface types available; whereas on a desktop computer, there may be "Wi-Fi" and "Wired Ethernet" interface types available. Implementations should provide all types that are supported on some system to all systems, in order to allow applications to write generic code.  For example, if a single implementation is used on both mobile devices and desktop devices, it should define the "Cellular" interface type for both systems, since an application may want to always "Prohibit Cellular".  Note that marking a specific interface type as "Required" limits path selection to a small set of interfaces, and leads to less flexible and resilient connection establishment. The set of interface types is expected to change over time as new access technologies become available. Interface types should not be treated as a proxy for properties of interfaces such as metered or unmetered network access.  If an application needs to prohibit metered interfaces, this should be specified via Provisioning Domain attributes prop-pvd or another specific property. </ins> 5.2.10. <ins> Type: Tuple (Enumeration, Preference) Similar to interface instances and types prop-interface, this property allows the application to control path selection by selecting which specific Provisioning Domains or categories of Provisioning Domains it wants to "Require", "Prohibit", "Prefer", or "Avoid".  Provisioning Domains define consistent sets of network properties that may be more specific than network interfaces RFC7556. The indentification of a specific Provisioning Domain (PvD) is defined to be implementation- and system-specific, since there is not a portable standard format for a PvD identitfier.  For example, this identifier may be a string name or an integer.  As with requiring specific interfaces, requiring a specific PvD strictly limits path selection. Categories or types of PvDs are also defined to be implementation- and system-specific.  These may be useful to identify a service that is provided by a PvD.  For example, if an application wants to use a PvD that provides a Voice-Over-IP service on a Cellular network, it can use the relevant PvD type to require some PvD that provides this service, without needing to look up a particular instance.  While this does restrict path selection, it is more broad than requiring specific PvD instances or interface instances, and should be preferred over those options. 5.2.11. </ins> Type: Enumeration This property specifies the application's expectation of the

Discussion:
Implements
tagging discuss since NAME and I, at least, apparently have a fairly fundamental disagreement on flexibility versus classification of layers 2.
NAME - I don't think I'll fight for this one, but to begin with, tell me: what do you think is wrong about my view?
Thanks for the hearty discussion! On this point, I do agree with NAME that we're not going to achieve full portability across systems for interfaces and PvDs, and it likely doesn't need to be a goal. If I'm writing an implementation in ten years for some new system that only uses Wi-Fi and [INSERT FANCY NEW RADIO TYPE HERE], why would I need to add support for this wired ethernet thing that I don't have any devices for? Since moving between different implementations isn't likely going to be 100% portable anyhow due to language differences and symbol differences, applications will need to change. However, a specific implementation that is portable (like NEAT, or like Apple's if we make it cross-platform) should endeavor to offer the same types across systems.
Fine by me, go ahead
NAME NAME please take a look at the update! NAME I assume based on your last comment that you're okay with the change going in now?
Yes, I agree with it!
let's land this one then...
Works for me now. Sorry for the delay!in my opinion, almost there… only minor comments to address left