An Abstract Application Layer Interface to Transport Services
draft-ietf-taps-interface-26

I updated my discuss items to non-blocking comments. I'm still a bit concerned that some security items are not fully addressed by the API or its Security Considerations. Resolving my comments would make the document a bit more clear and useful I think.


I'm not sure that the model really expands from netflows to IP flows (or TOR) in the future.

I'm not sure the Security Considerations warn enough about re-using the same credentials with different protocols/auth mechanisms.
(eg TLS and IKEv2, or TLS 1.2 and QUIC, or using RSA as RSA-PKCS1.5 as well as RSA-PSS)

Unqualified Hostname vs FQDN seems a security risk punted mostly to the application. 

I don't understand this code:

        Connection := Preconnection.Initiate()
        Connection2 := Connection.Clone()

        Connection -> Ready<>
        Connection2 -> Ready<>

        //---- Ready event handler for any Connection C begin ----
        C.Send(messageDataRequest)

Where does "C" come from in "C.Send" ? The comment says "any Connection C"?

I have a question on this code:

        Preconnections are reusable after being used to initiate a
        Connection, whether this Connection was closed or not. Hence, it
        would be correct to continue as follows after the above example:

        //.. carry out adjustments to the Preconnection, if desired
        Connection := Preconnection.Initiate()

What would happen here? I can imagine a "compiler" turning this into
a noop.  I can also see it would kill the existing Connection state and
start a new one. This could be to a different IP address (eg if the DNS
name has A and AAAA). When starting a new one, what would happen to any
Message or Event queues for Connection ?

        Preconnection.AddRemote(RemoteCandidates)

Should this not technically be:

        Preconnection.AddRemote([]RemoteCandidates)

as the array contains at least a host and a stun server candidate?

Maybe this is just the difference between you using the variable you define
that has been assigned, versus a more C like prototype format, eg:

        Preconnection := NewPreconnection([]LocalEndpoint,

So I guess if your example here had set LocalEndpoint := [a,b] you would not
have used [] in the call ?


Section 6.1.4

Perhaps it would be useful to add a Local Endpoint with ephemeral port before
the Local Endpoint with static port example, as the ephemeral port should be
the far more common case. Right now the examples might give the wrong impression
a local port MUST be specified.

SecurityParameters.Set() seems to allow to set our identiy and our certificate,
but not the remote peer's identity or certificate? For example, one might want
to pin a remote certificate and not just rely on a WithHostname() identifier
being present as subjectAltname on a certificate.


       The Connection state, which can be one of the following:
        Establishing, Established, Closing, or Closed.

I think the text in Section 8 should more clearly show the property names if the
goal is to have different implementations use the identical name. Eg in this case,
why not write: The Connection state ("state"). The next two entries are similarly
lacking a clear keyword to use:

        Whether the Connection can be used to send data.

        Whether the Connection can be used to receive data.

eg. why not define words for these to implementations will use the same words,
in this case perhaps ReadySend and ReadyRcv ?
Writing that now, perhaps "state" should be "State" then ?

Section 8.1.1:

        If this property is an Integer

It is best to define the actual type in this document and not let implementations
choose, if the goal is to try and harmonize implementations. I also see no non-integer
value being given here ?

Firstly, thank you very much for writing this document -- I found it a fascinating read.

I'd also like to thank Matt Brown for the DNS-DIR review, it was most helpful.

I only have a few nits / suggestions to make:
1: S 1.4.  Glossary of Key Terms
*Endpoint: An identifier for one side of a Connection (local or
      remote), such as a hostnames or URL. 

I'm not really sure that the definition of "Endpoint" works. E.g: the definition of "Connection" is "Shared state of two or more endpoints that persists across Messages". Ok, fine. But can you really have shared state between two **identifiers**? I don't really see how I'd have shared state between e.g hostnames, but I can see how I'd have state between entities *identified* by an identifier like a hostname. I understand what you are aiming for (and also "endpoint" seems to be used in more than one context), but I don't think that the definition as written actually works...

2: S 2.1.  Event-Driven API
This paragraph compares and contrasts the Socket API and the Transport Services API, but in the paragraph starting with "For example, an application first issues a call to receive new data from the connection.", it is unclear under which paradigm you are meaning. I'd suggest: "For example, when using the Transport Services API, an application first ..."

# Éric Vyncke, INT AD, comments for draft-ietf-taps-interface-22

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Anna Brunstrom for the shepherd's detailed write-up including the WG consensus, and the justification of the intended status and of the large number of authors. I can only support having all those authors cited (especially from current/past academia). 

Other thanks to Tatuya Jinmei, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-taps-interface-22-intdir-telechat-jinmei-2023-09-01/ (while a positive review, I would appreciate a reply by authors, esp on issue 1)

Other thanks to Matt Brown, the DNS directorate reviewer (at my request), please consider this dns  -dir review:
https://datatracker.ietf.org/doc/review-ietf-taps-interface-22-dnsdir-telechat-brown-2023-08-27/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Abstract and Section 1

It is not only about "multiple interfaces" but also about "multiple provisioning domains" (usually linked to interfaces), e.g., an interface can have several IPv6 addresses and several next-hops. RFC 7556 is only mentioned in Section 2.

## Section 1

`Action(param0, param1?, ...) / Event<param0, param1, ...>` the use of `\` is unclear... suggest using two lines ? Should param1 in Event() also be suffixed by a '?' ?

Is `IP Address` scoped ? E.g., fe80::1%eth0 Can it be unicast, anycast, multicast ? Even if section 6.1 is about this issue, it may be worth already telling the readers.

## Section 3

`from a Remote Endpoint` does the use of 'a' preclude a multicast group endpoint ?

## Section 3.1

Useful section. Thanks.

## Section 4.1

It is a little underspecified whether the '.' is also removed when the Namespace component is omitted (I guess yes, but let's be specific).

Should 'tcp' be in uppercase in `tcp Connection could support ` ?

`IETF document published in the RFC Series` in which stream ? Are ISE or IAB or IRTF streams also OK ?

## Section 5

If not mistaken, then there are only 3 occurrences of a normative SHOULD and several other non-normative "should". Is it the intent ?

## Section 6.1

I am not sure whether I like the split between .WithIPAddress() and .WithInterface()... E.g., using "fe80::1%eth0" as an endpoint would be nicer ?

Should there be a .WithPvD() to handle multiple PvDs on the same interface ? Even after reading section 6.2.12, it is unclear.

## Section 6.1.1

TTL is so legacy... Why not using RFC 8200 hop limit ?


# NITS

## Section 6.1 and other places

2001:db8:4920:e29d:a420:7461:7073:0a is not a valid RFC 5952 address ;-)

## Section 8.1.11.13

s/It specified as the number of bytes/It *is* specified as *a* number of bytes/ ?

I am excited about this doc, and can confirm based on some experience that this is basically implementable.

Nevertheless there are a few problems, and potentially significant errors:

(S4.1) "Namespaces for each of the keywords provided in the IANA protocol numbers registry ... are reserved for Protocol-specific Properties and MUST NOT be used for vendor or implementation-specific properties."

It's regrettable that this excludes QUIC, TLS, HTTP, and other candidates for protocols operating under this API. Would it be too much to add a registry for additional reserved names? Indeed, there is enough noise in the protocol number registry it might be better to just have a registry of the 10? protocols that today might conceivably operate under TAPS.

(S7.3) This section confused me as to whether ICE is done by the Transport Service (paragraph 4), the app (paragraph 8), or both. (I think it's both.) Maybe state this more explicitly?

(S7.4) What happens if a Clone command results in a connection with different properties (e.g. in a second connection, the peer rejects the necessary TCP option)?

(S8, paragraph 3) "Therefore, it is RECOMMENDED that Protocol-specific Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary."

I think the first instance of "protocol-specific properties should be "generic properties"?

(S8.2) UTO is not TCP-specific! QUIC does it too. Maybe this should be a generic property?

(S9.2.6) "The Transport Services API does order connPriority over msgPriority. In the absence of other externalities (e.g., transport-layer flow control), a priority 1 Message on a priority 0 Connection will be sent before a priority 0 Message on a priority 1 Connection in the same group."

Everywhere in this doc, larger integers = higher priorities. So IIUC the Priority 1 connection should be sent first!

Hi,

Moderate level comments:

(1) As per the architecture doc, I think that it is great that you are defining a new transport API.  I note that this API doesn't really include any standard APIs or structures to monitor the state of the transport sessions for a given application (i.e., API user).  E.g., how many connections are currently open, total number of connections (since library was initialized), number of errored transport connections, drops, mtu issues, flow rates, etc.  I think that with some of the changes to the Internet architecture (e.g., QUIC to cite one obvious example), it reduces the ability for network operators to monitor and debug network issues between applications.  A potential corollary of this is that a lot more debug and diagnostics information will need to be made available to applications in a common way to allow application support staff, and users of those applications to better understand where in the network issues and failures are happening.  It would seem unreasonable for me to hold a discuss on this document for what might be a lot of work and discussion that could take a long time to resolve but I hope that the authors and WG will consider whether there is further useful future work required in additional RFCs.



Minor level comments:

(2) p 6, sec 1.1.  Terminology and Notation

   *  Array: Denoted []Type, an instance takes a value for each of zero
      or more elements in a sequence of the given Type.  An array may be
      of fixed or variable length.
   *  Collection: An unordered grouping of one or more values of the
      same type.

Perhaps calling it a Set may be better than Collection (if duplicates are not allowed) or a Bag (if duplicates are allowed).


(3) p 17, sec 6.1.  Specifying Endpoints

   Note that an IPv6 address specified with a scope (e.g.
   2001:db8:4920:e29d:a420:7461:7073:0a%en0) is equivalent to
   WithIPAddress with an unscoped address and WithInterface together.

Would it not just be cleaner to not allow interface scoped IP addresses, and force the clients to use WithInterface, in the case they want to target a specific interface?


(4) p 26, sec 6.2.  Specifying Transport Properties

     Upon reading, the Preference type
   of a Selection Property changes into Boolean, where true means that
   the selected Protocol Stack supports the feature or uses the path
   associated with the Selection Property, and false means that the
   Protocol Stack does not support the feature or use the path.

I misunderstood this on first reading - maybe explicitly state that the types for non Preference types are unchanged on a get, maybe give an example of the return type for section 6.2.11.


(5) p 64, sec 9.2.  Sending Data

   The optional endOfMessage parameter supports partial sending and is
   described in Section 9.2.3.

If this is an asynchronous API, I presume that the caller must prevent any changes to, or freeing of, the messageData object until it has received a event to indicate that the send has successfully completed.  Perhaps this is too detailed for this abstract level API and is left to the implementation.


(6) p 70, sec 9.3.2.  Receive Events

   Each call to Receive will be paired with a single Receive event,
   which can be a success or an error.  This allows an application to
   provide backpressure to the transport stack when it is temporarily
   not ready to receive Messages.

The backpressure aspect wasn't entirely clear to me.  So, if an application can handle receiving multiple receive events at the same time, it can make multiple calls to receive without waiting for, or processing, any receive events?  Is that how the application controls the backpressure?


(7) p 70, sec 9.3.2.  Receive Events

   Each call to Receive will be paired with a single Receive event,
   which can be a success or an error.  This allows an application to
   provide backpressure to the transport stack when it is temporarily
   not ready to receive Messages.

How does the transport stack know that the application has finished with the memory holding the message in the receive event, or is the expectation that the receive message contents is logically always allocated on the heap and it is responsibility of the receiver to free the memory once it is done with it?

Regards,
Rob