[Taps] Feedback Re: Fwd: New Version Notification for draft-gjessing-taps-minset-05.txt

Hi,

when reading the minset draft, I stumbled over a couple of points. Some
of them may be nits and/or obvious to everyone except me, but I thought
I'd offer them as feedback.

Section 2 (Terminology): Would it make sense to define several more
terms here, such as Flow, Flow group, Message and Frame? While reading
the rest of the draft I was, e.g., wondering if a "TAPS flow" is the
same as "Connection" defined in Section 2 or something else. E.g., in
Section 3.1 the draft talks about how to create a TAPS flow and at least
for me it would be helpful to read a description of what a TAPS flow
actually is beforehand.

Section 3.1 (Flow Creation, Connection and Termination), second
paragraph: "A created flow can be queried for the maximum amount of data
that an application can possibly expect to have transmitted before or
during connection establishment."
I had trouble understanding this sentence, as it was not immediately
obvious to me that it is possible to send data before a connection is
established. Maybe it would be helpful to first state that this is a
feature that some protocols have.

Section 3.2 (Flow Group Configuration): Is it also possible to configure
these features on individual flows? Only if they do not have a group? (I
had the same question again later at the beginning of Section 4.)

Section 3.3 (Flow Configuration): At this point I was also wondering how
to configuring a flow to be, e.g., reliable. As reliability is one of
the most obvious transport features for me, I would find it useful to
make this explicit. It is not configured per flow, but per message,
right? So an application can send both reliable and unreliable messages
in one flow, but it does not communicate this through the TAPS API at
flow creation time, but only later when it actually sends the messages?

Section 3.4.1 (The Sender): This section talks about messages and
per-frame properties. Is a message the same as a frame here?

Features that are optional - So are these still mandatory features to
have in the API (which I thought the minset was) but then they do not
have to be implemented, i.e., actually do something?

Section 4 (An Abstract MinSet API): Do I have to create a flow-group-id
explicitly or is the flow-group-id just the flow-id of a previous flow?
In other words, are the flow-id and the flow-group-id the same number
space or are they distinct?

Best,
Theresa

On 20.06.2017 15:21, Michael Welzl 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-drafts@ietf.org <mailto:internet-drafts@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 <michawe@ifi.uio.no <mailto:michawe@ifi.uio.no>>,
>> Stein Gjessing <steing@ifi.uio.no <mailto:steing@ifi.uio.no>>
>> *Resent-From: *<michawe@ifi.uio.no <mailto:michawe@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
>> Status:
>>         https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/
>> Htmlized:       https://tools.ietf.org/html/draft-gjessing-taps-minset-05
>> Htmlized:
>>       https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05
>> Diff:
>>           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