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. 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. I hope this helps. Let me know if you need any more information to remove your DISCUSS on the draft. Cheers, Michael ---- On Sep 12, 2018, at 9:22 PM, Alissa Cooper <[email protected]> wrote: Alissa Cooper has entered the following ballot position for draft-ietf-taps-minset-08: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I was wondering about why this document is going for informational rather than proposed standard. I see that draft-ietf-taps-interface-01 has a normative reference to it, so this is effectively setting up a downref situation. That isn't necessarily a problem, but if the point is for this document to recommend an actual minimal set of transport services to be supported and exposed via the API specified in draft-ietf-taps-interface and other APIs, shouldn't that set be normative? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It seems like this document will be in need of updating once QUIC is published. Is the plan to publish this now and then publish an update next year? Why is that preferable to waiting and just publishing once? _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
