Re: [Taps] Alissa Cooper's Discuss on draft-ietf-taps-minset-08: (with DISCUSS and COMMENT)

[Michael Welzl <[e-mail]>]

Hi,

Below:


> On 19 Sep 2018, at 18:55, Alissa Cooper <[e-mail]> wrote:
> 
> 
> 
>> On Sep 17, 2018, at 2:26 AM, Michael Welzl <[e-mail]> 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