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

[Mirja Kühlewind <[e-mail]>]

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?