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

From: Alissa Cooper <[email-masked]>
Date: Wed, 12 Sep 2018 12:22:37 -0700

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?

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 12 Sep 2018 18:22:44 -0500

Hi, Alissa,

> https://datatracker.ietf.org/doc/draft-ietf-taps-minset/

Understood. I'll need to talk about this with the TAPS chairs, and that
won't happen before the telechat tomorrow morning, but I will talk with the
TAPS chairs, and you'll have an answer.

(So, "do we need to discuss that on this telechat?", "no, the Discuss is
clear and actionable". - just to save wear and tear on the Secretariat!)

Thanks,

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Mon, 17 Sep 2018 08:26:32 +0200

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-masked]> wrote:
Alissa Cooper has entered the following ballot position for
draft-ietf-taps-minset-08: Discuss

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 19 Sep 2018 12:55:07 -0400

> On Sep 17, 2018, at 2:26 AM, Michael Welzl <[email-masked]> wrote:
> 
> Dear Alissa,
> 

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.

> 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 w…

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

---

From: Michael Welzl <[email-masked]>
Date: Thu, 27 Sep 2018 11:34:07 +0200

Hi,

Below:

> On 19 Sep 2018, at 18:55, Alissa Cooper <[email-masked]> wrote:
> 
> 
> 

Thanks - and done now, with the update to version -11.

>   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