Draft: draft-ietf-taps-interface

Commentary: In the " Specifying Endpoints " section , a reference to the Selection Property that does a similar thing but with more fine - grained control . It was n't clear to me what is the best place to add this , so I put it right below the first example of specifying an interface name for the Local Endpoint to say that you can also do it differently . If you have better suggestions , please let me know . To the ListenError and RendezvousError , I text mentioning the " reconcile Endpoints and Properties " pitfall . I think this is probably more general , i.e. , there might be more sources of errors than just local interface , so I kept it generic . 
 For Local Address Preference we only have the option to prefer stable or temporary . However , I guess we would also need a way to e.g. specify that stable is required , no ? 
 Is this addressed by PR ? 
 I do n't think so . 
 When reading the current API draft , I was wondering the following : If an application wants to specify one or multiple local network interfaces , it can either set the Local Endpoint(s ) or it can set the " Interface Instance or Type " Selection Property . I think both ways are valid and should exist , but I 'm wondering if we should specify anything on the interaction of these two ways to do a similar thing . For example , should we explicitly mention the Selection Property in Section 5.1 ( " Specifying Endpoints " ) , to make readers aware that there is a " better " way to do this , which allows more flexibility ? Also , if an application specifies conflicting things , I guess this leads to an InitiateError , ListenError , or RendezvousError . Our current text already says this for the InitiateError : But should we make this particular issue more explicit here and/or should we add it for the ListenError or RendezvousError ? 
 I think so , yes ! Regarding the error in case of a conflict : I think so , yes - to all your questions : make it more explicit , state it in the description of both the ListenError and RendezvousError . Just my 2 cents 
 Thank you - works for me !
Paragraph (version B):
As an alternative to specifying an interface name for the Local
Endpoint, an application can express more fine-grained preferences
using the "Interface Instance or Type" Selection Property, see prop-
interface.  However, if the application specifies Selection
Properties which are inconsistent with the Local Endpoint, this will
result in an error once the application attempts to open a
Connection.
Paragraph (version A):
A ListenError occurs either when the Properties of the Preconnection
cannot be fulfilled for listening, when the Local Endpoint (or Remote
Endpoint, if specified) cannot be resolved, or when the application
is prohibited from listening by policy.
Paragraph (version B):
A ListenError occurs either when the Properties and Security
Parameters of the Preconnection cannot be fulfilled for listening or
cannot be reconciled with the Local Endpoint (and/or Remote Endpoint,
if specified), when the Local Endpoint (or Remote Endpoint, if
specified) cannot be resolved, or when the application is prohibited
from listening by policy.
Paragraph (version A):
An RendezvousError occurs either when the Preconnection cannot be
fulfilled for listening, when the Local Endpoint or Remote Endpoint
cannot be resolved, when no transport-layer connection can be
established to the Remote Endpoint, or when the application is
prohibited from rendezvous by policy.
Paragraph (version B):
An RendezvousError occurs either when the Properties and Security
Parameters of the Preconnection cannot be fulfilled for rendezvous or
cannot be reconciled with the Local and/or Remote Endpoints, when the
Local Endpoint or Remote Endpoint cannot be resolved, when no
transport-layer connection can be established to the Remote Endpoint,
or when the application is prohibited from rendezvous by policy.