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

Alissa Cooper <alissa@cooperw.in> Wed, 19 September 2018 16:55 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB42130DE9; Wed, 19 Sep 2018 09:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=l9A152l3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gSm6pwU1
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk3IbkdNxMex; Wed, 19 Sep 2018 09:55:12 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D40126DBF; Wed, 19 Sep 2018 09:55:12 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5FEA621D6F; Wed, 19 Sep 2018 12:55:10 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 19 Sep 2018 12:55:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=52cBDjvEfYg+VkdpSwRhRUjX16Ivr x8eS+XjwWJl0fg=; b=l9A152l3wqLGDiYDfuOKUrwC4cs+NI4vtUhi3QQKHQZkk Bz1yjOg4G1cy2PvOu+zylPb2xtHpn59/tGmaRjdZU4omQoMccwnk+X9ldJQea6D/ u7ygEFSM5NyFgg9q93JrDpfyk657wGlnKE9YrZ8bR1KZncJoV6nmesQ7A/90YdKj gDv4hAsMZOJS4SWfh8q3l2Y5R0lh8Xpqzdmj2K5Bf/yPvaQh6TJAXZyvfGzKAKQ0 fIOpGlXdTxNAz4RNABnuMwi4b6JRVMJB7Q8RWu0ZUkFUpsnMZlm5xVMi7jjAM//5 MhHFI1Mo5DnLohLq0GpgiLOimA6actKUzKFss6Vlg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=52cBDj vEfYg+VkdpSwRhRUjX16Ivrx8eS+XjwWJl0fg=; b=gSm6pwU1HcBkZ7HEfnjWRd tPih73h13YG9MghQcPx7In63fF1nn05yAYxdKZWUr3v4jzVpnRNAw0iDI+ee8+Qr nZ0OvRNVV6t+SzE3qLrIxogy9rMqzZGOrJHjGsMvTzM2OSTVctlbbeAVVXCuKAg6 7fxFAkGGydlSDJPs+mo82VbvBqQJolgxlRSWi+DeM2HlXnLpqZkyrkD89WKDP0lZ 7TX5vE4Xd6y3H4gL44Beb5xTpgf64FEkh/yhI5VhK+vnzVNqzQL9bC0FMw0lVGnV r2KMkkeC1DnTE+j5oVBlU+Gb/K6vW8pUpunVwkUBaSDmvF77Wo8OAAWLJjE/lKvQ ==
X-ME-Proxy: <xmx:bX-iW99IhVTzWOZd6qkvrTkEIyuuU0QhwD1rX1ed7D1ABrAdgYNzBQ> <xmx:bX-iW8ZmeSrNDeVTUWUak2s2_eyIb6-VlFpU15sCqpPdnMOxf4UiWA> <xmx:bX-iWztwEEjvWTJUZbXVu417cA3r-IjBtpwZ8uoNyRK7goGRQDkzDw> <xmx:bX-iW4ltLs5LIfXSoNEg5KCskTvrOkEycB4j3a-gMCKEDOx5I7lIEw> <xmx:bX-iWzx4vpFAIQ67wiAsBFUBe566QWap42Ec1_b02YhExsWQjjDUJA> <xmx:bn-iW_x0-Yi8a6PDW1IrpnJh92bmEOVuMxzZ_zMBXRMMfYENQm7oZw>
X-ME-Sender: <xms:bX-iW13GnYe4W1-5P3KcBm99Pt-6sOMSxh8uEJTp2W0D5hcTvwZeZg>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.77]) by mail.messagingengine.com (Postfix) with ESMTPA id 450EB102D3; Wed, 19 Sep 2018 12:55:09 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <D93D472F-9A47-49F5-84EA-C02F843AB4DE@ifi.uio.no>
Date: Wed, 19 Sep 2018 12:55:07 -0400
Cc: IESG <iesg@ietf.org>, draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, theresa@inet.tu-berlin.de, taps@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <665733E7-C577-40E2-9E1C-5BA9EFC8A9F7@cooperw.in>
References: <153678015751.9346.17511699926997513174.idtracker@ietfa.amsl.com> <D93D472F-9A47-49F5-84EA-C02F843AB4DE@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/ceniIJyMrNgGUSxomhNf3Y0XrGE>
Subject: Re: [Taps] Alissa Cooper's Discuss on draft-ietf-taps-minset-08: (with DISCUSS and COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Sep 2018 16:55:15 -0000


> On Sep 17, 2018, at 2:26 AM, Michael Welzl <michawe@ifi.uio.no> 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 <alissa@cooperw.in> 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?
>