Subject: [Taps] Mirja Kühlewind's No Objection on draft-ietf-taps-minset-08: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 07 Sep 2018 07:49:20 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-taps-minset-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-minset/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rereading this doc again, I still have a couple of mostly editorial comments
(however, none of them are critical in any way):

1) In the terminology section I think "Transport Service Instance" is actually
never used in this doc and could therefore be removed. Please also double-check
if service and feature is used coherently; I thought there were one or two
cases where I would have expected to see feature instead of service. And
finally Connection Group is explain there, however, given it is a new term and
important concept, I would recommend to introduce it anyway separately in the
intro as well.

2) Not sure if the paragraph in the intro about "one-sided" deployment is
needed there, given that this doc does not/should not really talk about any
deployment considerations for an taps system.

3) In section 3 I find this sentence a bit confusing: "The described transport
system can be implemented over TCP." This sentence leaves open if other
protocols can be implemented as well. However, I guess what you actually what
to say is something like "Any configuration based the described minimum set of
transport feature can always be realized over TCP but also gives the transport
system flexibility to choose another transport if implemented." Or something
like this. I think a clarification would be helpful to make clear that there is
no direct dependency on TCP.

4) I personally still think that having this example decision tree in section
3.1 puts to much emphasis on this specific example (that "only" covers TCP,
SCTP, and UDP(-Lite)) and I would rather move it to the appendix (or maybe
create an own subsection somehow).

5) In section 3.1 the paragraph starting with "Once a connection is created..."
seems redundant with section 3.2.1 and could potentially be just removed.

6) sec 3.3.1: "Note that
      applications sending unreliable data without congestion control
      should themselves perform congestion control in accordance with
      [RFC2914]."
  I guess the better reference is RFC8085 (if this sentence is needed at all).

7) Why is "Configure checksum usage" (only) applicable to individual
connections?

---

From: Michael Welzl <[email-masked]>
Date: Thu, 13 Sep 2018 16:30:24 +0200

Dear Mirja,

Thanks a lot for your comments! Answers below:

> never used in this doc and could therefore be removed.

Done

> Please also double-check
> cases where I would have expected to see feature instead of service.

Done

> And

Done

> deployment considerations for an taps system.

We believe that this is an important paragraph because the whole document is
about defining a set that can also function one-sided over TCP, and, with
limitations, UDP. If we can assume a certain "minset" protocol on the other
side, everything about this document changes.

> no direct dependency on TCP.

Done (updated using your proposed sentence).

> create an own subsection somehow).

We think that, structurally, having it in this place makes for an easier
read. It's stated that this is only an example and "not optimal for all cases",
so we think there's no problem with this having too much emphasis.

> seems redundant with section 3.2.1 and could potentially be just removed.

We don't see the redundancy: this paragraph describes some things related
to what we now call a "Preconnection" in draft-ietf-taps-interface, whereas
3.2.1 is strictly about connection groups.

>  I guess the better reference is RFC8085 (if this sentence is needed at all).

Done (updated the reference)

> 7) Why is "Configure checksum usage" (only) applicable to individual

Because it's a UDP-Lite thing and hence applies per send / receive call.
Regarding "only", it's the other way round: only "Configure checksum usage"
and "Configure priority or weight for a scheduler" can be used on
individual connections, everything else automatically applies to all
grouped connections (as stated in the first paragraph of section 3.2.1).

Thanks again,

cheers,
Michael