Hi, Below:
> On 19 Sep 2018, at 18:55, Alissa Cooper <[email protected]> wrote: > > > >> On Sep 17, 2018, at 2:26 AM, Michael Welzl <[email protected]> wrote: >> >> Dear Alissa, >> >> As an author of the minset draft, I'd like to share our own views on your >> comments below. These reflect both what we authors think, but also what >> several others seem to think - so in a way, this email also summarizes views >> from emails written by Mirja, Theresa Enghardt (doc shepherd), and Aaron >> Falk (TAPS chair). >> >> >> 1) The role of minset: >> ---------------------- >> In line with the charter of TAPS, draft-ietf-taps-minset describes the >> minimum functionality of the abstract API the working group is building, not >> any sort of compliance for implementors. In other words, it is an >> intermediate step in the working group's design effort that the working >> group (and charter) dictates should be published. To ensure the API design >> effort captured the most important IETF protocol functions, we wanted to be >> sure the working group documented and agreed on what those functions should >> be, thus the minimum set of functions the TAPS API should implement. The API >> itself is being developed in the standards track docs that are currently >> being written in the wg. I would agree there should be no normative >> references to this document and I'll work with the authors of >> draft-ietf-taps-interface to have it removed. > > Thanks, this is helpful. It might even be helpful to add a line about this > being an “intermediate step” to the draft. Up to you. I will clear my DISCUSS. Thanks - and done now, with the update to version -11. >> 2) QUIC: >> -------- >> Based on our analysis, QUIC doesn't add any additional features to the pool >> identified in the minset draft, so our conclusion is that no additional text >> is needed to be sure the API is compatible with QUIC. Of course, QUIC is not >> done and if this prediction would turn out to be wrong, we'd be talking >> about a direct influence of the (Proposed Standard) API document ( >> draft-ietf-taps-interface ), and perhaps draft-ietf-taps-impl, but not the >> minset document which just made sure we have the minimum covered. > > Ok. I was wondering in particular about this bit of text in Section 6, which > seems like it could quickly go stale: > > "Authentication, confidentiality protection, and integrity protection > are identified as transport features by [RFC8095]. As currently > deployed in the Internet, these features are generally provided by a > protocol or layer on top of the transport protocol; no current full- > featured standards-track transport protocol provides all of these > transport features on its own.” I understand; thanks! I now changed this text to say: "Often, these features are provided by a protocol or layer on top of the transport protocol; none of the full-featured standards-track transport protocols in [RFC8303], which this document is based upon, provides all of these transport features on its own." Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
