Hi Michael, Hi Stein, I also read through the draft (now more than once) and have some questions and comments. I hope not to open old rat-holes with this…
Sec 1 (Intro) The number of transport features of current IETF transports is large, and exposing all of them has a number of disadvantages: generally, the more functionality is exposed, the less freedom a TAPS system has to automate usage of the various functions of its available set of transport protocols. Some functions only exist in one particular protocol, and if an application would use them, this would statically tie the application to this protocol, counteracting the purpose of a TAPS system. Also, if the number of exposed features is exceedingly large, a TAPS system might become very hard to use for an application programmer. Taking [TAPS2] as a basis, this document therefore develops a minimal set of transport features, removing the ones that could be harmful to the purpose of a TAPS system but keeping the ones that must be retained for applications to benefit from useful transport functionality. I am somewhat unsure if a TAPS system really should withhold an application from, e.g., using TCP specific features if it has strong evidence that the other endpoint will be TCP only? I agree that an application using TAPS should make use of automation when possible to avoid ossification, but is excluding applications that need protocol specific functionality much more dangerous as it requires a non-TAPS API to be present to service them? This "minimal set" can be implemented one-sided with a fall-back to TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP receiver, and a receiver-side TAPS system can talk to a non-TAPS TCP sender. For systems that do not have this requirement, [I-D.trammell-taps-post-sockets] describes a way to extend the functionality of the minimal set such that several of its limitations are removed. I am glad to see that fallback is addressed, but why exclusively to TCP and not TCP or UDP – whatever is more applicable? I also don’t see any reason why a system like post sockets shouldn’t support fallback. If using something happy eyeballs to check what protocols are available (biased by preference)m there is no reason why supporting a fallback ha to limit functionality. Sec 2.3 (Flow Group Configuration) Does the "capacity profile” only apply to a flow group or can it also be applied on a per-message basis? If this is only intended to imply the DSCP value, a message would be a much better scope, e.g. for protocols that multiplex multiple kinds of message within a single flow/flow group. Same applies to more values. Does it make sense to make them configurable on multiple levels? Sec. 4 CONFIGURE_URGENCY (flow-group-id [scheduler] [capacity_profile] [low_watermark]) Do these three really belong together or are this these rathe three more or less independent configuration variables? CONNECT (flow-id dst_addr) Connects a flow. This primitive may or may not trigger a notification (continuing LISTEN) on the listening side. If a send precedes this call, then data may be transmitted with this connect. PARAMETERS: dst_addr: the destination transport address to connect to Might be only a knit but this looks very TCP centric for me – how would a usage example for "UDP connect” (which is somewhat of a contradiction anyway) – maybe I only dislike connect here… Maybe this also needs what types of dst_addr might take - do I have to think this something like a sockaddr_t or as a host / service pair? The latter is much more useful for automation. AVE! Philipp S. Tiesel / phils… > On 20. Jun 2017, at 15:21, Michael Welzl <mich...@ifi.uio.no> wrote: > > Dear group, > > We just updated the minset document. Important changes are: > - the minset itself is now presented early, all the long boring text about > how stuff was derived has been moved to an appendix > - a first stab at an abstract API representation of the minset is now > included! > > Cheers, > Michael & Stein > > >> Begin forwarded message: >> >> From: <internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>> >> Subject: New Version Notification for draft-gjessing-taps-minset-05.txt >> Date: June 20, 2017 at 2:09:24 PM GMT+1 >> To: Michael Welzl <mich...@ifi.uio.no <mailto:mich...@ifi.uio.no>>, Stein >> Gjessing <ste...@ifi.uio.no <mailto:ste...@ifi.uio.no>> >> Resent-From: <mich...@ifi.uio.no <mailto:mich...@ifi.uio.no>> >> >> >> A new version of I-D, draft-gjessing-taps-minset-05.txt >> has been successfully submitted by Michael Welzl and posted to the >> IETF repository. >> >> Name: draft-gjessing-taps-minset >> Revision: 05 >> Title: A Minimal Set of Transport Services for TAPS Systems >> Document date: 2017-06-20 >> Group: Individual Submission >> Pages: 44 >> URL: >> https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-05.txt >> <https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-05.txt> >> Status: https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ >> <https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/> >> Htmlized: https://tools.ietf.org/html/draft-gjessing-taps-minset-05 >> <https://tools.ietf.org/html/draft-gjessing-taps-minset-05> >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05 >> <https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05> >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-gjessing-taps-minset-05 >> <https://www.ietf.org/rfcdiff?url2=draft-gjessing-taps-minset-05> >> >> Abstract: >> This draft recommends a minimal set of IETF Transport Services >> offered by end systems supporting TAPS, and gives guidance on >> choosing among the available mechanisms and protocols. It is based >> on the set of transport features given in the TAPS document >> draft-ietf-taps-transports-usage-05. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org >> <http://tools.ietf.org/>. >> >> The IETF Secretariat >> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
