Draft: draft-ietf-taps-interface

Commentary: does the update about transport aliasing help ? 
 The call needs multiple local and remote candidate endpoints . This means should take lists of and objects ( section 5 ) and there should be ways of adding / removing and objects from a Relates to 
 Pairs of ? Local and remote endpoints probably need to be linked . 
 updates the description of to say : That 's fine , but it prevents a single being used in when there are multiple candidates . For to work , we need to relax this restriction and allow multiple addresses of the same type to be to an endpoint . what 's the rationale for the change in ? 
 I remember having multiple addresses on an endpoint would also benefit multicast . 
 the explanation for how multicast is handled did n't change at all here , btw . 
 I think it would make most sense to either : Use the alias approach , where one endpoint can have a list of aliases that are equivalent options , or Let the preconnection have multiple endpoint objects for rendezvous The definition of a single endpoint object is a lot easier to keep track of and understand if it is a single address or equivalent identifier . 
 sec 5.1 I found it odd that there did n't appear to be any sort of formal list of attributes of an endpoint , just some examples . 
 Should fix with 
 what happened if you add multiple addresses or interfaces to an endpoint : Does it overwrite the existing one or not ? 
 I would say that it does not overwrite but simply add to a list of addresses . This is , among other things , because for a Listen ( ) the remote endpoint can be used to filter incoming connections and I do n't think it makes much sense to only be able to constrain it to a single address . 
 I agree with – but we should really make this explicit 
 Discussion at interim : Clarification is needed . add ( ) during preconnection will overwrite , and add ( ) can not be used in connection state . Also add a note in the text that e.g. specifying a specific IP address might restrict mobility or use of multiple paths and could cause the connection to fails when the IP address goes way rather than enabling some handover . Still open : Do we need a way to add of multiple addresses in the first place ? This is used for filtering remote IP addresses for listener for multicast . 
 The current API text does n't use " add " , but rather " with ... " : It also implies that multiple is already allowed : How does that line up with the comment about , and having that replace ? 
 As far as I can see , in the API draft we currently have add ( ) for Properties and Security Parameters where each new add ( ) overwrites the value for the old one . So if we change this to add ( ) , probably IP addresses should work the same . But ca n't we just allow add ( ) with a list of IP addresses instead of just with a single IP address ? 
 Allow adding an alias endpoint to an endpoint Any one endpoint has at most one hostname Any one endpoint has at most one port / service ( if you need more , add an alias ) Any one endpoint has at most one address If you need multiple source - specific multicast filters , use multiple connection objects 
 From The Preconnection Object must be specified with both a Local Endpoint and a Remote Endpoint , and also the transport properties and security parameters needed for Protocol Stack selection . To Rendezvous ( ) we need multiple local and remote candidates . Should this be represented as either : Rendezvous ( ) taking two lists of Preconnection objects ; or as two Preconnection objects each with multiple addresses , ports , etc . I suggest option 1 , since this makes it easier to resolve a Preconnection to multiple preconnections , for NAT binding discovery . Relates to but with also different types of endpoint . 
 I 'm adding a point from here ( and closing a separate issue that he opened , because this tackles the same problem space ): In the past , when I 've designed transport abstraction APIs , I 've always kept address family abstract , just as BSD sockets do . In this case , you 've got WithIPv4Address and With IPv6Address as separate methods on the Endpoint type instead of just a single WithAddress method that takes an object of a type appropriate to the address family . Similarly , you 've got  as a first - class method instead of making it part of the Endpoint , as BSD sockets does with sockaddr_in . What if you want to support both TCP and QUIC , but the QUIC endpoint is on a different port ? The notion of " port " is similar between the two , making the use of the same name appropriate , but it is only by convention that they often match : they are completely different spaces implemented in entirely separate codepaths in every network stack . ICMP does n't even have a port : what if you wanted to use that ( or some other port - less protocol that , for instance , multiplexes via IPv6 host ID ) with this interface .
Paragraph (version A):
The transport services API uses the Local Endpoint and Remote
Endpoint Objects to refer to the endpoints of a transport connection.
Actions on these Objects can be used to represent various different
types of endpoint identifiers, such as IP addresses, DNS names, and
interface names, as well as port numbers and service names.
Paragraph (version B):
A single Endpoint Object represents the identity of a network host.
That endpoint can be more or less specific depending on which
identifiers are set.  For example, an Endpoint that only specifies a
hostname may in fact end up corresponding to several different IP
addresses on different hosts.
Paragraph (version B):
An Endpoint cannot have multiple identifiers of a same type set.
That is, 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.
Paragraph (version B):
The Resolve() action on a Preconnection can be used by the
application to force early binding when required, for example with
some Network Address Translator (NAT) traversal protocols (see
rendezvous).
Paragraph (version B):
Specifying a multicast group address on a Local Endpoint will
indicate to the transport system that the resulting connection will
be used to receive multicast messages.  The Remote Endpoint can be
used to filter incoming multicast from specific senders.  Such a
Preconnection will only support calling Listen(), not Initiate().
The accepted Connections are receive-only.
Paragraph (version B):
An Endpoint can have an alternative definition when using different
protocols.  For example, a server that supports both TLS/TCP and QUIC
may be accessible on two different port numbers depending on which
protocol is used.
Paragraph (version B):
To support this, Endpoint Objects can specify "aliases".  An Endpoint
can have multiple aliases set.
Paragraph (version B):
In order to scope an alias to a specific transport protocol, an
Endpoint can specify a protocol identifier.  These identifiers MUST
only be set for aliases.
Paragraph (version B):
The following example shows a case where "example.com" has a server
running on port 443, with an alternate port of 8443 for QUIC.
Paragraph (version B):
The following examples of Endpoints show common usage patterns.
Paragraph (version A):
Implementations may also support additional endpoint representations
and provide a single NewEndpoint() call that takes different endpoint
representations.
Paragraph (version A):
Multiple endpoint identifiers can be specified for each Local
Endpoint and Remote Endpoint.  For example, a Local Endpoint could be
configured with two interface names, or a Remote Endpoint could be
specified via both IPv4 and IPv6 addresses.  These multiple
identifiers refer to the same transport endpoint.
Paragraph (version A):
The Resolve() action on Preconnection can be used by the application
to force early binding when required, for example with some Network
Address Translator (NAT) traversal protocols (see rendezvous).
Paragraph (version A):
Specifying a multicast group address on the Local Endpoint will
indicate to the transport system that the resulting connection will
be used to receive multicast messages.  The Remote Endpoint can be
used to filter by specific senders.  This will restrict the
application to establishing the Preconnection by calling Listen().
The accepted Connections are receive-only.