> 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. > > > 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.” Best, Alissa > > 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
