[Taps] draft-ietf-taps-interface-05 review
Kyle Rose <krose@krose.org> Fri, 24 January 2020 01:24 UTC
Return-Path: <krose@krose.org>
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 04D41120105 for <taps@ietfa.amsl.com>; Thu, 23 Jan 2020 17:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 P4S3CuxHEnXS for <taps@ietfa.amsl.com>; Thu, 23 Jan 2020 17:24:27 -0800 (PST)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C1412084B for <taps@ietf.org>; Thu, 23 Jan 2020 17:24:27 -0800 (PST)
Received: by mail-yb1-xb30.google.com with SMTP id x18so164136ybk.6 for <taps@ietf.org>; Thu, 23 Jan 2020 17:24:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=NyplQedjRKCenazNXRaUmpesWc7QkV9R2H08zr5eZ4A=; b=LBY/Tg6gA6jGd0LAyJA0/Y6rg7NHYTdS9E/zYnsAWVLQqotB67kkgnUg6KSwqlW4TK fd2TLTDtCqXPSydqcp7fVHdT5k1/solcBo5AEXFgd+JlO9F1DqCDvVnAXI7mEdzrlF6w c4oJ34tyG6hVeaNUvJ5DjK9/bfBPZJn67W36U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NyplQedjRKCenazNXRaUmpesWc7QkV9R2H08zr5eZ4A=; b=XrZAZKCa+A3NqHEU6d7NiCkZ9WpBrAmO266LPC1DXuC2dAgWieMzqFOuXmz2Ezr56E oyy0k2/ecOTzq1ptseNcU5qsUeGPlGtTl9wcnvsW8PqqV+Gb+d2naxA7HIj2c9W3UK+L /N9jGM1g0ZHiaRMGYz3q0B7xbf/onQImfKo8fZovpWbDA9uu9YRN5/ycf4FJ16FGGST7 PFxz7T09FNLgzSioQEUeHr5N8YLDJwRiFuStc7HfNeHF6jrRPOiihfjeZOSkJ+FTW7Hg FEu2G9xVorf+JVhRCapL8Kd3qVd82MWFffKT3vpAnepplPX6yB6N1peKVmZfZw1edCiO vuMA==
X-Gm-Message-State: APjAAAXdDgP0czlklvsJnOezl5L3OSf8kVlSFIntbUIchVI3YfeCfxgH 7rW72qgjGeKqLq2o+CS0ja7XrbE/4LAhelb/6yz3T/26+hig+w==
X-Google-Smtp-Source: APXvYqxFrHV6BwM5Wa+/fm6wDm3D17qblkriUzCY20Uxh3EVlMkGsmYWJTiw1GYd0SEdUgbbBtetQPkQotzfjBr8kOg=
X-Received: by 2002:a25:eb0f:: with SMTP id d15mr488480ybs.247.1579829065628; Thu, 23 Jan 2020 17:24:25 -0800 (PST)
MIME-Version: 1.0
From: Kyle Rose <krose@krose.org>
Date: Thu, 23 Jan 2020 20:24:24 -0500
Message-ID: <CAJU8_nVyAvVzD6ZitxwzoVCYBYmT1y3oP7U8FhgyWfx8p6RR5w@mail.gmail.com>
To: taps WG <taps@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004365be059cd89e91"
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/o1ehdiAwdqAG42xy2Gy5Cb62eYA>
Subject: [Taps] draft-ietf-taps-interface-05 review
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: Fri, 24 Jan 2020 01:24:34 -0000
I've completed my review of draft-05, inline below. I will also submit a PR with minor changes that I recommend be addressed via cherry-picking agreed-upon hunks from the diff. 2. Terminology and Notation * "The method for dispatching and handling Events is an implementation detail, with the caveat that the interface for receiving Messages must require the application to invoke the Connection.Receive() Action once per Message to be received (see Section 8)." This isn't true if ReceivedPartial events are triggered, right? Also, it's not really clear that any of this discussion belongs in a section titled "Terminology and Notation". This issue is alluded to later in the doc, and probably mostly belongs in the implementation doc. * The notation "Sender -> Event" says nothing about who receives the event. Is it just assumed to be the application in the context of the particular event (e.g., a thread processing a particular connection)? 3. Interface Design Principles * What does "long-term caching of cryptographic identities" mean? The implication seems to be that credentials and transport security parameters can be configured once and used repeatedly. I'm not sure time interval ("long-term") is the right modifier here, and the word "caching" might be misunderstood as it means something subtly different in the realm of computer hardware and software than the dictionary definition implies. Maybe something like: "...and for configuration of cryptographic identities and transport security parameters persistent across multiple Connections" * "An application primarily interacts with this interface..." This seems awkward. An interface is the means by which an application interacts with the underlying transports. 4.2.1. Transport Property Names * The use of dashes in property names means they will necessarily look different in almost every widely-used language, in which dash is an operator. * If we're not currently asking IANA to create a registry of property names or namespaces, should we provide a recommendation that such symbols not listed explcitly in this document be prefixed with some experimental identifier? 4.3. Scope of the Interface Definition * "Implementations of this interface SHOULD implement each Selection Property, Connection Property, and Message Context Property specified in this document, exclusive of appendices. Each interface SHOULD be implemented even when this will always result in no operation, e.g. there is no action when the API specifies a Property that is not available in a transport protocol implemented on a specific platform." This seems like it implies that a property that is unavailable should silently fail to be activated, which conflicts with the "Require" preference referenced later. There may be some way to reword this to be clear that it's referring to implementing all of the properties in the API so that compile-time or runtime errors don't spuriously occur when some symbol hasn't been defined. Also: why "exclusive of appendices"? 5.2. Specifying Transport Properties * There are a lot of choices being made about how users will want to prioritize transport protocol selection. How confident are we that, for instance, path selection should take priority over protocol selection? I think that's right, but I wonder if it might not make more sense to have two interfaces: one that provides a purely numeric priority ordering of preferences, and one (based on the existing 5-level preferences) that maps into it. * "As preference typed selection properties..." I can't parse this. * Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried output of selected properties seems like a shortcut that will lead to some confusion. 5.2.5. Use 0-RTT Session Establishment with an Idempotent Message * I'll repeat the same statement I made at the mic a few years ago: idempotency != replay-safe. DELETE is idempotent, but not safe for replay because someone might have done a PUT or POST in the meantime. 5.2.10. Interface Instance or Type * These type symbols really deserve an actual registry, or at least the start of one. Otherwise, we are likely to end up with a mess. 5.2.11. Provisioning Domain Instance or Type * What about ordering of similar interfaces? I have a 2-SIM cellphone with wifi. 5.3.2. Connection Establishment Callbacks * What constitutes trust verification prior to the handshake? 6.4. Connection Groups * "An ideal transport system" for whom? The capacity partitioning recommended here seems purely subjective. I'd just remove it. 7.3.1. Sent * It seems like an abstract API would be helpful for the reference to the Message to which a Sent event applies: this seems like something many, many applications would need to do. With callbacks, the application can always curry in a reference to the original message (that's what my event system from ~2001 did), so maybe that should be the recommendation and the message reference removed...? I don't have a strong feeling here other than that if something is included then its use should be more well-defined. 7.3.3. SendError * Is there a reason why a single messageContext object is used for both sends and receives? I probably missed the original discussion about this, but I'd like to understand the reasoning. 7.4.7. Reliable Data Transfer (Message) * The default isn't "true", it's whatever the underlying connection had, right? 7.4.9. Singular Transmission * Might be worth pointing out there's no guarantee here, either, considering resegmenting TCP middleboxes. 8. Receiving Data * A connection can be used to receive data if it is not configured as unidirectional transmit. 8.2. Receive Events * "A call to Receive will be paired with a single Receive Event" or possibly multiple ReceivedPartial Events? * Also, can the draft be consistent about Receive vs. Received, et al.? 9. Message Contexts * "To get or set Message Properties, the optional scope parameter is left empty, for framing meta-data, the framer is passed." I can't parse this. 11. General comments * There's a lot of UNIXisms here that should probably be excised in favor of a more abstract presentation. The most obvious is the use of -1 to mean something other than the integer -1. In Python, for instance, you might want to use None for this purpose. I would specify non-numeric values symbolically, and maybe indicate in the appendix that a UNIX C implementation might want to use -1 to represent such values. 11.1.3. Priority (Connection) * I'm not sure what "relative inverse priority" means. Is P1 higher priority than P5, and therefore lower inverse priority than P5? Or the other way around? 11.1.10. Capacity Profile * Very little of this section is about capacity. Traffic Profile? * "High Throughput Data" might be better phrased as "Capacity-Seeking". 11.2. Soft Errors * Should the SoftError Event carry some information about e.g. the ICMP message received?
- [Taps] draft-ietf-taps-interface-05 review Kyle Rose
- Re: [Taps] draft-ietf-taps-interface-05 review Michael Welzl
- Re: [Taps] draft-ietf-taps-interface-05 review Philipp S. Tiesel
- Re: [Taps] draft-ietf-taps-interface-05 review Michael Welzl
- Re: [Taps] draft-ietf-taps-interface-05 review Gorry Fairhurst
- Re: [Taps] draft-ietf-taps-interface-05 review Kyle Rose