Draft: draft-ietf-taps-interface

Commentary: Implements 
 tagging discuss since and I , at least , apparently have a fairly fundamental disagreement on flexibility versus classification of layers 2 . 
 - I do n'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 that we 're not going to achieve full portability across systems for interfaces and PvDs , and it likely does n'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 do n't have any devices for ? Since moving between different implementations is n'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 
 please take a look at the update ! 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
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
Path Properties of the path(s) in use, once the Connection has
been established.  These properties can be derived from the local
provisioning domain, measurements by the Protocol Stack, or other
sources.  They can only be queried.
Paragraph (version B):
Path Properties of the path(s) in use, once the Connection has
been established.  These properties can be derived from the local
provisioning domain RFC7556, measurements by the Protocol Stack,
or other sources.  They can only be queried.