Dear Mirja, Thanks a lot for your comments! Answers below:
> 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. Done > 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. Done > 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. Done > 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. 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. > 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. Done (updated using your proposed sentence). > 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). 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. > 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. 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. > 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). Done (updated the reference) > 7) Why is "Configure checksum usage" (only) applicable to individual > connections? 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
