Re: [arch-d] [hrpc] New Version Notification for draft-iab-for-the-users-01.txt

Eliot Lear <lear@cisco.com> Fri, 13 December 2019 15:51 UTC

Return-Path: <lear@cisco.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45211120863 for <architecture-discuss@ietfa.amsl.com>; Fri, 13 Dec 2019 07:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 A1VhTHl6Brb1 for <architecture-discuss@ietfa.amsl.com>; Fri, 13 Dec 2019 07:51:05 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F490120861 for <architecture-discuss@ietf.org>; Fri, 13 Dec 2019 07:51:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12083; q=dns/txt; s=iport; t=1576252261; x=1577461861; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=5cLGdSh1w7nNmjw+w0D4G52RZ8dzW9L5m5+cQqtPfFQ=; b=BjwNRjhl9WGk7D8YROB02GBwbILXISWob56gq8YRk1MTRRzNvsCtLhyl lOvJwNdBnmo+AzjbRbnIG3uRVMCpA7MBaijm7CGgaGC982Jvi4yejqcuD ZeRxN9RxigHeKzENblbrzRWn4Bfddw+zZm/T7u3ECBADGIbBHhmpgBQym E=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AADgsvNd/xbLJq1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBfoNhIBIqhAOJA4gxgQGSI4YkgWcCBwEBAQkDAQEvAQG?= =?us-ascii?q?EQAKCMzgTAgMNAQEEAQEBAgEFBG2FQ4VeAQEBAQIBI1QCBQsLGBUVAgJXBhM?= =?us-ascii?q?fgwMBglcgrDZ1gTKFT4RqEIE2gVOIcoFtggCBEScggU5JBTA+hAMBCXuCUTK?= =?us-ascii?q?CLASNFiGJTJdsgjqCPIEZiQKJIhuOUotvpWWDIwIEBgUCFYFpIj6BGjMaCBs?= =?us-ascii?q?VZQGBWWg+EhEUm1lAAzCNaYFSYAEB?=
X-IronPort-AV: E=Sophos;i="5.69,309,1571702400"; d="asc'?scan'208,217";a="20317235"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Dec 2019 15:50:59 +0000
Received: from [10.61.204.232] ([10.61.204.232]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xBDFowEF015661 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Dec 2019 15:50:58 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <326C92A0-5F29-411D-99DE-7C785CF73EE7@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_06D0BF67-BA8F-4BA3-87C2-24D20F70A9FA"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Fri, 13 Dec 2019 16:50:57 +0100
In-Reply-To: <alpine.LRH.2.21.1912130913480.8529@bofh.nohats.ca>
Cc: Ted Lemon <mellon@fugue.com>, Vittorio Bertola <vittorio.bertola@open-xchange.com>, "hrpc@irtf.org" <hrpc@irtf.org>, architecture-discuss@ietf.org
To: Paul Wouters <paul@nohats.ca>
References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> <01246A3C-31EC-4B7B-841D-F799EEFADCB8@mnot.net> <227662299.12784.1575991106819@appsuite-gw2.open-xchange.com> <C74D5288-709B-46E3-B9F9-4FDE0234C451@fugue.com> <429195684.13066.1575996064551@appsuite-gw2.open-xchange.com> <0C729385-1361-460C-9C16-E1BE1680A3E6@fugue.com> <1100636076.15285.1576072588087@appsuite-gw2.open-xchange.com> <4A034991-E5C8-4797-B6BF-9484BB2FA614@fugue.com> <31473650-0872-4EFE-A99C-E3DD4CDBC700@cisco.com> <alpine.LRH.2.21.1912130913480.8529@bofh.nohats.ca>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
X-Outbound-SMTP-Client: 10.61.204.232, [10.61.204.232]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/XCgizWLUOjDh8OKD_R60OdtIkOk>
Subject: Re: [arch-d] [hrpc] New Version Notification for draft-iab-for-the-users-01.txt
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2019 15:51:12 -0000

Hi Paul,

> On 13 Dec 2019, at 15:21, Paul Wouters <paul@nohats.ca> wrote:
> 
> On Fri, 13 Dec 2019, Eliot Lear wrote:
> 
>> It concerns me that Paul Wouters can take from this document that somehow enterprises do not address end user interests.
> 
> Your take on what I wrote seems misinterpreted.
> 
> IETF protocols deliver protections within their protocols for end users
> (or: end to end communication). Whereas the enterprise tries to take
> some of that away to provide its own set of protections for their
> subset of users (called customers or employees).

You can also call them citizens, patients, students, scientists, soldiers, residents, motorists, passengers, first responders, etc.

> My point was that
> while both the end-to-end and customer/employees targets are valid,
> the latter should not come at the expense of the former. The latter
> (presumbly) voluntarilly opt-in for the replacement of protection
> mechanisms. Therefor, the end-to-end principle of all users should
> never be compromised for the betterment of a subset of users.


You can say, “let’s target the individuals accessing the web”, but recognize that in itself is a subset of individuals.  Our works are used in ways we never considered by people we never heard of for purposes we never imagined.  I gave you but a small taste of examples of how that is the case.  To his credit, Mark has recognized these uses when he writes toward the end of Section 2:
   a person
   entering a room with sensors that send data to the Internet has
   interests that may be involved in our deliberations about how those
   sensor readings are handled.
   While such less-direct interactions between people and the Internet
   may be harder to evaluate, this document's concept of end-user
   nonetheless includes such people.
And here’s the kicker: we want those enterprises to use our protocol suites.  For one thing, they’re more likely to get it wrong if they don’t.  More code paths != better code, and some of that code sits in devices that can harm a great many individuals if they malfunction.  Conversely, a more shared understanding helps to advance the state of the art.  Much of what we do is highly esoteric.  How many people on this earth do you think fully understand CBOR or ASN.1?

> 
>>  The example I always give is that of a business who has a regulatory requirement to
>> avoid leaking PII.  There are all sorts of toolsets that MITM communications in order to protect the privacy of account holders.  I think it would be useful for the draft to address this example as a bit of
>> a case study.  One can reasonably argue that an explicit proxy mechanism on at least one side of a communication provides for this, but it begins to encroach on the so-called “end-to-end” views (I put that
>> in quotes because the end-to-end model is often misused in these sorts of discussions).
> 
> The problem I see here, is that this business has the tools to do what
> it wants to its subset of worldwilde users of a protocol to do what it
> deems is best. But it should still not be at the expense of global
> endusers as a group. Do not weaken the protocol for this use case.

In the aggregate of all of these use cases are global.  I am not suggesting that any of this is easy.  I don’t think the draft suggests that either.  But that’s why they pay the IAB the big bucks :-). I do think it means that we have to have a broader understanding of how all of this stuff fits together, and not just go on the war path when someone says they have a use case that you don’t have.  But that also means some understanding on their part as well, such that alternatives can be explored without a conflagration taking place.

I don’t know if Mark thought about it when he reprioritized architectural purity, but that statement can be taken to mean, “don’t just stick to something for because it looks nice that way” or “just because you didn’t arrange the building blocks in some particular way doesn’t mean others won’t.”  The web is one arrangement of those building blocks; a field area network connecting traffic lights is another.  If it fails, we end up in a scene from The Italian Job, only it’s ambulances and fire trucks not getting to move in that traffic jam.

Eliot