Hi, Thanks a lot for your comments!
> On May 31, 2018, at 6:17 PM, Tommy Pauly <[email protected]> wrote: > > Hello TAPS, > > I’ve just done a read through of the current minset draft. Overall, looks > good! I have a few nits, but these can all be addressed in the next revision: > > - The first sentence of the abstract is a bit hard to parse for someone who > isn’t coming from the context of the working group: > > "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.” > > We use the term “TAPS” as a well-known term here, which I don’t think it is > necessarily. In our architecture/API/implementation documents we’re trying to > avoid using TAPS as term, and using Transport Services more instead. That’s > not to say we should remove the usage of TAPS here, but perhaps do the > Transport Services (TAPS) definition somewhere up-front. Also, why is this is > minimal set of “IETF" services? I assume this means “a minimal set of > Transport Services defined in IETF protocols”, but it feels heavy on the > jargon. Done (given that this is an IETF document, the fact that it’s based upon IETF-defined protocols is the default assumption, not an exception; moreover, the abstract also says that it’s based on RFC 8303, and so this IETF reference seems unnecessary). > - Same point of defining “TAPS” for the introduction.’ Done (removed “TAPS” everywhere) > - Introduction: > > "For example, it does not help an > application that talks to a middleware…” > > Does the application talk to “a middleware”? I understand the use of “the > middleware” later, but it seems to me that middleware should have the same > usage as “software”, and we don’t use “a software” generally. Changed to “library” > - Section 3 > > Personally, I’d add an Oxford comma here: "Based on the categorization, > reduction and discussion…” to "Based on the categorization, reduction, and > discussion…” Done > - Section 3.1 > > Is there a reason we use underscore style for the parameters? > “Checksum_coverage”, “Config_msg_prio”, etc. While I understand that these > may be the code symbols you use in a C program, you’re not using this style > or these symbols elsewhere, and it would be clearer to write out “Configure > message priority”, etc. It will also look more palatable to more modern > language styles =) Agree, done - note that these are only a handful of occurrences (actually only the two you mention + what is now “Early message timeout notification”, as all others refer to other documents and hence carry the name that’s used there. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
