Draft: draft-ietf-taps-interface

Commentary: According to : As a small change to  's second proposal , this uses : " The design of the API MUST NOT permit an Endpoint to be configured with multiple identifiers of the same type . " instead of : " The design of the API MUST NOT permit an Endpoint to set multiple identifiers of the same type . " because it 's not the Endpoint itself that is actually doing anything . 
 looks fine to me
Mailing list commentary: I ' m unsure that I precisely understand the diference between /rely upon/ and /depend upon/ , in this sentence I 'd be happy either with either word " rely " would be fine for me . I think ( if I understand your argument ) that you say a design will prevent this because that is how we define Endpoint . I 'd agree a design of system can not allow this , but then thenis it any better to state the design requirement as " The design of the API MUST NOT permit an Endpoint to set multiple identifiers of the same type . "
Paragraph (version A):
An Endpoint MUST NOT be configured with multiple identifiers of the
same type.  For example, an endpoint cannot have two IP addresses
specified.  Two separate IP addresses are represented as two Endpoint
Objects.  If a Preconnection specifies a Remote Endpoint with a
specific IP address set, it will only establish Connections to that
IP address.  If, on the other hand, the Remote Endpoint specifies a
hostname but no addresses, the Connection can perform name resolution
and attempt using any address derived from the original hostname of
the Remote Endpoint.  Note that multiple Remote Endpoints can be
added to a Preconnection, as discussed in add-endpoints.
Paragraph (version B):
The design of the API MUST NOT permit an Endpoint to be configured
with multiple identifiers of the same type.  For example, an endpoint
cannot have two IP addresses specified.  Two separate IP addresses
are represented as two Endpoint Objects.  If a Preconnection
specifies a Remote Endpoint with a specific IP address set, it will
only establish Connections to that IP address.  If, on the other
hand, the Remote Endpoint specifies a hostname but no addresses, the
Connection can perform name resolution and attempt using any address
derived from the original hostname of the Remote Endpoint.  Note that
multiple Remote Endpoints can be added to a Preconnection, as
discussed in add-endpoints.
Paragraph (version A):
Cached State: The state and history that the implementation keeps
for each set of associated Endpoints that have been used
previously.  This can include DNS results, TLS session state,
previous success and quality of transport protocols over certain
paths, as well as other information.  This caching does not imply
that the same decisions are necessarily made for subsequent
connections, rather, it means that cached state is used by the
Transport Services architecture to inform functions such as
choosing the candidates to be raced, selecting appropriate
transport parameters, etc.  An application SHOULD NOT depend on
specific caching behaviour, instead it ought to explicitly request
any required or desired properties via the Transport Services API.
Paragraph (version B):
Cached State: The state and history that the implementation keeps
for each set of associated Endpoints that have been used
previously.  This can include DNS results, TLS session state,
previous success and quality of transport protocols over certain
paths, as well as other information.  This caching does not imply
that the same decisions are necessarily made for subsequent
connections, rather, it means that cached state is used by the
Transport Services architecture to inform functions such as
choosing the candidates to be raced, selecting appropriate
transport parameters, etc.  An application SHOULD NOT rely on
specific caching behaviour, instead it ought to explicitly request
any required or desired properties via the Transport Services API.