From nobody Mon Nov 4 17:13:38 2019 Return-Path: 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 F3D18120874 for ; Mon, 4 Nov 2019 17:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 Qg7h1b1Y5bPp for ; Mon, 4 Nov 2019 17:13:30 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 A7712120911 for ; Mon, 4 Nov 2019 17:13:30 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id n13so2163946pff.1 for ; Mon, 04 Nov 2019 17:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=WssBwUzovYxE8kMNxwxNGkWEYgJBh43GPHZk9UoCpYA=; b=YUhnxTmgc+FWSiqO7tDEestw1hag5mgJW64avGssIEL3DCB2/qoUrgpa3XjC00L74U NfwZVY5VT68ELn/KRW0UEBZBMNLSevMDlD78zFhLx/+IqLYTOav+nADImQnpzB6OHg0n GDse3jw/omxevwo9K+TUnv5SAmFxV9H0N+7FPzRSDMjjE5688c6Dus7EA0iWxfz3YT4Z q4FnVXA0BfllkRSOCseIgjIRK66HIJKUrRZsnLbb9YPrQ41eFYwv27Q/uhXY8DC9sdsk rYRaOoUEHWkCrBySEcRNADafwMiFsI/XjN54hkbDnKN+71HweqJ3Xu0D29dUslMu74b6 kBig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WssBwUzovYxE8kMNxwxNGkWEYgJBh43GPHZk9UoCpYA=; b=e1vmZu7DzbUmzxYR2R9pADANyvF7/QRVk6ADs2wQaeqVT5c221iGYwUp05zO7U7+Eb SWODITIB95aHeKPpBErKwKdnC+nLFc4i6xy66tcXudkwi+ZWYWbAbMTRbhCi1OXX06h+ cGz76ZcnrLhkloRGET3KEYKw9EiTYbn9uRClc5bRNZ1OFd+etRvt3VaP0NCMKfQAWEIa EO9IB6fEXT5jGBA95GDfAdnX/NTHK7wxPFDzDOa30e8zcoQ7coDn3f6demyxmNK9ASkE 5iPNPjmfhod25ibkFEwaPLrdwZkaxPLm5gsbWB3OoVpwgUvD1+gSETcvYkjiEueyi41Y IHPw== X-Gm-Message-State: APjAAAXErRNTZcFCVa3toZ2mDZRu9vf86HFt+Z7WsfWd5naM8E7bAcht +N1l0IyYcxDsdY1dua9N4KowMW5r0lU= X-Google-Smtp-Source: APXvYqxMdcnjWSjvXXTgMthK+Phc3/zhIv369iqGiJ+tf/FlNWhOFP4DYrhi8F10NvHBNkJUlnHC1g== X-Received: by 2002:a17:90a:348c:: with SMTP id p12mr2719853pjb.105.1572916409769; Mon, 04 Nov 2019 17:13:29 -0800 (PST) Received: from [130.216.38.14] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.14]) by smtp.gmail.com with ESMTPSA id r185sm17691096pfr.68.2019.11.04.17.13.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 17:13:28 -0800 (PST) To: iab@iab.org, architecture-discuss@ietf.org References: <157284936054.13440.20144182660413459@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Tue, 5 Nov 2019 14:13:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <157284936054.13440.20144182660413459@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 01:13:38 -0000 Hi, Thanks for the updates, but I still have concerns about this draft. > Abstract ... > For a protocol > that is actively maintained, the robustness principle can, and > should, be avoided. To be blunt, I don't think there is community consensus for this statement. Now the IAB can of course express an opinion, but for something as contentious as this, I think it needs to be labelled as an opinion statement, especially in the Abstract which tends to bias the reader's mindset. Or a more neutral phrasing could be used; for example: For a protocol that is actively maintained, the impact of applying the robustness principle should be carefully considered. > 1. Introduction ... > Ideally, protocol implementations never have to apply the robustness > principle. Or, where it is unavoidable, use of the robustness > principle is viewed as a short term workaround that needs to be > quickly reverted. In an ideal world, all implementations would be perfect, so the robustness principle would be unnecessary. But the very basis for it is that the world *is not* ideal and many implementations *are not* perfect. So, really, what is the point of the first sentence? And no, I don't believe it's a short term workaround. That's like saying: when I've finished testing my Python program, I can take out all the try:... except:... statements because I've fixed all the errors, so I don't need the except: cases any more. On the contrary - good engineers leave the exception handling in for ever. When they don't, planes crash. Is there really a consensus view in the community that "the robustness principle is viewed as a short term workaround"? I don't believe it. > 4. Ecosystem Effects > > Once deviations become entrenched, it can be extremely difficult - if > not impossible - to rectify the situation. I take the point. Sloppy usage of the robustness principle can indeed allow sloppy errors in the spec or in an implmentation to survive. But there's a trade-off that, IMHO, the draft does not recognize: non-robust implementations that do not tolerate sloppy inputs are bad for users trying to accomplish something. It's perfectly reasonable to argue that an implementation should have a strict mode, in which it logs errors etc., in a way that allows the detection of sloppiness at the other end. And I agree that this is of particular value during active development of the protocol and its ecosystem**. But I don't see any developer shipping code to the mass market that has strict mode on by default. I don't see any recognition of this reality in the draft. It's also correct to argue that sloppiness in certain security functions such as algorithm negotiation is never OK. ** If anyone here is masochistic enough to try my prototype of GRASP, they'll discover that its first two questions to the user are: Test mode (many extra diagnostics)? Y/N: Diagnostics for inbound message parse errors? Y/N: So yes, I agree with a lot of the points this draft makes. Regards Brian Carpenter On 04-Nov-19 19:36, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Architecture Board IETF of the IETF. > > Title : The Harmful Consequences of the Robustness Principle > Author : Martin Thomson > Filename : draft-iab-protocol-maintenance-04.txt > Pages : 12 > Date : 2019-11-03 > > Abstract: > The robustness principle, often phrased as "be conservative in what > you send, and liberal in what you accept", has long guided the design > and implementation of Internet protocols. The posture this statement > advocates promotes interoperability in the short term, but can > negatively affect the protocol ecosystem over time. For a protocol > that is actively maintained, the robustness principle can, and > should, be avoided. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 > https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-iab-protocol-maintenance-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Mon Nov 4 17:24:26 2019 Return-Path: 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 813FD120048 for ; Mon, 4 Nov 2019 17:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 WGEZCEIKrQVj for ; Mon, 4 Nov 2019 17:24:24 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5240120033 for ; Mon, 4 Nov 2019 17:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xeUVQwvatllz+LHiahuK9YrSooGT0ckflSfLT/Y/gqA=; b=Mk6lDe8ZMRXiDjn4o4ditCk/1 c+xx46o4nqF9LXLD6kta1/WhJscSpXnQO3DefZPJfuQ8a3E37ZUcPaOz7MkGt9hn5haAb7zYp/xPT VZDq7uD+Ltn0FuVNd2xA7EYEmxkS32RzYy8vJCnpggVQ3EzlrGU3whWGOWCbXGDEcg4Sh87zhHtik +q0MGWo8DgOouYUxUwhlD1PTDqHRmizrwfxiuQ421vAOV++Prt1mHeomcdjOBNzDPx7MjIXeaHyom lRFRcXp2Gbm/LxB8UQt6Q0ynHvBQlku+76RLsugQ43rrwXizdMMygkfwQ4A0cPP01lbHuJvNX7Enu tMNp/Pv1A==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58694 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iRna0-000pvV-19; Mon, 04 Nov 2019 20:24:24 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Mon, 4 Nov 2019 17:24:19 -0800 Cc: iab@iab.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157284936054.13440.20144182660413459@ietfa.amsl.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 01:24:26 -0000 > On Nov 4, 2019, at 5:13 PM, Brian E Carpenter = wrote: >=20 > Hi, >=20 > Thanks for the updates, but I still have concerns about this draft. >=20 >> Abstract > .... >> For a protocol >> that is actively maintained, the robustness principle can, and >> should, be avoided. >=20 > To be blunt, I don't think there is community consensus for this > statement. Now the IAB can of course express an opinion, but for > something as contentious as this, I think it needs to be labelled > as an opinion statement, especially in the Abstract which tends > to bias the reader's mindset. Or a more neutral phrasing could > be used; for example: >=20 > For a protocol that is actively maintained, the impact of > applying the robustness principle should be carefully considered. FWIW, even that should have the =E2=80=9Cin the IAB=E2=80=99s opinion=E2=80= =99 as a preface. However, if that=E2=80=99s not a requirement for ALL such docs out of = the IAB, then it should be. These aren=E2=80=99t consensus documents. Joe From nobody Tue Nov 5 14:58:37 2019 Return-Path: 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 8B9B712008F for ; Tue, 5 Nov 2019 14:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=r4gwqwVA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bGH1yDEp 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 TP_JGC6-uENT for ; Tue, 5 Nov 2019 14:58:33 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D774E120025 for ; Tue, 5 Nov 2019 14:58:33 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 517D35B4; Tue, 5 Nov 2019 17:58:33 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 05 Nov 2019 17:58:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=XNXPII2SoWmpeqMKQcUx7ecStka5FuTiwe27e4JPAN4=; b=r4gwqwVA BbaulTcIj0NUTKVHMl2ocM30WxNaMttht9hLt7X5D8JY8MWuY5dZciy3FZkRRzQx BlSaCrBoD1bQ4k1fCGQ689naAlf2B6KDlg77oJ4W3Avib8329XkDY5osEdTaWFn+ g3jWUZbIprenhQc8uUuRQB3cd+7jje/0xp2YHcf2g84LM9+3CNAWUsF/6L7XV84d afo6WQFQuXMYV1qvQ9S/1DIhvzs2ckSKlZ3uJr2eAFss7eC1BXqyX9OY2+8e2ZDo K3jQ0FA6DUUM/ax9wk9QF5DMCyDO9G7JueE6MqfrvdL1odDgx0k3QRS91vPnrNc8 wPKj08n07kGQng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=XNXPII2SoWmpeqMKQcUx7ecStka5F uTiwe27e4JPAN4=; b=bGH1yDEplK2N07e1aVlCYWBUTXqKL4rFeiYf+zIsjiEi6 fv7LQScoH/HZXYLh0l5dwwlsXiE2CTXVxpGWfkK7Hc+mV2trnJvXpSlV0kAUoLNn KhQNkWH5dMAy3/w5JsAdhAtBfXY5d1VUW5d4imKZzgkJnqrUhEZWDSjEd/XD00xU UsaNgmfl0I97fgBvBUEEfsSgjD8ZX7M5xBtVPJ5zeW2XuB8TbZQ4w/sCrL2uK2QQ IBXcDTEgvTPJ42WkJTdPtvsPIARHnJvqVuLh+3CM1Sfz5iEAok7i7MNylpS4k8yY GntRHCkRHmmfdNOYVjlzK/2KPXJ7h8WUIXjfRDqtg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduiedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesthdtredtreertdenucfhrhhomhepfdforghrthhi nhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E158BE00A5; Tue, 5 Nov 2019 17:58:29 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <3db77634-6edf-4047-b758-f83a462420b7@www.fastmail.com> Date: Wed, 06 Nov 2019 09:58:08 +1100 From: "Martin Thomson" To: architecture-discuss@ietf.org, "Jari Arkko" Content-Type: text/plain Archived-At: Subject: [arch-d] Centralization or diversity 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 22:58:36 -0000 Having just read draft-arkko-arch-infrastructure-centralisation, I was struck by an observation. The draft specifically calls out the notion of a single point of failure being a problem. But my experience with centralized services is that they aren't centralized in the fault tolerance sense. If I look at the big services, that scale is only achieved with careful distributed systems design. Name any modern service of even modest scale and you generally find excellent fault tolerance. This draft really wants to say something less negative: that it values diversity on multiple axes. The draft covers: * fault domains * geopolitical * organizational To which I might add: * geographic * implementation * infrastructure (power, network, hardware) There are probably areas of diversity that are less valuable. Protocol diversity has the effect of forcing divisions. I tend to think that cryptographic diversity divides the limited resources available for protecting and assuring system integrity. And diversifying where standardization happens is almost certainly bad [RFC5704]. Finally, I don't like the emphasis on DNS in this document. It only serves to sensationalize. From nobody Wed Nov 6 13:14:54 2019 Return-Path: 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 2A26A1208DB; Wed, 6 Nov 2019 13:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1aIhdkpKw9yc; Wed, 6 Nov 2019 13:14:44 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679E51208F5; Wed, 6 Nov 2019 13:14:44 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xA6L9tjG001987; Wed, 6 Nov 2019 16:14:41 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2w45seg9y7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Nov 2019 16:14:33 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xA6LEIYu027104; Wed, 6 Nov 2019 16:14:18 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xA6LEAOH026831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Nov 2019 16:14:10 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id 1CB994009E7E; Wed, 6 Nov 2019 21:14:10 +0000 (GMT) Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (unknown [130.9.129.148]) by zlp27128.vci.att.com (Service) with ESMTPS id 000944009E7D; Wed, 6 Nov 2019 21:14:09 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.44]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0468.000; Wed, 6 Nov 2019 16:14:09 -0500 From: "BRUNGARD, DEBORAH A" To: Brian E Carpenter , "iab@iab.org" , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt Thread-Index: AQHVktorQzqaBndTdEufGR0WueBBLad8Go4AgAJ+wLA= Date: Wed, 6 Nov 2019 21:14:08 +0000 Message-ID: References: <157284936054.13440.20144182660413459@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.249.177] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911060207 Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 21:14:53 -0000 KzEgb24gQnJpYW4ncyBwb2ludHMNCg0KSSBtYXkgYmUgbWlzLXJlYWRpbmcgQnJpYW4ncyBjb25j bHVzaW9uLCBhbmQgd2lsbCB0YWtlIHRoZSBsaWJlcnR5IHRvIHJlLXBocmFzZSAtICJldmVuIGZv ciBhIHByb3RvY29sIGFjdGl2ZWx5IG1haW50YWluZWQsIHdlIGFyZSBub3QgcGVyZmVjdCIuDQoN Ckkgc3RpbGwgaGF2ZSBkaWZmaWN1bHR5IHdpdGggdGhlIHRpdGxlIG9mIHRoaXMgZG9jdW1lbnQu IEFzIEJyaWFuIHNheXMsIG11Y2ggb2YgdGhlIGNvbnRlbnQgb2YgdGhlIGRyYWZ0IGlzIGdvb2Qu IEFjdGl2ZS9yZXNwb25zaWJsZSBtYWludGVuYW5jZSBvbiBvdXIgcHJvdG9jb2xzIC0gbm90aGlu ZyB3cm9uZyAtIHRvdGFsbHkgYWdyZWUuIEJ1dCB0byBzYXkgInRoZSByb2J1c3RuZXNzIHByaW5j aXBsZSBpcyBoYXJtZnVsIiBiZWNhdXNlIGl0IGVuY291cmFnZXMgaW50ZXJvcGVyYWJpbGl0eSBh bmQgZGlzY291cmFnZXMgcHJvcGVyIG1haW50ZW5hbmNlL25ldyBpbXBsZW1lbnRhdGlvbnMgZG9l c24ndCBwYXJzZSBmb3IgbWUuIFRoZSB0aXRsZSwgd2hpbGUgYXR0ZW50aW9uIGdldHRpbmcsIHNp bXBseSBkb2Vzbid0IG1ha2Ugc2Vuc2UuDQoNCkZvciBtZSwgdGhlIHJvYnVzdG5lc3MgcHJpbmNp cGxlIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggcHJldmVudGluZyBuZXcgZXh0ZW5zaW9ucyBvbiBh IHByb3RvY29sLCBpdCBoYXMgZXZlcnl0aGluZyB0byBkbyB3aXRoIHByb3RlY3RpbmcgZXhpc3Rp bmcgZGVwbG95bWVudHMuIFRoZSBkb2N1bWVudCdzIHByb3Bvc2FsICJDaG9vc2luZyB0byBnZW5l cmF0ZSBmYXRhbCBlcnJvcnMgZm9yIHVuc3BlY2lmaWVkIGNvbmRpdGlvbnMiIG1heSBiZSBhcHBy b3ByaWF0ZSBmb3Igc29tZSBwcm90b2NvbHMsIGl0IHdvdWxkIGNhdXNlIGEgbWVsdCBkb3duIG9m IHRoZSBuZXR3b3JrIGZvciBvdGhlciBwcm90b2NvbHMuIE9uZSBvZiBteSB3b3JraW5nIGdyb3Vw cyBjdXJyZW50bHkgaXMgZG9pbmcgYSAiZml4IiAtIGFuZCBvbmx5IGJlY2F1c2Ugb2YgdGhlIHJv YnVzdG5lc3MgcHJpbmNpcGxlLCB0aGVyZSBoYXZlIGJlZW4gbm8gaXNzdWVzIHdpdGggY3VycmVu dCBkZXBsb3ltZW50cy4gU3VyZSwgd2hlbiB0aGUgZG9jdW1lbnQgd2FzIGZpcnN0IGRvbmUsIGl0 IHNob3VsZCBoYXZlIGFsbCBiZWVuIHBlcmZlY3QuIEJ1dCB3ZSBhcmUgbm90IHBlcmZlY3QsIGV2 ZW4gYWZ0ZXIgYWxsIHRoZSBBcmVhIERpcmVjdG9yYXRlIHJldmlld3MgYW5kIElFU0cgcmV2aWV3 c/CfmIogVGhlb3J5IHZzLiBwcmFjdGljZS4NCg0KUkZDMTk1OCBpcyBub3QgdGhlIG9ubHkgUkZD IGNpdGluZyB0aGUgcm9idXN0bmVzcyBwcmluY2lwbGUgLSBpdCBpcyBpbiBtYW55IG1hbnkgZG9j dW1lbnRzLiBIb3cgYWJvdXQgdGhpcyBvbmUgb24gIlRoZSBUd2VsdmUgTmV0d29ya2luZyBUcnV0 aHMiLCB1bmZvcnR1bmF0ZWx5IGl0IGlzIG5vdCBhcyBlYXNpbHkgc2V0IHRvIHR1bmUgYXMgYSBz aW1pbGFyIDEyLWRheXMgdHVuZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3Jm YzE5MjUvDQoNClJlZ2FyZHMsDQpEZWJvcmFoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBBcmNoaXRlY3R1cmUtZGlzY3VzcyA8YXJjaGl0ZWN0dXJlLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJyaWFuIEUgQ2FycGVudGVyDQpTZW50OiBNb25kYXks IE5vdmVtYmVyIDA0LCAyMDE5IDg6MTMgUE0NClRvOiBpYWJAaWFiLm9yZzsgYXJjaGl0ZWN0dXJl LWRpc2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbYXJjaC1kXSBJLUQgQWN0aW9uOiBkcmFm dC1pYWItcHJvdG9jb2wtbWFpbnRlbmFuY2UtMDQudHh0DQoNCkhpLA0KDQpUaGFua3MgZm9yIHRo ZSB1cGRhdGVzLCBidXQgSSBzdGlsbCBoYXZlIGNvbmNlcm5zIGFib3V0IHRoaXMgZHJhZnQuDQoN Cj4gQWJzdHJhY3QNCi4uLi4NCj4gICAgRm9yIGEgcHJvdG9jb2wNCj4gICAgdGhhdCBpcyBhY3Rp dmVseSBtYWludGFpbmVkLCB0aGUgcm9idXN0bmVzcyBwcmluY2lwbGUgY2FuLCBhbmQNCj4gICAg c2hvdWxkLCBiZSBhdm9pZGVkLg0KDQpUbyBiZSBibHVudCwgSSBkb24ndCB0aGluayB0aGVyZSBp cyBjb21tdW5pdHkgY29uc2Vuc3VzIGZvciB0aGlzIHN0YXRlbWVudC4gTm93IHRoZSBJQUIgY2Fu IG9mIGNvdXJzZSBleHByZXNzIGFuIG9waW5pb24sIGJ1dCBmb3Igc29tZXRoaW5nIGFzIGNvbnRl bnRpb3VzIGFzIHRoaXMsIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgbGFiZWxsZWQgYXMgYW4gb3Bp bmlvbiBzdGF0ZW1lbnQsIGVzcGVjaWFsbHkgaW4gdGhlIEFic3RyYWN0IHdoaWNoIHRlbmRzIHRv IGJpYXMgdGhlIHJlYWRlcidzIG1pbmRzZXQuIE9yIGEgbW9yZSBuZXV0cmFsIHBocmFzaW5nIGNv dWxkIGJlIHVzZWQ7IGZvciBleGFtcGxlOg0KDQpGb3IgYSBwcm90b2NvbCB0aGF0IGlzIGFjdGl2 ZWx5IG1haW50YWluZWQsIHRoZSBpbXBhY3Qgb2YgYXBwbHlpbmcgdGhlIHJvYnVzdG5lc3MgcHJp bmNpcGxlIHNob3VsZCBiZSBjYXJlZnVsbHkgY29uc2lkZXJlZC4NCg0KPiAxLiAgSW50cm9kdWN0 aW9uDQouLi4uDQo+ICAgIElkZWFsbHksIHByb3RvY29sIGltcGxlbWVudGF0aW9ucyBuZXZlciBo YXZlIHRvIGFwcGx5IHRoZSByb2J1c3RuZXNzDQo+ICAgIHByaW5jaXBsZS4gIE9yLCB3aGVyZSBp dCBpcyB1bmF2b2lkYWJsZSwgdXNlIG9mIHRoZSByb2J1c3RuZXNzDQo+ICAgIHByaW5jaXBsZSBp cyB2aWV3ZWQgYXMgYSBzaG9ydCB0ZXJtIHdvcmthcm91bmQgdGhhdCBuZWVkcyB0byBiZQ0KPiAg ICBxdWlja2x5IHJldmVydGVkLg0KDQpJbiBhbiBpZGVhbCB3b3JsZCwgYWxsIGltcGxlbWVudGF0 aW9ucyB3b3VsZCBiZSBwZXJmZWN0LCBzbyB0aGUgcm9idXN0bmVzcyBwcmluY2lwbGUgd291bGQg YmUgdW5uZWNlc3NhcnkuIEJ1dCB0aGUgdmVyeSBiYXNpcyBmb3IgaXQgaXMgdGhhdCB0aGUgd29y bGQgKmlzIG5vdCogaWRlYWwgYW5kIG1hbnkgaW1wbGVtZW50YXRpb25zICphcmUNCm5vdCogcGVy ZmVjdC4gU28sIHJlYWxseSwgd2hhdCBpcyB0aGUgcG9pbnQgb2YgdGhlIGZpcnN0IHNlbnRlbmNl Pw0KDQpBbmQgbm8sIEkgZG9uJ3QgYmVsaWV2ZSBpdCdzIGEgc2hvcnQgdGVybSB3b3JrYXJvdW5k LiBUaGF0J3MgbGlrZQ0Kc2F5aW5nOiB3aGVuIEkndmUgZmluaXNoZWQgdGVzdGluZyBteSBQeXRo b24gcHJvZ3JhbSwgSSBjYW4gdGFrZSBvdXQgYWxsIHRoZSB0cnk6Li4uIGV4Y2VwdDouLi4gc3Rh dGVtZW50cyBiZWNhdXNlIEkndmUgZml4ZWQgYWxsIHRoZSBlcnJvcnMsIHNvIEkgZG9uJ3QgbmVl ZCB0aGUgZXhjZXB0OiBjYXNlcyBhbnkgbW9yZS4NCg0KT24gdGhlIGNvbnRyYXJ5IC0gZ29vZCBl bmdpbmVlcnMgbGVhdmUgdGhlIGV4Y2VwdGlvbiBoYW5kbGluZyBpbiBmb3IgZXZlci4gV2hlbiB0 aGV5IGRvbid0LCBwbGFuZXMgY3Jhc2guDQoNCklzIHRoZXJlIHJlYWxseSBhIGNvbnNlbnN1cyB2 aWV3IGluIHRoZSBjb21tdW5pdHkgdGhhdCAidGhlIHJvYnVzdG5lc3MgcHJpbmNpcGxlIGlzIHZp ZXdlZCBhcyBhIHNob3J0IHRlcm0gd29ya2Fyb3VuZCI/DQpJIGRvbid0IGJlbGlldmUgaXQuDQoN Cj4gNC4gIEVjb3N5c3RlbSBFZmZlY3RzDQo+IA0KPiAgICBPbmNlIGRldmlhdGlvbnMgYmVjb21l IGVudHJlbmNoZWQsIGl0IGNhbiBiZSBleHRyZW1lbHkgZGlmZmljdWx0IC0gaWYNCj4gICAgbm90 IGltcG9zc2libGUgLSB0byByZWN0aWZ5IHRoZSBzaXR1YXRpb24uDQoNCkkgdGFrZSB0aGUgcG9p bnQuIFNsb3BweSB1c2FnZSBvZiB0aGUgcm9idXN0bmVzcyBwcmluY2lwbGUgY2FuIGluZGVlZCBh bGxvdyBzbG9wcHkgZXJyb3JzIGluIHRoZSBzcGVjIG9yIGluIGFuIGltcGxtZW50YXRpb24gdG8g c3Vydml2ZS4gQnV0IHRoZXJlJ3MgYSB0cmFkZS1vZmYgdGhhdCwgSU1ITywgdGhlIGRyYWZ0IGRv ZXMgbm90IHJlY29nbml6ZTogbm9uLXJvYnVzdCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3Qg dG9sZXJhdGUgc2xvcHB5IGlucHV0cyBhcmUgYmFkIGZvciB1c2VycyB0cnlpbmcgdG8gYWNjb21w bGlzaCBzb21ldGhpbmcuDQoNCkl0J3MgcGVyZmVjdGx5IHJlYXNvbmFibGUgdG8gYXJndWUgdGhh dCBhbiBpbXBsZW1lbnRhdGlvbiBzaG91bGQgaGF2ZSBhIHN0cmljdCBtb2RlLCBpbiB3aGljaCBp dCBsb2dzIGVycm9ycyBldGMuLCBpbiBhIHdheSB0aGF0IGFsbG93cyB0aGUgZGV0ZWN0aW9uIG9m IHNsb3BwaW5lc3MgYXQgdGhlIG90aGVyIGVuZC4gQW5kIEkgYWdyZWUgdGhhdCB0aGlzIGlzIG9m IHBhcnRpY3VsYXIgdmFsdWUgZHVyaW5nIGFjdGl2ZSBkZXZlbG9wbWVudCBvZiB0aGUgcHJvdG9j b2wgYW5kIGl0cyBlY29zeXN0ZW0qKi4gQnV0IEkgZG9uJ3Qgc2VlIGFueSBkZXZlbG9wZXIgc2hp cHBpbmcgY29kZSB0byB0aGUgbWFzcyBtYXJrZXQgdGhhdCBoYXMgc3RyaWN0IG1vZGUgb24gYnkg ZGVmYXVsdC4gSSBkb24ndCBzZWUgYW55IHJlY29nbml0aW9uIG9mIHRoaXMgcmVhbGl0eSBpbiB0 aGUgZHJhZnQuDQoNCkl0J3MgYWxzbyBjb3JyZWN0IHRvIGFyZ3VlIHRoYXQgc2xvcHBpbmVzcyBp biBjZXJ0YWluIHNlY3VyaXR5IGZ1bmN0aW9ucyBzdWNoIGFzIGFsZ29yaXRobSBuZWdvdGlhdGlv biBpcyBuZXZlciBPSy4NCg0KKiogSWYgYW55b25lIGhlcmUgaXMgbWFzb2NoaXN0aWMgZW5vdWdo IHRvIHRyeSBteSBwcm90b3R5cGUgb2YgR1JBU1AsIHRoZXknbGwgZGlzY292ZXIgdGhhdCBpdHMg Zmlyc3QgdHdvIHF1ZXN0aW9ucyB0byB0aGUgdXNlciBhcmU6DQoNClRlc3QgbW9kZSAobWFueSBl eHRyYSBkaWFnbm9zdGljcyk/IFkvTjoNCkRpYWdub3N0aWNzIGZvciBpbmJvdW5kIG1lc3NhZ2Ug cGFyc2UgZXJyb3JzPyBZL046DQoNClNvIHllcywgSSBhZ3JlZSB3aXRoIGEgbG90IG9mIHRoZSBw b2ludHMgdGhpcyBkcmFmdCBtYWtlcy4NCg0KUmVnYXJkcw0KICAgQnJpYW4gQ2FycGVudGVyDQoN Ck9uIDA0LU5vdi0xOSAxOTozNiwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiAN Cj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m IHRoZSBJbnRlcm5ldCBBcmNoaXRlY3R1cmUgQm9hcmQgSUVURiBvZiB0aGUgSUVURi4NCj4gDQo+ ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogVGhlIEhhcm1mdWwgQ29uc2VxdWVuY2VzIG9mIHRo ZSBSb2J1c3RuZXNzIFByaW5jaXBsZQ0KPiAgICAgICAgIEF1dGhvciAgICAgICAgICA6IE1hcnRp biBUaG9tc29uDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pYWItcHJvdG9jb2wtbWFpbnRl bmFuY2UtMDQudHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiAxMg0KPiAJRGF0ZSAgICAgICAgICAg IDogMjAxOS0xMS0wMw0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoZSByb2J1c3RuZXNzIHByaW5j aXBsZSwgb2Z0ZW4gcGhyYXNlZCBhcyAiYmUgY29uc2VydmF0aXZlIGluIHdoYXQNCj4gICAgeW91 IHNlbmQsIGFuZCBsaWJlcmFsIGluIHdoYXQgeW91IGFjY2VwdCIsIGhhcyBsb25nIGd1aWRlZCB0 aGUgZGVzaWduDQo+ICAgIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBJbnRlcm5ldCBwcm90b2NvbHMu ICBUaGUgcG9zdHVyZSB0aGlzIHN0YXRlbWVudA0KPiAgICBhZHZvY2F0ZXMgcHJvbW90ZXMgaW50 ZXJvcGVyYWJpbGl0eSBpbiB0aGUgc2hvcnQgdGVybSwgYnV0IGNhbg0KPiAgICBuZWdhdGl2ZWx5 IGFmZmVjdCB0aGUgcHJvdG9jb2wgZWNvc3lzdGVtIG92ZXIgdGltZS4gIEZvciBhIHByb3RvY29s DQo+ICAgIHRoYXQgaXMgYWN0aXZlbHkgbWFpbnRhaW5lZCwgdGhlIHJvYnVzdG5lc3MgcHJpbmNp cGxlIGNhbiwgYW5kDQo+ICAgIHNob3VsZCwgYmUgYXZvaWRlZC4NCj4gDQo+IA0KPiBUaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5p ZXRmLg0KPiBvcmdfZG9jX2RyYWZ0LTJEaWFiLTJEcHJvdG9jb2wtMkRtYWludGVuYW5jZV8mZD1E d0lDQWcmYz1MRllaLW85X0hVTWVNDQo+IFRTUWljdmpJZyZyPTZVaEdwVzlsd2k5ZE03allseFhE OHcmbT1LYnBmYmZocTlQbGlUUDg2YlY1Zldqc1JtU3pDQmVESnoNCj4geW9WYVBIVmhjTSZzPWti U1pNaXIyRUQtOTgySWdNc1pTbXEyRzBpUFVkdGhTTTJPbUhrbTdXNDQmZT0NCj4gDQo+IFRoZXJl IGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19o dA0KPiBtbF9kcmFmdC0yRGlhYi0yRHByb3RvY29sLTJEbWFpbnRlbmFuY2UtMkQwNCZkPUR3SUNB ZyZjPUxGWVotbzlfSFVNZU1UDQo+IFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZt PUticGZiZmhxOVBsaVRQODZiVjVmV2pzUm1TekNCZURKenkNCj4gb1ZhUEhWaGNNJnM9eU9CWUhp by16cTlkcmpWLU5vWXNoLTd6RG0xZGJoVnRXR0RuWFgtc1F0NCZlPQ0KPiBodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYu DQo+IG9yZ19kb2NfaHRtbF9kcmFmdC0yRGlhYi0yRHByb3RvY29sLTJEbWFpbnRlbmFuY2UtMkQw NCZkPUR3SUNBZyZjPUxGWVoNCj4gLW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdq WWx4WEQ4dyZtPUticGZiZmhxOVBsaVRQODZiVjVmV2pzUg0KPiBtU3pDQmVESnp5b1ZhUEhWaGNN JnM9Y2ZxRGU4VU9kS01MWU9TWmF5S1c1cVhvUnRndl9mT0tKSlZxelhiSWMyOCZlPQ0KPiANCj4g QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19yZmNkDQo+IGlmZi0zRnVybDItM0RkcmFmdC0yRGlhYi0yRHByb3RvY29sLTJEbWFpbnRl bmFuY2UtMkQwNCZkPUR3SUNBZyZjPUxGWVoNCj4gLW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BX OWx3aTlkTTdqWWx4WEQ4dyZtPUticGZiZmhxOVBsaVRQODZiVjVmV2pzUg0KPiBtU3pDQmVESnp5 b1ZhUEhWaGNNJnM9XzJHZzVqOWxFNE5KLWZDNVVwdmpSOTJETDg3LUZNRXpuazM3cmxMRmY1MCZl PQ0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1mdHAtM0FfX2Z0cC5p ZXRmLm9yZ19pbnRlcm4NCj4gZXQtMkRkcmFmdHNfJmQ9RHdJQ0FnJmM9TEZZWi1vOV9IVU1lTVRT UWljdmpJZyZyPTZVaEdwVzlsd2k5ZE03allseFhEOA0KPiB3Jm09S2JwZmJmaHE5UGxpVFA4NmJW NWZXanNSbVN6Q0JlREp6eW9WYVBIVmhjTSZzPWZLaVR4VHdkQnR2LTBENVpkV1NYDQo+IF95TEJk Z0FWLXdlanQ0SUh6VEFxbmVjJmU9DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+IEktRC1B bm5vdW5jZUBpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsDQo+IG1hbl9saXN0aW5mb19pLTJEZC0y RGFubm91bmNlJmQ9RHdJQ0FnJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPTZVaEcNCj4gcFc5 bHdpOWRNN2pZbHhYRDh3Jm09S2JwZmJmaHE5UGxpVFA4NmJWNWZXanNSbVN6Q0JlREp6eW9WYVBI VmhjTSZzPWlaLQ0KPiBVdkhXb3ZtN3pMY0FDNGhDdWpvYU9zU2hVQURRdFo2cVA3alpfdFo4JmU9 DQo+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiANCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pZXRmLm9yZ19zaGFkbw0KPiB3Lmh0 bWwmZD1Ed0lDQWcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdqWWx4 WEQ4dyZtPUtiDQo+IHBmYmZocTlQbGlUUDg2YlY1Zldqc1JtU3pDQmVESnp5b1ZhUEhWaGNNJnM9 Y1JlRi15QTlRd3RyVjY0ZGdIZENEREhHTWcNCj4gRklXRDEyZXc0TjFwQ2dZN00mZT0gb3IgDQo+ IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1mdHAtM0FfX2Z0cC5p ZXRmLm9yZ19pZXRmXzENCj4gc2hhZG93LTJEc2l0ZXMudHh0JmQ9RHdJQ0FnJmM9TEZZWi1vOV9I VU1lTVRTUWljdmpJZyZyPTZVaEdwVzlsd2k5ZE03ag0KPiBZbHhYRDh3Jm09S2JwZmJmaHE5UGxp VFA4NmJWNWZXanNSbVN6Q0JlREp6eW9WYVBIVmhjTSZzPVphTUFNT0RHMUxZVC02DQo+IC12RWNq aDRhZG9wR080emt5OEtiYjBwUHNWVm4wJmU9DQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQXJjaGl0ZWN0dXJlLWRpc2N1c3MgbWFpbGluZyBs aXN0DQpBcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19hcmNoaXRlY3R1cmUtMkRkaXNjdXNzJmQ9RHdJQ0FnJmM9TEZZWi1vOV9IVU1lTVRTUWlj dmpJZyZyPTZVaEdwVzlsd2k5ZE03allseFhEOHcmbT1LYnBmYmZocTlQbGlUUDg2YlY1Zldqc1Jt U3pDQmVESnp5b1ZhUEhWaGNNJnM9a2dkUVNRZXpDVjY0QTgxY3p4eEJLRGFDcS13RFMwbEc4eWxf WHd2WVJSYyZlPQ0K From nobody Wed Nov 6 13:46:27 2019 Return-Path: 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 E6136120100 for ; Wed, 6 Nov 2019 13:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 bzoMSjjazeEH for ; Wed, 6 Nov 2019 13:46:23 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0F9120145 for ; Wed, 6 Nov 2019 13:46:23 -0800 (PST) Received: from [192.168.217.102] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 477g8Y3T4bzyRf; Wed, 6 Nov 2019 22:46:21 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 6 Nov 2019 22:46:21 +0100 Cc: Brian E Carpenter , "iab@iab.org" , "architecture-discuss@ietf.org" X-Mao-Original-Outgoing-Id: 594769579.3696049-3c98ed31c9345182d0f9102e17ee8a1e Content-Transfer-Encoding: quoted-printable Message-Id: <2D4229AF-0217-4E8F-AD2B-C7D41DF98BA5@tzi.org> References: <157284936054.13440.20144182660413459@ietfa.amsl.com> To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 21:46:26 -0000 On Nov 6, 2019, at 22:14, BRUNGARD, DEBORAH A wrote: >=20 > But to say "the robustness principle is harmful" (I apologize if I sound like a broken record:) =E2=80=9CCommon misunderstandings of the robustness principle are = harmful=E2=80=9D Or misapplications. As with all principles, the robustness principle = has its proper domain. And we now know more about the harmful effects of misapplying it than we = did in 1983. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Nov 6 14:26:25 2019 Return-Path: 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 E49D4120100 for ; Wed, 6 Nov 2019 14:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 3TqNQN-CstL0 for ; Wed, 6 Nov 2019 14:26:22 -0800 (PST) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 0943712002F for ; Wed, 6 Nov 2019 14:26:22 -0800 (PST) Received: by mail-il1-x131.google.com with SMTP id z12so11250473ilp.2 for ; Wed, 06 Nov 2019 14:26:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8OYLnJPdOfB0u5jLEuVo4J0IS76hn+D96zMze4E5A2Y=; b=NTOTLE6MY2fNjhUCpe7OP8Z6pCgWVCvrbioDAtikz5OY0saAmOvzIZhPyVIzMarbuP 4RRgk8nDpVMJFjxPPcZiWsaVy+tCTy76B+XWEabyPlZZbkVxdF7ERkhDWzGDN9l6PLk/ MZ5sZurTTZAx+zFstlFHJ3ySsvq1JhVIbUMJvA26uzAdMZhXqylAwmwkDh3s6PY1OjOi GXlNurrH61hn2KrD7p0vgpAd2SQFcSzVdDESxtuSuHc6WgYIMJdnZ2ezgHGNbAqXZ1Nw zo7t6/aaJNRYpYkZ4wBysBOFDOAfANVRFS9ua7QzEdO5VhWZSfuzGshycyDUqgpU7JQF aVrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8OYLnJPdOfB0u5jLEuVo4J0IS76hn+D96zMze4E5A2Y=; b=HeYXxdJ6foJfXwWEtcILElUAjF13hnylg+v95TH5l3zlJbhHWElptoJkNVEqAYQmRn rPXfoLflPbo6ehQoA66MJNYQqFVyXQGSiA7DQT1iS9bHkqmaAxpdZHy9+LPm1Ha24HfL GUPvER2rzDVO0axg1RkmwhBxikE0IpCz4wX5FBW0kIBUSGkR4XNXG3th529GzazcICVC hT2mxYi1YEweAxyQfKAvZ8B/jON7EAMtmWhuudAZwrUKQhgmAYkIkGhyKQDLPCp4J5K8 BR205W3I3NHUCT2ugtfbLGxyflYnLfIdHDMPR3mc9EFNIMPJweRtH+kDeCGe0RQqtmsn JKLA== X-Gm-Message-State: APjAAAUfXGOs8DMsinHG/6sDIx37Vbu8/SIHnatCirWXL0b90FfpeYZa inG1Ls63caJzzHlR6k+Dzphym0l0vDh6VpuVZUk= X-Google-Smtp-Source: APXvYqywIWHfasIOhePbQQz+grMM0alweF9G1hoiMKtSIdwv/N1YYPWlIlP8eBxheaSZ8G9LauC7y7bzlRUXlDjiMoA= X-Received: by 2002:a05:6e02:cc1:: with SMTP id c1mr122721ilj.139.1573079180741; Wed, 06 Nov 2019 14:26:20 -0800 (PST) MIME-Version: 1.0 References: <157284936054.13440.20144182660413459@ietfa.amsl.com> In-Reply-To: From: Ted Hardie Date: Wed, 6 Nov 2019 14:25:50 -0800 Message-ID: To: "BRUNGARD, DEBORAH A" Cc: Brian E Carpenter , "iab@iab.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c594ce0596b5097a" Archived-At: Subject: Re: [arch-d] [IAB] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 22:26:24 -0000 --000000000000c594ce0596b5097a Content-Type: text/plain; charset="UTF-8" Hi Deborah, On Wed, Nov 6, 2019 at 1:15 PM BRUNGARD, DEBORAH A wrote: > > > For me, the robustness principle has nothing to do with preventing new > extensions on a protocol, it has everything to do with protecting existing > deployments. The document's proposal "Choosing to generate fatal errors for > unspecified conditions" may be appropriate for some protocols, it would > cause a melt down of the network for other protocols. One of my working > groups currently is doing a "fix" - and only because of the robustness > principle, there have been no issues with current deployments. > > As Carsten says downthread, some of the applications of the robustness principle are obviously good. Some, not so much. I think we all agree, though, that maintaining points of extension is both good and, ultimately, necessary if the Internet is going to continue to change and grow. One issue is that some of the points of extension get eaten up by poor applications of the robustness principle. If you reserve a code point but ignore its use in deployments because it has no meaning, it can really never have a meaning until a forklift upgrade arrives, as you can't tell which bits ignore it and which use it. Given our current rate of ossification, that is a problem. I don't know the situation you allude to above, and it may not apply there. If you can send text on how to distinguish the situation you see and the doc describes, we'd be grateful. regards, Ted --000000000000c594ce0596b5097a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Deborah,

On Wed, Nov 6, 2019 at 1:1= 5 PM BRUNGARD, DEBORAH A <db3546@att.c= om> wrote:
To: Ted Hardie CC: Brian E Carpenter , "iab@iab.org" , "architecture-discuss@ietf.org" Thread-Topic: [IAB] [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt Thread-Index: AQHVktorQzqaBndTdEufGR0WueBBLad8Go4AgAJ+wLCAAHcYAIAHZrLg Date: Mon, 11 Nov 2019 21:28:20 +0000 Message-ID: References: <157284936054.13440.20144182660413459@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.194.42] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8A3AB1B94MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-11_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911110186 Archived-At: Subject: Re: [arch-d] [IAB] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 21:28:34 -0000 --_000_F64C10EAA68C8044B33656FA214632C8A3AB1B94MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVkLA0KDQpXaXRoIHRoZSB1cGNvbWluZyBtZWV0aW5nLCBJ4oCZdmUgYmVlbiBzd2FtcGVk IHdpdGggcHJlcHMsIGhvcGVmdWxseSBkdXJpbmcgdGhlIG1lZXRpbmcgd2VlaywgY2FuIGZpbmQg c29tZSB0aW1lIHRvIHRhbGsgYXMgbXVjaCBlYXNpZXIgdGhhbiBlbWFpbC4NCg0KSSBhZ3JlZSB3 aXRoIHdoYXQgeW91IGhhdmUgYmVsb3cgYXMgbGlrZWx5IHRvIGJlIGFwcGxpY2FibGUgZm9yIHNv bWUgcHJvdG9jb2xzIGJ1dCBJIHdvdWxkIGJlIHZlcnkgdW5jb21mb3J0YWJsZSB0byBzYXkgaXQg aXMgdW5pdmVyc2FsbHkgYXBwbGljYWJsZS4gSW4gcm91dGluZywgd2UgZG8gbWFueSB0aW1lcyBn ZW5lcmF0ZSByZXNwb25zZXMgZm9yIG5vbi1yZWNvZ25pemVkIHJlcXVlc3RzIGJ1dCB0aGUgcmVz cG9uc2UgZG9lcyBub3QgbmVjZXNzYXJpbHkgcmVzdWx0IGluIGEgZmF0YWwgZXJyb3IuIEFuZCBm b3IgbWFueSDigJxiaXRz4oCdIGUuZy4gZmxhZ3MsIGRlcGVuZGluZyBvbiB0aGUgaW1wYWN0LCBy b3V0aW5nIG1heS9tYXkgbm90IGhhdmUgYW4gZXJyb3IgbWVzc2FnZSwgOg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLXJlZ2lzdHJpZXMt dXBkYXRlLw0KDQpBbiBleGFtcGxlIG9mIHdoZXJlIHdlIHdlcmUgbm90IOKAnHBlcmZlY3TigJ0g b24gZmlyc3Qgc3BlY2lmeWluZyAoYW5kIGFzc3VtZSB0b2xlcmFudCByZWNlaXZlcnMpOg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtZmxh Z3MvDQoNCk1heWJlIEnigJltIGEgYml0IG1vcmUgcGVzc2ltaXN0aWMgdGhhbiBvcHRpbWlzdGlj LCBJIGZpbmQgaXQgaGFyZCB0byBwYXJzZSB0aGF0IGdlbmVyYXRpbmcgZmF0YWwgZXJyb3JzIHdp bGwgcHJvbW90ZSBpbnRlcm9wZXJhYmlsaXR5IChpZiB0aGlzIGlzIHdoYXQgaXMgbWVhbnQpLiBJ IHRoaW5rIG9uZSBuZWVkcyB0byBhbGxvdyBmb3IgdW5leHBlY3RlZCBiZWhhdmlvciBhbmQgYWxs b3cgZ3JhY2VmdWwgZmFpbHVyZS4gT25lIGNhbiBuZXZlciBiZSBzdXJlIGFsbCB0aGUgZXJyb3Ig Y2FzZXMvZGVsYXkgaW1wYWN0cyBoYXZlIGJlZW4gc29ydGVkIG91dCwgZXNwZWNpYWxseSBjb21p bmcgZnJvbSBvdXRzaWRlIG9mIG9uZeKAmXMgZG9tYWluL3N0YXRlIG1hY2hpbmVzL21pY3Jvc2Vy dmljZXMuIEUuZy4gZm9yIGEgcm91dGVyLCBvbmUgbmVlZHMgZmlyc3QgdG8gZW5zdXJlIHRoZSBp bnRlZ3JpdHkgb2YgdGhlIHN5c3RlbSBpcyBtYWludGFpbmVkIGFuZCB1c2VmdWwuIE9uZSBjYW4g aGF2ZSBhIGJlYXV0aWZ1bCBhcmNoaXRlY3R1cmUgdnMuIGRlcGxveW1lbnQgcmVhbGl0eS4NCg0K Q2Fyc3RlbiDigJMgYSByZS1waHJhc2luZyB0byBjbGFyaWZ5IHdvdWxkIGJlIHZlcnkgaGVscGZ1 bC4NCg0KQ2hlZXJzLA0KRGVib3JhaA0KDQoNCkZyb206IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdt YWlsLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDYsIDIwMTkgNToyNiBQTQ0KVG86 IEJSVU5HQVJELCBERUJPUkFIIEEgPGRiMzU0NkBhdHQuY29tPg0KQ2M6IEJyaWFuIEUgQ2FycGVu dGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+OyBpYWJAaWFiLm9yZzsgYXJjaGl0ZWN0 dXJlLWRpc2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSUFCXSBbYXJjaC1kXSBJLUQgQWN0 aW9uOiBkcmFmdC1pYWItcHJvdG9jb2wtbWFpbnRlbmFuY2UtMDQudHh0DQoNCkhpIERlYm9yYWgs DQoNCk9uIFdlZCwgTm92IDYsIDIwMTkgYXQgMToxNSBQTSBCUlVOR0FSRCwgREVCT1JBSCBBIDxk YjM1NDZAYXR0LmNvbTxtYWlsdG86ZGIzNTQ2QGF0dC5jb20+PiB3cm90ZToNCg0KDQpGb3IgbWUs IHRoZSByb2J1c3RuZXNzIHByaW5jaXBsZSBoYXMgbm90aGluZyB0byBkbyB3aXRoIHByZXZlbnRp bmcgbmV3IGV4dGVuc2lvbnMgb24gYSBwcm90b2NvbCwgaXQgaGFzIGV2ZXJ5dGhpbmcgdG8gZG8g d2l0aCBwcm90ZWN0aW5nIGV4aXN0aW5nIGRlcGxveW1lbnRzLiBUaGUgZG9jdW1lbnQncyBwcm9w b3NhbCAiQ2hvb3NpbmcgdG8gZ2VuZXJhdGUgZmF0YWwgZXJyb3JzIGZvciB1bnNwZWNpZmllZCBj b25kaXRpb25zIiBtYXkgYmUgYXBwcm9wcmlhdGUgZm9yIHNvbWUgcHJvdG9jb2xzLCBpdCB3b3Vs ZCBjYXVzZSBhIG1lbHQgZG93biBvZiB0aGUgbmV0d29yayBmb3Igb3RoZXIgcHJvdG9jb2xzLiBP bmUgb2YgbXkgd29ya2luZyBncm91cHMgY3VycmVudGx5IGlzIGRvaW5nIGEgImZpeCIgLSBhbmQg b25seSBiZWNhdXNlIG9mIHRoZSByb2J1c3RuZXNzIHByaW5jaXBsZSwgdGhlcmUgaGF2ZSBiZWVu IG5vIGlzc3VlcyB3aXRoIGN1cnJlbnQgZGVwbG95bWVudHMuDQpBcyBDYXJzdGVuIHNheXMgZG93 bnRocmVhZCwgc29tZSBvZiB0aGUgYXBwbGljYXRpb25zIG9mIHRoZSByb2J1c3RuZXNzIHByaW5j aXBsZSBhcmUgb2J2aW91c2x5IGdvb2QuICBTb21lLCBub3Qgc28gbXVjaC4gIEkgdGhpbmsgd2Ug YWxsIGFncmVlLCB0aG91Z2gsIHRoYXQgbWFpbnRhaW5pbmcgcG9pbnRzIG9mIGV4dGVuc2lvbiBp cyBib3RoIGdvb2QgYW5kLCB1bHRpbWF0ZWx5LCBuZWNlc3NhcnkgaWYgdGhlIEludGVybmV0IGlz IGdvaW5nIHRvIGNvbnRpbnVlIHRvIGNoYW5nZSBhbmQgZ3Jvdy4gIE9uZSBpc3N1ZSBpcyB0aGF0 IHNvbWUgb2YgdGhlIHBvaW50cyBvZiBleHRlbnNpb24gZ2V0IGVhdGVuIHVwIGJ5IHBvb3IgYXBw bGljYXRpb25zIG9mIHRoZSByb2J1c3RuZXNzIHByaW5jaXBsZS4gIElmIHlvdSByZXNlcnZlIGEg Y29kZSBwb2ludCBidXQgaWdub3JlIGl0cyB1c2UgaW4gZGVwbG95bWVudHMgYmVjYXVzZSBpdCBo YXMgbm8gbWVhbmluZywgaXQgY2FuIHJlYWxseSBuZXZlciBoYXZlIGEgbWVhbmluZyB1bnRpbCBh IGZvcmtsaWZ0IHVwZ3JhZGUgYXJyaXZlcywgYXMgeW91IGNhbid0IHRlbGwgd2hpY2ggYml0cyBp Z25vcmUgaXQgYW5kIHdoaWNoIHVzZSBpdC4gIEdpdmVuIG91ciBjdXJyZW50IHJhdGUgb2Ygb3Nz aWZpY2F0aW9uLCB0aGF0IGlzIGEgcHJvYmxlbS4NCg0KSSBkb24ndCBrbm93IHRoZSBzaXR1YXRp b24geW91IGFsbHVkZSB0byBhYm92ZSwgYW5kIGl0IG1heSBub3QgYXBwbHkgdGhlcmUuICBJZiB5 b3UgY2FuIHNlbmQgdGV4dCBvbiBob3cgdG8gZGlzdGluZ3Vpc2ggdGhlIHNpdHVhdGlvbiB5b3Ug c2VlIGFuZCB0aGUgZG9jIGRlc2NyaWJlcywgd2UnZCBiZSBncmF0ZWZ1bC4NCg0KcmVnYXJkcywN Cg0KVGVkDQo= --_000_F64C10EAA68C8044B33656FA214632C8A3AB1B94MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSBUZWQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggdGhlIHVwY29taW5nIG1lZXRpbmcs IEnigJl2ZSBiZWVuIHN3YW1wZWQgd2l0aCBwcmVwcywgaG9wZWZ1bGx5IGR1cmluZyB0aGUgbWVl dGluZyB3ZWVrLCBjYW4gZmluZCBzb21lIHRpbWUgdG8gdGFsayBhcyBtdWNoIGVhc2llciB0aGFu IGVtYWlsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggd2hhdCB5b3UgaGF2 ZSBiZWxvdyBhcyBsaWtlbHkgdG8gYmUgYXBwbGljYWJsZSBmb3Igc29tZSBwcm90b2NvbHMgYnV0 IEkgd291bGQgYmUgdmVyeSB1bmNvbWZvcnRhYmxlIHRvIHNheSBpdCBpcyB1bml2ZXJzYWxseSBh cHBsaWNhYmxlLiBJbiByb3V0aW5nLCB3ZSBkbyBtYW55IHRpbWVzIGdlbmVyYXRlIHJlc3BvbnNl cyBmb3Igbm9uLXJlY29nbml6ZWQgcmVxdWVzdHMgYnV0IHRoZSByZXNwb25zZQ0KIGRvZXMgbm90 IG5lY2Vzc2FyaWx5IHJlc3VsdCBpbiBhIGZhdGFsIGVycm9yLiBBbmQgZm9yIG1hbnkg4oCcYml0 c+KAnSBlLmcuIGZsYWdzLCBkZXBlbmRpbmcgb24gdGhlIGltcGFjdCwgcm91dGluZyBtYXkvbWF5 IG5vdCBoYXZlIGFuIGVycm9yIG1lc3NhZ2UsIDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbXBscy1sc3AtcGluZy1yZWdpc3RyaWVzLXVwZGF0ZS8iPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1yZWdpc3RyaWVzLXVwZGF0 ZS88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuIGV4YW1wbGUgb2Ygd2hlcmUgd2Ugd2Vy ZSBub3Qg4oCccGVyZmVjdOKAnSBvbiBmaXJzdCBzcGVjaWZ5aW5nIChhbmQgYXNzdW1lIHRvbGVy YW50IHJlY2VpdmVycyk6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXBjZS1zdGF0 ZWZ1bC1mbGFncy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt cGNlLXN0YXRlZnVsLWZsYWdzLzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF5YmUgSeKA mW0gYSBiaXQgbW9yZSBwZXNzaW1pc3RpYyB0aGFuIG9wdGltaXN0aWMsIEkgZmluZCBpdCBoYXJk IHRvIHBhcnNlIHRoYXQgZ2VuZXJhdGluZyBmYXRhbCBlcnJvcnMgd2lsbCBwcm9tb3RlIGludGVy b3BlcmFiaWxpdHkgKGlmIHRoaXMgaXMgd2hhdCBpcyBtZWFudCkuIEkgdGhpbmsgb25lIG5lZWRz IHRvIGFsbG93IGZvciB1bmV4cGVjdGVkIGJlaGF2aW9yIGFuZCBhbGxvdyBncmFjZWZ1bCBmYWls dXJlLg0KIE9uZSBjYW4gbmV2ZXIgYmUgc3VyZSBhbGwgdGhlIGVycm9yIGNhc2VzL2RlbGF5IGlt cGFjdHMgaGF2ZSBiZWVuIHNvcnRlZCBvdXQsIGVzcGVjaWFsbHkgY29taW5nIGZyb20gb3V0c2lk ZSBvZiBvbmXigJlzIGRvbWFpbi9zdGF0ZSBtYWNoaW5lcy9taWNyb3NlcnZpY2VzLiBFLmcuIGZv ciBhIHJvdXRlciwgb25lIG5lZWRzIGZpcnN0IHRvIGVuc3VyZSB0aGUgaW50ZWdyaXR5IG9mIHRo ZSBzeXN0ZW0gaXMgbWFpbnRhaW5lZCBhbmQgdXNlZnVsLiBPbmUNCiBjYW4gaGF2ZSBhIGJlYXV0 aWZ1bCBhcmNoaXRlY3R1cmUgdnMuIGRlcGxveW1lbnQgcmVhbGl0eS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Q2Fyc3RlbiDigJMgYSByZS1waHJhc2luZyB0byBjbGFyaWZ5IHdvdWxkIGJlIHZl cnkgaGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVib3JhaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBU ZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFpbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIE5vdmVtYmVyIDA2LCAyMDE5IDU6MjYgUE08YnI+DQo8Yj5Ubzo8L2I+IEJSVU5H QVJELCBERUJPUkFIIEEgJmx0O2RiMzU0NkBhdHQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQnJp YW4gRSBDYXJwZW50ZXIgJmx0O2JyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSZndDs7IGlhYkBp YWIub3JnOyBhcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0lBQl0gW2FyY2gtZF0gSS1EIEFjdGlvbjogZHJhZnQtaWFiLXByb3RvY29sLW1haW50 ZW5hbmNlLTA0LnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIERl Ym9yYWgsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBX ZWQsIE5vdiA2LCAyMDE5IGF0IDE6MTUgUE0gQlJVTkdBUkQsIERFQk9SQUggQSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRiMzU0NkBhdHQuY29tIj5kYjM1NDZAYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQpGb3IgbWUsIHRoZSByb2J1 c3RuZXNzIHByaW5jaXBsZSBoYXMgbm90aGluZyB0byBkbyB3aXRoIHByZXZlbnRpbmcgbmV3IGV4 dGVuc2lvbnMgb24gYSBwcm90b2NvbCwgaXQgaGFzIGV2ZXJ5dGhpbmcgdG8gZG8gd2l0aCBwcm90 ZWN0aW5nIGV4aXN0aW5nIGRlcGxveW1lbnRzLiBUaGUgZG9jdW1lbnQncyBwcm9wb3NhbCAmcXVv dDtDaG9vc2luZyB0byBnZW5lcmF0ZSBmYXRhbCBlcnJvcnMgZm9yIHVuc3BlY2lmaWVkIGNvbmRp dGlvbnMmcXVvdDsgbWF5IGJlIGFwcHJvcHJpYXRlDQogZm9yIHNvbWUgcHJvdG9jb2xzLCBpdCB3 b3VsZCBjYXVzZSBhIG1lbHQgZG93biBvZiB0aGUgbmV0d29yayBmb3Igb3RoZXIgcHJvdG9jb2xz LiBPbmUgb2YgbXkgd29ya2luZyBncm91cHMgY3VycmVudGx5IGlzIGRvaW5nIGEgJnF1b3Q7Zml4 JnF1b3Q7IC0gYW5kIG9ubHkgYmVjYXVzZSBvZiB0aGUgcm9idXN0bmVzcyBwcmluY2lwbGUsIHRo ZXJlIGhhdmUgYmVlbiBubyBpc3N1ZXMgd2l0aCBjdXJyZW50IGRlcGxveW1lbnRzLg0KPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMg Q2Fyc3RlbiBzYXlzIGRvd250aHJlYWQsIHNvbWUgb2YgdGhlIGFwcGxpY2F0aW9ucyBvZiB0aGUg cm9idXN0bmVzcyBwcmluY2lwbGUgYXJlIG9idmlvdXNseSBnb29kLiZuYnNwOyBTb21lLCBub3Qg c28gbXVjaC4mbmJzcDsgSSB0aGluayB3ZSBhbGwgYWdyZWUsIHRob3VnaCwgdGhhdCBtYWludGFp bmluZyBwb2ludHMgb2YgZXh0ZW5zaW9uIGlzIGJvdGggZ29vZCBhbmQsIHVsdGltYXRlbHksIG5l Y2Vzc2FyeSBpZiB0aGUNCiBJbnRlcm5ldCBpcyBnb2luZyB0byBjb250aW51ZSB0byBjaGFuZ2Ug YW5kIGdyb3cuJm5ic3A7IE9uZSBpc3N1ZSBpcyB0aGF0IHNvbWUgb2YgdGhlIHBvaW50cyBvZiBl eHRlbnNpb24gZ2V0IGVhdGVuIHVwIGJ5IHBvb3IgYXBwbGljYXRpb25zIG9mIHRoZSByb2J1c3Ru ZXNzIHByaW5jaXBsZS4mbmJzcDsgSWYgeW91IHJlc2VydmUgYSBjb2RlIHBvaW50IGJ1dCBpZ25v cmUgaXRzIHVzZSBpbiBkZXBsb3ltZW50cyBiZWNhdXNlIGl0IGhhcyBubyBtZWFuaW5nLCBpdA0K IGNhbiByZWFsbHkgbmV2ZXIgaGF2ZSBhIG1lYW5pbmcgdW50aWwgYSBmb3JrbGlmdCB1cGdyYWRl IGFycml2ZXMsIGFzIHlvdSBjYW4ndCB0ZWxsIHdoaWNoIGJpdHMgaWdub3JlIGl0IGFuZCB3aGlj aCB1c2UgaXQuJm5ic3A7IEdpdmVuIG91ciBjdXJyZW50IHJhdGUgb2Ygb3NzaWZpY2F0aW9uLCB0 aGF0IGlzIGEgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBkb24ndCBrbm93IHRoZSBzaXR1YXRpb24geW91IGFsbHVkZSB0byBh Ym92ZSwgYW5kIGl0IG1heSBub3QgYXBwbHkgdGhlcmUuJm5ic3A7IElmIHlvdSBjYW4gc2VuZCB0 ZXh0IG9uIGhvdyB0byBkaXN0aW5ndWlzaCB0aGUgc2l0dWF0aW9uIHlvdSBzZWUgYW5kIHRoZSBk b2MgZGVzY3JpYmVzLCB3ZSdkIGJlIGdyYXRlZnVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UZWQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F64C10EAA68C8044B33656FA214632C8A3AB1B94MISOUT7MSGUSRDE_-- From nobody Tue Nov 12 16:33:42 2019 Return-Path: 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 00004120130 for ; Tue, 12 Nov 2019 16:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XxOwUC_DKsAH for ; Tue, 12 Nov 2019 16:33:36 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 731A51200B5 for ; Tue, 12 Nov 2019 16:33:35 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id z188so369093lfa.11 for ; Tue, 12 Nov 2019 16:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7I943FELD27quGbwgyj8EEJuC/gJQqzyV2CZ0kWadrE=; b=A70SfUylk16KXhsX8MTxo/HmFbYkGQSZEJYJ9n9qN4Kle+OZ1glmy2ozx3Xcd+2fA6 yPR/EaBvmB1j1ASkFGx2kz75097wTRL1K9xkatGGXhdRSLiVOh3f3IJ15GMSZe5n4heg /V3uKEWB0R02X5GTT3kO4XfC013Ssd5SySWSYLTZ5HU9h/qh3uITkdwJdk+OhGdAFg41 hZXrwTIy1dw3Mhak02q6bKgSHWNfzL1ftMqlHClprz0M7JWO6dzFZRQep1JOFaksHjkb VmcvNHZpUTJajDg9hUVTT1W3+5onubXDW75CG9o4BO0/p3VE/vvQCmYFWs/tlZ3cajdp luDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7I943FELD27quGbwgyj8EEJuC/gJQqzyV2CZ0kWadrE=; b=L0KhmT0c+h0qniTh3uFRRk+cU7eviSq5BloPr00WYJsc3CslNfvFbN7kTcfMuRchX7 A9XVnrEePgxunv0RqI6I/qPchJ4wuESZIkR50jR8irIZDYie054UfqAGsh6sA37MDaT5 VJZsuMgnMNsHZuCA7/oYMnn7rpLHcBhHUaLJZBRy45XEb/6H10r1FJau3Dc+lp9ilRyb uZbZH8osMZcNQC684Hf055+avl4Ris7OvKzhBfXsz9tScLBjsfWgq0jzezRtd+3PlnyX C0z+U67caOKNawIWHSsLKPGKzNS5FKsGD555BHJ7RdM0bDz9J8diDiqgYUvvodwh5MrG IRdA== X-Gm-Message-State: APjAAAU2Llyyg4X9uk7omhpyMzbdKjiiZ3r+l7M60EnB3Sl5iPvhtmVV YneZH0azQ1/ood5AshZh4zokotKlPgd+whFNoaI= X-Google-Smtp-Source: APXvYqwg2qkpA4f6Yvu0dKCvu3B0rNjbbFjBCV6yDTQfFVTcORuSM4oi4GxvMBQ9KSEI4X1PZCg4JbykryPDyMGThig= X-Received: by 2002:a19:48cf:: with SMTP id v198mr380380lfa.59.1573605213195; Tue, 12 Nov 2019 16:33:33 -0800 (PST) MIME-Version: 1.0 References: <157284936054.13440.20144182660413459@ietfa.amsl.com> In-Reply-To: From: Bernard Aboba Date: Tue, 12 Nov 2019 16:33:22 -0800 Message-ID: To: Brian E Carpenter Cc: IAB IAB , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000bfcfff05972f83a5" Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 00:33:41 -0000 --000000000000bfcfff05972f83a5 Content-Type: text/plain; charset="UTF-8" Brian said: "> For a protocol > that is actively maintained, the robustness principle can, and > should, be avoided. To be blunt, I don't think there is community consensus for this statement. " [BA] Actually, I don't think you are being blunt enough. The robustness principle is *fundamental* to the operation of the Internet, which is about the interconnection of vast numbers of disparate implementations. With such diversity (and with the increasing complexity of protocol specifications) it is inevitable that interoperability problems will arise frequently. The robustness principle says "regardless of whether your interpretation of the specifications is the "right" one" - get over yourself and make it work. The idea that "the robustness principle should be avoided" sounds like something that would belong in a modern remake of a 1960s movie by Stanley Kubrick: "Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb" We could rename it "Dr. NoPackets or: How I Learned to Stop Worrying and Love Loss of Connectivity" Brian also said: "Now the IAB can of course express an opinion, but for something as contentious as this, I think it needs to be labelled as an opinion statement" [BA] You are being far too kind here. This is an opinion that just can't be taken seriously. Are we sure that it wasn't intended for publication on April 1? On Mon, Nov 4, 2019 at 5:13 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > Thanks for the updates, but I still have concerns about this draft. > > > Abstract > .... > > For a protocol > > that is actively maintained, the robustness principle can, and > > should, be avoided. > > To be blunt, I don't think there is community consensus for this > statement. Now the IAB can of course express an opinion, but for > something as contentious as this, I think it needs to be labelled > as an opinion statement, especially in the Abstract which tends > to bias the reader's mindset. Or a more neutral phrasing could > be used; for example: > > For a protocol that is actively maintained, the impact of > applying the robustness principle should be carefully considered. > > > 1. Introduction > .... > > Ideally, protocol implementations never have to apply the robustness > > principle. Or, where it is unavoidable, use of the robustness > > principle is viewed as a short term workaround that needs to be > > quickly reverted. > > In an ideal world, all implementations would be perfect, so the > robustness principle would be unnecessary. But the very basis for > it is that the world *is not* ideal and many implementations *are > not* perfect. So, really, what is the point of the first sentence? > > And no, I don't believe it's a short term workaround. That's like > saying: when I've finished testing my Python program, I can take > out all the try:... except:... statements because I've fixed > all the errors, so I don't need the except: cases any more. > > On the contrary - good engineers leave the exception handling > in for ever. When they don't, planes crash. > > Is there really a consensus view in the community that > "the robustness principle is viewed as a short term workaround"? > I don't believe it. > > > 4. Ecosystem Effects > > > > Once deviations become entrenched, it can be extremely difficult - if > > not impossible - to rectify the situation. > > I take the point. Sloppy usage of the robustness principle can indeed > allow sloppy errors in the spec or in an implmentation to survive. But > there's a trade-off that, IMHO, the draft does not recognize: non-robust > implementations that do not tolerate sloppy inputs are bad for users > trying to accomplish something. > > It's perfectly reasonable to argue that an implementation should have > a strict mode, in which it logs errors etc., in a way that allows the > detection of sloppiness at the other end. And I agree that this is of > particular value during active development of the protocol and its > ecosystem**. But I don't see any developer shipping code to the mass > market that has strict mode on by default. I don't see any recognition > of this reality in the draft. > > It's also correct to argue that sloppiness in certain security > functions such as algorithm negotiation is never OK. > > ** If anyone here is masochistic enough to try my prototype > of GRASP, they'll discover that its first two questions to > the user are: > > Test mode (many extra diagnostics)? Y/N: > Diagnostics for inbound message parse errors? Y/N: > > So yes, I agree with a lot of the points this draft makes. > > Regards > Brian Carpenter > > On 04-Nov-19 19:36, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Internet Architecture Board IETF of the > IETF. > > > > Title : The Harmful Consequences of the Robustness > Principle > > Author : Martin Thomson > > Filename : draft-iab-protocol-maintenance-04.txt > > Pages : 12 > > Date : 2019-11-03 > > > > Abstract: > > The robustness principle, often phrased as "be conservative in what > > you send, and liberal in what you accept", has long guided the design > > and implementation of Internet protocols. The posture this statement > > advocates promotes interoperability in the short term, but can > > negatively affect the protocol ecosystem over time. For a protocol > > that is actively maintained, the robustness principle can, and > > should, be avoided. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 > > https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-iab-protocol-maintenance-04 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000bfcfff05972f83a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian said:=C2=A0
">=C2=A0 =C2=A0 For a protocol
>=C2=A0 =C2=A0 = that is actively maintained, the robustness principle can, and
>=C2= =A0 =C2=A0 should, be avoided.

To be blunt, I don't think there = is community consensus for this
statement. "
=
[BA] Actually, I don't think you are being blunt enough.=

The robustness principle is *fundamental* to the = operation of the Internet, which is about the interconnection of vast numbe= rs of disparate implementations.=C2=A0 With such diversity (and with the in= creasing complexity of protocol specifications) it is inevitable that inter= operability problems will arise frequently.=C2=A0 The robustness principle = says "regardless of whether your interpretation of the specifications = is the "right" one" - get over yourself and make it work.=C2= =A0

The idea that "the robustness=C2=A0princi= ple should be avoided" sounds like something that would belong in a mo= dern remake of a 1960s movie by Stanley Kubrick:=C2=A0

=

"Dr. Strangelove or: How I = Learned to Stop Worrying and Love the Bomb"

We could re= name it "Dr. NoPackets or: How I Learned to Stop Worrying and Love Los= s of Connectivity"=C2=A0

Bria= n also said:=C2=A0

&qu= ot;Now the=C2=A0IAB=C2=A0can of course express an opinion, but for somethi= ng as contentious as this, I think it needs to be labelled
as an opinion= statement"

[BA]=C2=A0=C2=A0You are being far = too kind here.=C2=A0 This is an opinion that just can't be taken seriou= sly.=C2=A0 Are we sure that it wasn't intended for publication on April= 1?=C2=A0=C2=A0

On Mon, Nov 4, 2019 at 5:13 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
Hi,

Thanks for the updates, but I still have concerns about this draft.

> Abstract
....
>=C2=A0 =C2=A0 For a protocol
>=C2=A0 =C2=A0 that is actively maintained, the robustness principle can= , and
>=C2=A0 =C2=A0 should, be avoided.

To be blunt, I don't think there is community consensus for this
statement. Now the IAB can of course express an opinion, but for
something as contentious as this, I think it needs to be labelled
as an opinion statement, especially in the Abstract which tends
to bias the reader's mindset. Or a more neutral phrasing could
be used; for example:

For a protocol that is actively maintained, the impact of
applying the robustness principle should be carefully considered.

> 1.=C2=A0 Introduction
....
>=C2=A0 =C2=A0 Ideally, protocol implementations never have to apply the= robustness
>=C2=A0 =C2=A0 principle.=C2=A0 Or, where it is unavoidable, use of the = robustness
>=C2=A0 =C2=A0 principle is viewed as a short term workaround that needs= to be
>=C2=A0 =C2=A0 quickly reverted.

In an ideal world, all implementations would be perfect, so the
robustness principle would be unnecessary. But the very basis for
it is that the world *is not* ideal and many implementations *are
not* perfect. So, really, what is the point of the first sentence?

And no, I don't believe it's a short term workaround. That's li= ke
saying: when I've finished testing my Python program, I can take
out all the try:... except:... statements because I've fixed
all the errors, so I don't need the except: cases any more.

On the contrary - good engineers leave the exception handling
in for ever. When they don't, planes crash.

Is there really a consensus view in the community that
"the robustness principle is viewed as a short term workaround"?<= br> I don't believe it.

> 4.=C2=A0 Ecosystem Effects
>
>=C2=A0 =C2=A0 Once deviations become entrenched, it can be extremely di= fficult - if
>=C2=A0 =C2=A0 not impossible - to rectify the situation.

I take the point. Sloppy usage of the robustness principle can indeed
allow sloppy errors in the spec or in an implmentation to survive. But
there's a trade-off that, IMHO, the draft does not recognize: non-robus= t
implementations that do not tolerate sloppy inputs are bad for users
trying to accomplish something.

It's perfectly reasonable to argue that an implementation should have a strict mode, in which it logs errors etc., in a way that allows the
detection of sloppiness at the other end. And I agree that this is of
particular value during active development of the protocol and its
ecosystem**. But I don't see any developer shipping code to the mass market that has strict mode on by default. I don't see any recognition<= br> of this reality in the draft.

It's also correct to argue that sloppiness in certain security
functions such as algorithm negotiation is never OK.

** If anyone here is masochistic enough to try my prototype
of GRASP, they'll discover that its first two questions to
the user are:

Test mode (many extra diagnostics)? Y/N:
Diagnostics for inbound message parse errors? Y/N:

So yes, I agree with a lot of the points this draft makes.

Regards
=C2=A0 =C2=A0Brian Carpenter

On 04-Nov-19 19:36, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Internet Architecture Board IETF of t= he IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: The Harmful Consequences of the Robustness Principle
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Martin Thomson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= iab-protocol-maintenance-04.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 12
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2019-11-03
>
> Abstract:
>=C2=A0 =C2=A0 The robustness principle, often phrased as "be conse= rvative in what
>=C2=A0 =C2=A0 you send, and liberal in what you accept", has long = guided the design
>=C2=A0 =C2=A0 and implementation of Internet protocols.=C2=A0 The postu= re this statement
>=C2=A0 =C2=A0 advocates promotes interoperability in the short term, bu= t can
>=C2=A0 =C2=A0 negatively affect the protocol ecosystem over time.=C2=A0= For a protocol
>=C2=A0 =C2=A0 that is actively maintained, the robustness principle can= , and
>=C2=A0 =C2=A0 should, be avoided.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/do= c/draft-iab-protocol-maintenance/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-= iab-protocol-maintenance-04
> https://datatracker.ietf= .org/doc/html/draft-iab-protocol-maintenance-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdi= ff?url2=3Ddraft-iab-protocol-maintenance-04
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000bfcfff05972f83a5-- From nobody Tue Nov 12 16:41:57 2019 Return-Path: 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 9886A1200C1 for ; Tue, 12 Nov 2019 16:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NqZskzBAn9e3 for ; Tue, 12 Nov 2019 16:41:53 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52DC3120091 for ; Tue, 12 Nov 2019 16:41:53 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 1153D37401A2; Tue, 12 Nov 2019 16:41:49 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id D153A1945738; Tue, 12 Nov 2019 17:41:48 -0700 (MST) Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id C9B0E1945737; Tue, 12 Nov 2019 17:41:48 -0700 (MST) From: Paul Ebersman To: Bernard Aboba cc: Brian E Carpenter , IAB IAB , architecture-discuss@ietf.org In-reply-to: References: <157284936054.13440.20144182660413459@ietfa.amsl.com> Comments: In-reply-to Bernard Aboba message dated "Tue, 12 Nov 2019 16:33:22 -0800." X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <54067.1573605708.1@fafnir.local> Date: Tue, 12 Nov 2019 17:41:48 -0700 Message-Id: <20191113004148.D153A1945738@fafnir.remote.dragon.net> Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 00:41:55 -0000 b.aboba> The robustness principle is *fundamental* to the operation of b.aboba> the Internet, which is about the interconnection of vast b.aboba> numbers of disparate implementations. +1 Anyone who thought they were getting interoperability but were sold protocol conformance can tell you why the robustness principle is vital. While it may sometimes more resemble bondo or duct tape than we'd like, interoperability is what the internet runs on. From nobody Tue Nov 12 16:58:54 2019 Return-Path: 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 8C3E91200C1; Tue, 12 Nov 2019 16:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 2nS4NN9rouNj; Tue, 12 Nov 2019 16:58:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE10120091; Tue, 12 Nov 2019 16:58:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1iUgzg-0000OT-JN; Wed, 13 Nov 2019 00:58:48 +0000 Date: Tue, 12 Nov 2019 16:58:47 -0800 Message-ID: From: Randy Bush To: Bernard Aboba Cc: Brian E Carpenter , IAB , architecture-discuss@ietf.org In-Reply-To: References: <157284936054.13440.20144182660413459@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 00:58:53 -0000 while i do not think the robustness principle should be avoided per se, i am not comfortable with enshrining it in concrete. > The robustness principle is *fundamental* to the operation of the > Internet being a naggumite, imiho being liberal in what you accept can be entropic to the point of breakage. i would take the principle as guidance, not law. and i will pretend not to have read your hyperbole randy From nobody Tue Nov 12 17:18:30 2019 Return-Path: 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 4436A1200F7 for ; Tue, 12 Nov 2019 17:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=zQP8g8vX; dkim=pass (1536-bit key) header.d=taugh.com header.b=qdX6Z4EV 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 2BSaOd3-kvVW for ; Tue, 12 Nov 2019 17:18:27 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB38120091 for ; Tue, 12 Nov 2019 17:18:26 -0800 (PST) Received: (qmail 9019 invoked from network); 13 Nov 2019 01:18:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2339.5dcb59e0.k1911; i=printer-iecc.com@submit.iecc.com; bh=S1aCtspqQJ5wHGh8/z3jYo0ZyUElOVo2uqJoDih9WXg=; b=zQP8g8vXcFin/Yku1GMxYYvL0RNXJLRy4FEAEH7Uzq20DyxwEU5QRzqTHmScmO5BSGTsDkZyBPWsUzm1rw9mAxOIRxLfncjc1FhV/wx2O+vusXhH/XnbHAxpCd8NW81YuX2vhKaQiptOSJzA+N3ABGfDf61jz4rrNKlwAzgO1qMVcNjTYEYq+Lbnt85yymxFLnQZssZUpp+RH3hzqiDWv8oVO2OFRn8zo8+CxYmSwyWe92OK2Lzs1IlZaRiwlU7r DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2339.5dcb59e0.k1911; olt=printer-iecc.com@submit.iecc.com; bh=S1aCtspqQJ5wHGh8/z3jYo0ZyUElOVo2uqJoDih9WXg=; b=qdX6Z4EVP8gZJQShY17Vu6cIu5DFu0wmI1eEntltJzC5/9GuU9/1HLFUOBGZrhl3p6yxeRxN4wOEViCDcEoZkx3vN+uSjkaKYEbmyONY+01n/CssFscYSgIOwRlGxJeodiDttu+nv7uUMdla/KLGRLlWfetQ4llbHQa3IUMI94Uzf0RYJcewPtXZpbE0urs820JcJzbC+KX7VNPJEXptz3P7hLb7JJUQAORgFPLvpbhp8XZRldJ4FK8lClunX3FW Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP6; 13 Nov 2019 01:18:24 -0000 Received: by ary.qy (Postfix, from userid 501) id 0F362EB2192; Tue, 12 Nov 2019 20:18:23 -0500 (EST) Date: 12 Nov 2019 20:18:23 -0500 Message-Id: <20191113011824.0F362EB2192@ary.qy> From: "John Levine" To: architecture-discuss@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 01:18:29 -0000 In article you write: >The robustness principle is *fundamental* to the operation of the Internet, >which is about the interconnection of vast numbers of disparate >implementations. ... Yes, different implementations need to interoperate, but the best way to make that happen isn't necessarily to program around other people's mistakes. In the e-mail world, I can assure you that SMTP implementations are ever more strict about what they accept, since we've all observed that real mail software implements SMTP correctly, and the stuff that makes mistakes is spamware. By being stricter about what we accept, we more reliably deliver the mail our users want. I think you can also distinguish between being liberal about things that are ambiguous and things that are wrong. For example, there's no guidance about whether to send mail addresses in upper or lower case, so in practice everyone accepts them interchangably. (Even this turns out to have less than ideal consequences since in mail with UTF-8 addresses, you can't reliably do case folding until you know what language the address is supposed to be in, which you usually don't.) On the other hand, if a mail client sends something that is just wrong, leaving out required punctuation, or sending out of sequence, that's just wrong, and generally is fatal for mail senders. I think there is a lot to be said for Virtuous Intolerance, in at least some contexts. Figuring out which contexts the are will be an interesting challenge. R's, John From nobody Tue Nov 12 18:33:53 2019 Return-Path: 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 4D80D120105 for ; Tue, 12 Nov 2019 18:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 WB5M5zaxNznI for ; Tue, 12 Nov 2019 18:33:49 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 B27F3120072 for ; Tue, 12 Nov 2019 18:33:49 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id c184so556050pfb.0 for ; Tue, 12 Nov 2019 18:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=fUbcRCN0nqmLGuA1C277a/yt4pccfrgcvyB8rrV0qXQ=; b=XutsTfpChKA4UCAFKjxUX17ok5mFHUeDKDQbGqR6R085JquN8BnCBEZlHeqra1K5V9 IDARTHFt5VtGPfY5rsyiM6mBr0JPImLIRXtnSZBTVW9MVkiBGBkCtRzB+zutdugOrZup Zitf0ChpnYIEY88J5iJKbCgz5LJaz3A+GGaHjiL9dg0deQMLUDDpEZb4S3orAuq7ovKJ gGlAn6OEZMZIIhDoOr/3/tLjOfOK9LDD111v9n34XOyk43YawHXqg0ajk5t7wSp0T47j Z5lBPFMifQwrxOjMfK8+R3b4B+BKCjm5c/V2E/27bmIpsgdSE18u350UiglT5Oy6ahMj 9ySw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=fUbcRCN0nqmLGuA1C277a/yt4pccfrgcvyB8rrV0qXQ=; b=aHC/UYYB2VpM9cJUo6N+w7bMr2YJcEO4noBSHl7zyTaHN3oFx2yC5ySqICHEIih1Wy 3kThBV5nKus60ES+N2JCwZQNXpfBlzo6tsbwdLJ9x8UpJieg7Bn5fzHtO4WjJbPlvLmE 4dW/+Kp+dB+lGnqJ87FC4x7G1+fHCHvSua+yNZ9hXoO8bd53tGkDJeqSKsxUBr2hEiWZ chvYyyAT9j45dbzVzcnykpO6FV1WmrCu34kO9+THkaO+sQ1zPm4bpD1DPqLIME79nlqR UD9LlQkU1is4fWyWG/Nh9bBWwf+2a71pghS7BylFA0N8/DVACFU2VCrNxWn8JxA8KxIK j2ow== X-Gm-Message-State: APjAAAVV09MN05aaeV9pHoK6MIbJ/+IMaxQQ9Xx6kOuhYAz5p0qemsmz Je0VEt13blvHCviZ4E4y/VZFXCrF X-Google-Smtp-Source: APXvYqxsANHnZyeX53xexS4GOPEkOUuZ/HfnGrkeNwKvfSTQcswPAUNSUBa1lM3z7QGrU4GDlw18Dg== X-Received: by 2002:a17:90a:9a81:: with SMTP id e1mr1457025pjp.59.1573612428240; Tue, 12 Nov 2019 18:33:48 -0800 (PST) Received: from [192.168.1.157] (c-71-227-236-207.hsd1.wa.comcast.net. [71.227.236.207]) by smtp.gmail.com with ESMTPSA id m34sm365693pgb.26.2019.11.12.18.33.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Nov 2019 18:33:47 -0800 (PST) From: Bernard Aboba X-Google-Original-From: Bernard Aboba Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Tue, 12 Nov 2019 18:33:45 -0800 Message-Id: <3D988D7D-5216-4C23-9A66-48E40FDC5D40@gmail.com> References: <20191113011824.0F362EB2192@ary.qy> Cc: architecture-discuss@ietf.org In-Reply-To: <20191113011824.0F362EB2192@ary.qy> To: John Levine X-Mailer: iPad Mail (17B102) Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 02:33:51 -0000 John said: =E2=80=9C I think you can also distinguish between being liberal about thing= s that are ambiguous and things that are wrong.=E2=80=9D [BA] Good point. One might not be liberal about potentially malicious activi= ty (your spam example). Ambiguities tend to be resolved over time as standar= ds advance.=20 In terms of code complexity, =E2=80=9Caccept=E2=80=9D may just mean =E2=80=9C= ignoring=E2=80=9D and continuing on instead of failing. Sometimes that=E2=80= =99s a perfectly fine approach, and one that can result in less maintenance o= ver time. So the robustness principle doesn=E2=80=99t always imply a growing= maintenance problem. > On Nov 12, 2019, at 17:18, John Levine wrote: >=20 > I think you can also distinguish between being liberal about things > that are ambiguous and things that are wrong. From nobody Tue Nov 12 22:54:09 2019 Return-Path: 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 56EF012085B for ; Tue, 12 Nov 2019 22:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 NImy1nWY4F8M for ; Tue, 12 Nov 2019 22:53:59 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110084.outbound.protection.outlook.com [40.107.11.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DF01200CD for ; Tue, 12 Nov 2019 22:53:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ElZUyZbruxosXRdcPGeDzyAcA9nZFNxpr9mCYhgni4zvbMmTvY+hFgdBT3IstcDVrDt8oMo2JMFYbZWGd1dPrtSSCf4B6ty5mGhVKT5hY9zpF51fSTjR0P7SCIRikxVPtkmn6+WILs59pov2xwevdp87P3/0eMYlet2MvlLFzn88opDswl+/uVM9nUgYr0JpJyS9Eh3vLqew1fRxQlX9cEcsM/OeUnhEjl9JgILwLOapMD63NorwHJIwAmjNIu2yo5Wc/JiTfZphfTPgm1Tl75i/qp0P9uzHt1Fqe/8qNKWmF45oxg2qtOSrA8OmR969SqA+TAiYqWuFa1i7Mcg3TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=igSCvG5IVuePi3oBdgnnxclfcK9iaOt8acwDPHSbrQE=; b=k1EupRGnzSoqeoACVBTxPY8ga1eD+KJI+L+31YMJPPIS0SgIqCFFcogsDj9f2OTk/zAhkozAcGpCTVKTS7NHIwB8brnlR9kQGfpTxQ/L/llk4Gxv0Q9hmdZ1LzKZ9KON+mJX6glu7n/YSHZTEXb0vWv9sj8EtGZ//cA/ip9zPTvHoBOKdpmW4wM0oHwAY8DFpROe2lyxJOvLItqB9K5M0M2aqoO1nfvAXDhI2klPSc4T3TNNK2m80xMEGhvLMKLGTGCWkDaQoZ2bbzYEQS04M215gmt/wrk/nP33EToS+09KZFcvgFg1PvvK8n1u0YfHAwr/sbOe8b4YRbXTvO983w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=igSCvG5IVuePi3oBdgnnxclfcK9iaOt8acwDPHSbrQE=; b=CpzlxjQrWSvtzMhoUMekZlIHSl1y2Nve2AwncSG6ZaXqHgEV3Yde7P5Zx5AUD/6SKfLa51NOjqlHfDM3JVDrJiuSpGatg/i1e6OIJC/Df14JsDKbOmqD1HW3AteefHAT07SjLIP86CjYppJXJVyJH+/X6NGAI+B+qJrKA+QqgLo= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0542.GBRP265.PROD.OUTLOOK.COM (10.166.99.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.23; Wed, 13 Nov 2019 06:53:56 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2430.028; Wed, 13 Nov 2019 06:53:56 +0000 From: Andrew Campling To: "architecture-discuss@ietf.org" Thread-Topic: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure" Thread-Index: AdWZ7xzz/1YK89C5RdqDpoO8+b/71w== Date: Wed, 13 Nov 2019 06:53:55 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [109.151.10.212] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f8206e6-6776-46d0-2588-08d7680640b6 x-ms-traffictypediagnostic: LO2P265MB0542: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(39830400003)(136003)(396003)(189003)(199004)(71200400001)(508600001)(6916009)(256004)(86362001)(316002)(966005)(6436002)(6116002)(102836004)(3846002)(14444005)(99286004)(25786009)(74316002)(305945005)(486006)(26005)(71190400001)(81166006)(81156014)(6246003)(8936002)(14454004)(7736002)(8676002)(44832011)(2906002)(30864003)(66574012)(33656002)(52536014)(2501003)(6306002)(5640700003)(66946007)(7696005)(5660300002)(229853002)(476003)(66066001)(6506007)(186003)(66556008)(66476007)(2351001)(76116006)(66446008)(9686003)(64756008)(55016002)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB0542; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0MqmN0ydOqz3SlTm3sCiZ2p8AogGVxtpZ+kiz8eAzw2omnOChpCXqJwmHZvyHGvXk3c1bJEWRSPiveMlcE35muZQFqZW3Zzkxl2DU0RQaRZVquBvRmsCiwqL+QOPpHljLsyxqWN5XiGJRhcFm4gVqNbsW0MvP0D9BzLs3QrfwZpOTaLdaGjwhO5+6NBUNhWo9V+1gBcmi415o1KuEotHEfXZoe4EfFU9cWiW0Z7awuTh1/iUB0VJBSgTpbA7HrLQXnEQ2Suon32om2egppbtuybkkzD8uaZ5DDAwipyvAcdz/nWmqGqiCyyTmYlkDM0avL66V2RxRSbq6e2vN2TpBmxSSlNs/4/ih+TBoGlyJlYeIjqO8JytDXuNdsfhkNjm+QPq91QikBYJANqFW2QGpDls2g9/3+mXScu4vpZwqHGORlvjV33ZFwc7gVdsspGh x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573C0D8F8D9D7ECF4E472AFC2760LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 6f8206e6-6776-46d0-2588-08d7680640b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 06:53:55.8857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: O78o89wg61jcBWP2Jmw9Mx2bf6xlEwvBR2bke06bVC6FGcXsUBI9rNneWpiEN/6KpIHgr2DI2NXBar15Uujh29XLwm/Zpfsu1fl9OTXuVDk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0542 Archived-At: Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 06:54:04 -0000 --_000_LO2P265MB0573C0D8F8D9D7ECF4E472AFC2760LO2P265MB0573GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vittorio Bertola > wrote on Mon, 09 September 2019 15:26 In the DNS section, it is disheartening to read the IAB stating that = "[a DNS resolver] returning the wrong (or no) address breaks the trust that= users have in this infrastructure", after having spent months on the ADD l= ist and elsewhere to explain that there are indeed lots of use cases in whi= ch users expect, or even actively request, that their resolver applies filt= ers to the responses. In some cases it is actually the opposite - if I acqu= ire a DNS-based service to prevent any accidental connection to malware-inf= ected websites and then I get malware, that's when I lose trust in my DNS r= esolver; same for parental controls. I believe that the broad assertion that "all DNS filtering is wrong" sugges= ts a lack of understanding in the way that many users and entities use DNS = as a control surface in a variety of contexts. There are large classes of = users that would disagree with the insistence that a DNS resolver must retu= rn the correct address in every case. More generally, the entire document sounds like a claim that the Inte= rnet's infrastructure and those who run it need to be exempt from cooperati= on with law enforcement activities, and totally unregulated. In my view it is unrealistic to expect that governments and regulators will= be content to allow the Internet's infrastructure and those who run to be = exempt from cooperation with law enforcement activities, and totally unregu= lated. Indeed the many privacy, antitrust and other issues that have surfa= ced relating to the tech sector over the last several years have led to an = environment where an increase in oversight is both pretty much guaranteed a= nd necessary. in the recommendations, it then mentions "endpoint-focused interventi= ons" only to suggest that those who are subject to them should be listed ex= plicitly in the regulation (which, by the way, is not how a law can work). I agree that, in most if not all cases, it would neither be practical nor d= esirable to explicitly list all of the organisations that are subject to a = specific intervention. At best it might be possible to list categories of = organisations in some cases, however even then the evolution of markets and= technology may bring different categories within scope over time. Similarly, the section titled "Impact on Internet evolution" seems to= argue against regulation of the Internet, but in the final section there i= s no recommendation against regulation, just a request to involve all stake= holders when discussing it. As above, in my view it is unrealistic to expect that governments and regul= ators will be content to exempt the internet from regulation. As also stat= ed above, the many privacy, antitrust and other issues that have surfaced r= elating to the tech sector over the last several years have led to an envir= onment where an increase in regulation is both pretty much guaranteed and n= ecessary. It would be nice if we could understand better what is the objective = that the IAB wants to achieve with this statement and what does it actually= recommend, before commenting further. I agree that it would be useful to see some clarification regarding both th= e objective behind the statement and the recommendation itself. Andrew --_000_LO2P265MB0573C0D8F8D9D7ECF4E472AFC2760LO2P265MB0573GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Vittorio Bertola <vittorio.bertola@open-xchange.com= > wrote on Mon, 09 September 2019 15:26
 
In the DNS section, it is disheartening t= o read the IAB stating that "[a DNS resolver] returning the wrong (or = no) address breaks the trust that users have in this infrastructure", = after having spent months on the ADD list and elsewhere to explain that there are indeed lots of use cases in which users= expect, or even actively request, that their resolver applies filters to t= he responses. In some cases it is actually the opposite - if I acquire a DN= S-based service to prevent any accidental connection to malware-infected websites and then I get malware, that's when= I lose trust in my DNS resolver; same for parental controls.
 <= /div>
I believe that the broad assertion that “all DNS filtering is wr= ong” suggests a lack of understanding in the way that many users and = entities use DNS as a control surface in a variety of contexts.  There= are large classes of users that would disagree with the insistence that a DNS resolver must return the correct address in every= case. 
 
 
More generally, the entire document sound= s like a claim that the Internet's infrastructure and those who run it need= to be exempt from cooperation with law enforcement activities, and totally= unregulated.
 <= /div>
In my view it is unrealistic to expect that governments and regulators= will be content to allow the Internet's infrastructure and those who run t= o be exempt from cooperation with law enforcement activities, and totally u= nregulated.  Indeed the many privacy, antitrust and other issues that have surfaced relating to the tech sector o= ver the last several years have led to an environment where an increase in = oversight is both pretty much guaranteed and necessary. 
 
 <= /div>
in the recommendations, it then mentions = "endpoint-focused interventions" only to suggest that those who a= re subject to them should be listed explicitly in the regulation (which, by= the way, is not how a law can work).
 
I agree that, in most if not all cases, it would neither be practical = nor desirable to explicitly list all of the organisations that are subject = to a specific intervention.  At best it might be possible to list cate= gories of organisations in some cases, however even then the evolution of markets and technology may bring differe= nt categories within scope over time. 
 
 
Similarly, the section titled "Impac= t on Internet evolution" seems to argue against regulation of the Inte= rnet, but in the final section there is no recommendation against regulatio= n, just a request to involve all stakeholders when discussing it.
 
As above, in my view it is unrealistic to expect that governments and = regulators will be content to exempt the internet from regulation.  As= also stated above, the many privacy, antitrust and other issues that have = surfaced relating to the tech sector over the last several years have led to an environment where an increase in= regulation is both pretty much guaranteed and necessary. 
 
 
It would be nice if we could understand b= etter what is the objective that the IAB wants to achieve with this stateme= nt and what does it actually recommend, before commenting further.
 <= /div>
I agree that it would be useful to see some clarification regarding bo= th the objective behind the statement and the recommendation itself.
 
 
Andrew
 <= /div> --_000_LO2P265MB0573C0D8F8D9D7ECF4E472AFC2760LO2P265MB0573GBRP_-- From nobody Tue Nov 12 22:57:38 2019 Return-Path: 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 DD3111200CD for ; Tue, 12 Nov 2019 22:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 eUCdReCDGrij for ; Tue, 12 Nov 2019 22:57:34 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100079.outbound.protection.outlook.com [40.107.10.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203EE120851 for ; Tue, 12 Nov 2019 22:57:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YppsvgFQhtirWbxTiQ425inhfb5E4sKuyzgMOxKIp6NLXw9qw3O0+R8NijWBQuvjSHo2SqZgUI+rfzJzU3DomHt2oiH2NmUvi+MmGld5Ie0dhdpUAas/+/V9KLA1fC1vkTk/ZpamInQbxOWLVxAt9gpYpvh0bEKJ4+3wvyCh8kXo7JxO35xRak1zPKAiW/salawPbWNsRO7PJrxomip4QOflUu5yOUtPC0fW9neae3HTliXRuz7cWSk75XMYExhaTRrZcBJ2KSktEDv3WgzYscQlJSz88SMRpX14E1W1rEd2jDFed8Fg4FN9xma2rG64YU1o7rO9ndDKYek1WOc/7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DgXjAs8OUbzVc11yH4wagFdlxNU9m6VWYbjAGm2LTqI=; b=bcqt7R0bwYzHgX0iOiygthUwd9Bgf/1VbzpgJmlpEynzMsUN4SM2pt3HHua3DaKULppNOWCUGo549skc63m/ZA8+DIUJp2r4tFurnchg49HRKWBsPwJqYunhAcmPOCYihHs4+IkDMAOxeV59C+RXNTMDUYgx94T1VMnAY7MDv6pwqIvYhar4c9y6rvzpAAfvvPvRGOBPA3jMs3Znp0KV+Kum3HKtZ7qWogk8iVMOPvPVBYOvMB5765BzTNEhi0c+uPttJ70wHt0Kf/4LkLConzXc8PJChKWMFc1GToJYekU7SsjbT2sa2Ex65iXDq1jePpVlfYBZ0tSTjqtH6BOQTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DgXjAs8OUbzVc11yH4wagFdlxNU9m6VWYbjAGm2LTqI=; b=rFnGdloLpFizch9h3rnXXb/hEraDcdJ6fEXkuALHg8Z1tQwfb1v7oAofZjVFW9sDXSntqZDVprZzvf0nTtuU3apGsb9ELFP/iaSFJ/4ZJEhjbO+f946hVt+QbQ5HZP9gGdNzEJUWr0tcrxJiKmw46TKjRGBdgxvzsaxHXBf1OMM= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0542.GBRP265.PROD.OUTLOOK.COM (10.166.99.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.23; Wed, 13 Nov 2019 06:57:31 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2430.028; Wed, 13 Nov 2019 06:57:31 +0000 From: Andrew Campling To: "architecture-discuss@ietf.org" Thread-Topic: [arch-d] Centralization or diversity Thread-Index: AdWZ752tpDRmE2LzSyqR1/ftRTJmbQ== Date: Wed, 13 Nov 2019 06:57:31 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [109.151.10.212] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35cdf942-c086-4eb3-026a-08d76806c15f x-ms-traffictypediagnostic: LO2P265MB0542: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(136003)(39830400003)(346002)(366004)(376002)(189003)(199004)(52536014)(33656002)(2501003)(66574012)(30864003)(66066001)(66476007)(66556008)(186003)(2351001)(6506007)(55016002)(64756008)(9686003)(66446008)(76116006)(7696005)(66946007)(5640700003)(5660300002)(6306002)(476003)(229853002)(102836004)(6116002)(6436002)(3846002)(99286004)(14444005)(25786009)(256004)(6916009)(508600001)(316002)(86362001)(71200400001)(966005)(8936002)(14454004)(6246003)(44832011)(2906002)(8676002)(7736002)(305945005)(74316002)(71190400001)(26005)(81156014)(81166006)(486006)(46492004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB0542; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rrNAR0tsjQu3rWtD+DvyF6HTs+fE56yBUwvf1R2oTDU0zMSCWbZvjkehw7nb2nIjzatkGkLDuS7a7UWsS90qeYJSfIgYnWco/U5ggFP3PVk0x0oZ8b1mQBIyhJJlVh4UsEc/cU3XDZ/ceJXz58lyD4tnlGET6uJzfBmnsLKWtKOy8OQaxH0WT3o4MmRD2AxR83ALpFJoGLwFcn8fAQOh64a0Mya2yEYRytKm+zYlqFVIQJ/e8EAMJQWgLyI/bW4xU+oB7Uc6V2TaB4QDV96MW/LPQPH3AIZqaqXJfbMtnZrQEe96HUMWayUfepPGI5xSaxQlkwnWakZxZwOQcpqaKSt47WIqoA6Uku0WoY+dn1Oa5ozNQbq+3nv5zXjEXCDLXowoc0aY0b4v8f8LpPfUkiX6+uDXjHeoysSi1JLb6k8JtaZGvaRDdUwb4YYDi0aY x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573A1353911BFDD554DE5C8C2760LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 35cdf942-c086-4eb3-026a-08d76806c15f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 06:57:31.8826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PVn/gGiX1BGa8l6uxW60WHbJDlBfFseCqIrQY8H7HwKKo+wzbSV/eLpd+K/4DY6AUDrCPd4nMe8iYq7LNaLgiJfZT22hjZ7fxNMn8vIUG8A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0542 Archived-At: Subject: Re: [arch-d] Centralization or diversity 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 06:57:37 -0000 --_000_LO2P265MB0573A1353911BFDD554DE5C8C2760LO2P265MB0573GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Martin Thomson" > wrote on Tue= , 05 November 2019 22:58: The draft specifically calls out the notion of a single point of fail= ure being a problem. But my experience with centralized services is that t= hey aren't centralized in the fault tolerance sense. If I look at the big = services, that scale is only achieved with careful distributed systems desi= gn. Name any modern service of even modest scale and you generally find ex= cellent fault tolerance. I thought that the document made it quite clear that it wasn't specifically= referring to a single point of failure in a technical, fault tolerance sen= se. In fact it made this clear by, for example, also highlighting issues s= uch as "administrative or governance system can become weak through too muc= h power or imagined power concentratred in one place". Finally, I don't like the emphasis on DNS in this document. It only = serves to sensationalize. I thought that the reference to DNS was particularly helpful given one of t= he potential side-effects of the push behind DoH could be to centralise wha= t is currently a highly decentralised system. I agree with the comment in = section 4 that "where such centralised points are created, they will eventu= ally fail, or they will be misused through surveillance or legal actions re= gardless of the best efforts of the Internet community. The best defense t= o data leak is to avoid creating that data store to begin with". In addition, noting the references to RFC 1958 and RFC3935, I believe that = it would be prudent for RFC8484 to be reviewed accordingly. Andrew --_000_LO2P265MB0573A1353911BFDD554DE5C8C2760LO2P265MB0573GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
"Martin Thomson" <mt@lowentropy.net> wrote on Tue,= 05 November 2019 22:58:
 
The draft specifically calls out the noti= on of a single point of failure being a problem.  But my experience wi= th centralized services is that they aren't centralized in the fault tolera= nce sense.  If I look at the big services, that scale is only achieved with careful distributed systems design.  = Name any modern service of even modest scale and you generally find excelle= nt fault tolerance.
 <= /div>
I thought that the document made it quite clear that it wasn’t s= pecifically referring to a single point of failure in a technical, fault to= lerance sense.  In fact it made this clear by, for example, also highl= ighting issues such as “administrative or governance system can become weak through too much power or imagined power concentratr= ed in one place”. 
 
Finally, I don't like the emphasis on DNS= in this document.  It only serves to sensationalize.
 
I thought that the reference to DNS was particularly helpful given one= of the potential side-effects of the push behind DoH could be to centralis= e what is currently a highly decentralised system.  I agree with the c= omment in section 4 that “where such centralised points are created, they will eventually fail, or they will be = misused through surveillance or legal actions regardless of the best effort= s of the Internet community.  The best defense to data leak is to avoi= d creating that data store to begin with”. 
 
In addition, noting the references to RFC 1958 and RFC3935, I believe = that it would be prudent for RFC8484 to be reviewed accordingly. 
 <= /div>
 <= /div>
Andrew
&nb= sp;
 <= /div> --_000_LO2P265MB0573A1353911BFDD554DE5C8C2760LO2P265MB0573GBRP_-- From nobody Wed Nov 13 02:50:57 2019 Return-Path: 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 60637120113 for ; Wed, 13 Nov 2019 02:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 l81v0qH0XIV5 for ; Wed, 13 Nov 2019 02:50:50 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 9D7E11208B7 for ; Wed, 13 Nov 2019 02:50:49 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id a15so1777108wrf.9 for ; Wed, 13 Nov 2019 02:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2xv4QcbB4LXDzMuUWGWZDOoDhDXfXRkHNJs9WjBhb94=; b=o9na8mibfz/NqcTM16VyUVGEyevjDNmMnzmN7PA5II2p+/vA5JhHoukflATOP3qXGE 0TsLXo9IThgeVMVFT9rmJ0x7bg3ZJa+8C1IMeYD0TU5NB/HTYGu/fHF3QbdQfMy62alG lGT7bkVZHV35FAUQWDMsA3AH4P9LK+pjRUIsr1YA102Es5RIaNYeaIuSiBZtBIhxXBvl /QScz1lWN5bu0Ej3ODNJztLFfPBD9/px2ZA7za8cabbp5jJ7Py8tkhcXtM8bP/P3tXUg x5IdTF1qFqZOEI0J4ot6DYQ5Vr+i0F+dpmbI8Avbkb0UNoF7zJYp6cuIZy73iwLckt3g ddPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2xv4QcbB4LXDzMuUWGWZDOoDhDXfXRkHNJs9WjBhb94=; b=bbUDvQH5Pw705tcAueNXgPGve5EmJ0T0YqdU7HJkR8ZSfnPnDxSG0OEKwJxEtUIvG8 X7EOJjbiO2O0WNIv7uLtNzmpv1Y4CVjr2XgtauZ+SuuhFe0wncWEosLm42PGcAp7sGGp jVocEhjOXf2BvAmMGK/duokLw8lUjlmbxD8t/Wau4p8zgaX1xdWdidDplMp1VgMDnMJP kFvGVn/pIGcQW879ftd8PYk5pnWi+jjY2xTc9nmvnnABINUQ7sejZGl4m5tCtUxPjtrs D7AmWnX0URHcG9GoEoMNu/wC1kgZNMQqQpfIMrJ0sve0jWl4CFW8H/aoMlVv6GNrF/+S Ldhg== X-Gm-Message-State: APjAAAUmGmvejtvq1pYVPLBkW8BkRBjCtqCzeSjdmwDQ5whP0cqDTB7K yfUXUeCUq0gAOdWWiKzyzqM= X-Google-Smtp-Source: APXvYqwZ6UcAt7Od9KE9S3ZSHoHs1+wy/HdoVlB+0BTGNJQXt2CbNigX1xXkFbnTq5Jsa0GxU7ywkg== X-Received: by 2002:adf:d1a3:: with SMTP id w3mr2340200wrc.9.1573642248193; Wed, 13 Nov 2019 02:50:48 -0800 (PST) Received: from broadband.bt.com ([2a00:23a8:4140:0:a073:2c40:39ac:6449]) by smtp.gmail.com with ESMTPSA id f14sm2329467wrv.17.2019.11.13.02.50.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 02:50:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Stewart Bryant In-Reply-To: <20191113004148.D153A1945738@fafnir.remote.dragon.net> Date: Wed, 13 Nov 2019 10:50:46 +0000 Cc: Bernard Aboba , IAB IAB , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <737AAD41-E4EC-4087-AD46-4A1934B98815@gmail.com> References: <157284936054.13440.20144182660413459@ietfa.amsl.com> <20191113004148.D153A1945738@fafnir.remote.dragon.net> To: Paul Ebersman X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 10:50:56 -0000 > On 13 Nov 2019, at 00:41, Paul Ebersman = wrote: >=20 > b.aboba> The robustness principle is *fundamental* to the operation of > b.aboba> the Internet, which is about the interconnection of vast > b.aboba> numbers of disparate implementations. >=20 > +1 >=20 > Anyone who thought they were getting interoperability but were sold > protocol conformance can tell you why the robustness principle is = vital. > While it may sometimes more resemble bondo or duct tape than we'd = like, > interoperability is what the internet runs on. >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss No matter how correct the implementation of a protocol was, from time to = time an instantiation will break, be it from human or natural causes. = Robustness is what causes the system as a whole to continue to operate = despite the (accidental) milevance of a small number of actors. As such = it is essential to the operation of any complex system. - Stewart From nobody Wed Nov 13 13:56:06 2019 Return-Path: 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 62F26120809 for ; Wed, 13 Nov 2019 13:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 dhhYRgYvPuat for ; Wed, 13 Nov 2019 13:56:02 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id F38AB1200DB for ; Wed, 13 Nov 2019 13:56:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4DFE066012D; Wed, 13 Nov 2019 23:56:00 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1GdwTtLXXRJ; Wed, 13 Nov 2019 23:55:59 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 050666600DF; Wed, 13 Nov 2019 23:55:59 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <3db77634-6edf-4047-b758-f83a462420b7@www.fastmail.com> Date: Wed, 13 Nov 2019 23:53:58 +0200 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <37DD022E-DEEF-40E6-9170-F6624E93E014@piuha.net> References: <3db77634-6edf-4047-b758-f83a462420b7@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [arch-d] Centralization or diversity 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 21:56:04 -0000 Martin, Thanks for your read and thoughts. Inline: > The draft specifically calls out the notion of a single point of = failure being a problem. But my experience with centralized services is = that they aren't centralized in the fault tolerance sense. If I look at = the big services, that scale is only achieved with careful distributed = systems design. Name any modern service of even modest scale and you = generally find excellent fault tolerance. As Andrew points out, the draft indeed notes that even on a technical = side there are issues that can cause a distributed system to fail, e.g. = management systems failing. So yes, we have learned to build distributed = systems quite well, but it does not remove all causes of errors in those = systems. History of failures even in large systems tends to support this = notion... > This draft really wants to say something less negative: that it values = diversity on multiple axes. The draft covers: >=20 > * fault domains > * geopolitical > * organizational >=20 > To which I might add: >=20 > * geographic > * implementation > * infrastructure (power, network, hardware) Here I agree with you. That=E2=80=99s a good formulation; there needs to = be diversity along several axis. > There are probably areas of diversity that are less valuable. = Protocol diversity has the effect of forcing divisions. Agree here too. > I tend to think that cryptographic diversity divides the limited = resources available for protecting and assuring system integrity. And = diversifying where standardization happens is almost certainly bad = [RFC5704]. Agree on standards; not sure about cryptographic diversity though.=20 > Finally, I don't like the emphasis on DNS in this document. It only = serves to sensationalize. Your preference is noted :-) My personal opinion is that what=E2=80=99s = happening to the DNS is an important topic. The various trends and = changes are topics that the Internet community *should* have discussions = about. In particular, there are different potential approaches to = improving privacy security of DNS with the help of DOH, with very = different implications for people=E2=80=99s privacy. There=E2=80=99s = potential here for much bigger improvements as well as downsides than = for most other current technology changes in the Internet. I think it = would be prudent of us to evaluate them carefully, and raise issues = where we see them. In my mind, that=E2=80=99s the only way we can = improve. Jari From nobody Wed Nov 13 13:59:30 2019 Return-Path: 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 7C3FB120809 for ; Wed, 13 Nov 2019 13:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 HVhpeW7i_6ML for ; Wed, 13 Nov 2019 13:59:27 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id CD1891200DB for ; Wed, 13 Nov 2019 13:59:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 01AA866012D; Wed, 13 Nov 2019 23:59:25 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXlM6Yf9IFL7; Wed, 13 Nov 2019 23:59:22 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id D99BF6600DF; Wed, 13 Nov 2019 23:59:22 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <3db77634-6edf-4047-b758-f83a462420b7@www.fastmail.com> Date: Wed, 13 Nov 2019 23:59:22 +0200 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9E8CB681-8B0A-42D2-9594-57C4C622E602@piuha.net> References: <3db77634-6edf-4047-b758-f83a462420b7@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [arch-d] Centralization or diversity 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 21:59:29 -0000 Martin, Thanks for your read and thoughts. Inline: > The draft specifically calls out the notion of a single point of = failure being a problem. But my experience with centralized services is = that they aren't centralized in the fault tolerance sense. If I look at = the big services, that scale is only achieved with careful distributed = systems design. Name any modern service of even modest scale and you = generally find excellent fault tolerance. As Andrew points out, the draft indeed notes that even on a technical = side there are issues that can cause a distributed system to fail, e.g. = management systems failing. So yes, we have learned to build distributed = systems quite well, but it does not remove all causes of errors in those = systems. History of failures even in large systems tends to support this = notion... > This draft really wants to say something less negative: that it values = diversity on multiple axes. The draft covers: >=20 > * fault domains > * geopolitical > * organizational >=20 > To which I might add: >=20 > * geographic > * implementation > * infrastructure (power, network, hardware) Here I agree with you. That=E2=80=99s a good formulation; there needs to = be diversity along several axis. > There are probably areas of diversity that are less valuable. = Protocol diversity has the effect of forcing divisions. Agree here too. > I tend to think that cryptographic diversity divides the limited = resources available for protecting and assuring system integrity. And = diversifying where standardization happens is almost certainly bad = [RFC5704]. Agree on standards; not sure about cryptographic diversity though.=20 > Finally, I don't like the emphasis on DNS in this document. It only = serves to sensationalize. Your preference is noted :-) My personal opinion is that what=E2=80=99s = happening to the DNS is an important topic. The various trends and = changes are topics that the Internet community *should* have discussions = about. In particular, there are different potential approaches to = improving privacy security of DNS with the help of DOH, with very = different implications for people=E2=80=99s privacy. There=E2=80=99s = potential here for much bigger improvements as well as downsides than = for most other current technology changes in the Internet. I think it = would be prudent of us to evaluate them carefully, and raise issues = where we see them. In my mind, that=E2=80=99s the only way we can = improve. Jari From nobody Wed Nov 13 14:29:34 2019 Return-Path: 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 0491A120807 for ; Wed, 13 Nov 2019 14:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 d4T7pgEYSMoJ for ; Wed, 13 Nov 2019 14:29:31 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B183F120119 for ; Wed, 13 Nov 2019 14:29:31 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 6B5EB3740155; Wed, 13 Nov 2019 14:29:30 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id E72EC194CFA1; Wed, 13 Nov 2019 15:29:29 -0700 (MST) Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id E1B9F194CFA0; Wed, 13 Nov 2019 15:29:29 -0700 (MST) From: Paul Ebersman To: Andrew Campling cc: "architecture-discuss@ietf.org" In-reply-to: References: Comments: In-reply-to Andrew Campling message dated "Wed, 13 Nov 2019 06:53:55 +0000." X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70824.1573684169.1@fafnir.local> Date: Wed, 13 Nov 2019 15:29:29 -0700 Message-Id: <20191113222929.E72EC194CFA1@fafnir.remote.dragon.net> Archived-At: Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 22:29:33 -0000 acampling> In the DNS section, it is disheartening to read the IAB acampling> stating that "[a DNS resolver] returning the wrong (or no) acampling> address breaks the trust that users have in this acampling> infrastructure", after having spent months on the ADD list acampling> and elsewhere to explain that there are indeed lots of use acampling> cases in which users expect, or even actively request, that acampling> their resolver applies filters to the responses. In some acampling> cases it is actually the opposite - if I acquire a DNS-based acampling> service to prevent any accidental connection to acampling> malware-infected websites and then I get malware, that's when acampling> I lose trust in my DNS resolver; same for parental controls. acampling> I believe that the broad assertion that ``all DNS filtering acampling> is wrong'' suggests a lack of understanding in the way that acampling> many users and entities use DNS as a control surface in a acampling> variety of contexts. There are large classes of users that acampling> would disagree with the insistence that a DNS resolver must acampling> return the correct address in every case. Yes. A recent post from Hugh Dixon in the ADD list quotes RFC 7258: "Pervasive Monitoring (PM) is widespread (and often covert) surveillance through intrusive gathering of protocol artefacts, including application content, or protocol metadata such as headers." "While PM is an attack, other forms of monitoring that might fit the definition of PM can be beneficial and not part of any attack, e.g., network management functions monitor packets or flows and anti-spam mechanisms need to see mail message content" He points out that sometimes monitoring is not an attack. My take from RFC 7258 is that the key differentiator is user knowledge and/or consent, i.e. if the user is not aware they are being monitored and/or has not consented explicitly to altered data (in this case DNS answers), that is what RFC 7258 considers an attack. In the use case of DNS filtering, if the user is both aware of the alteration of DNS answers (and why/how they might be altered) and has consented via opt-in, that is a *service*, not an attack. While there is not consensus in ADD/ABCD on the long term effectiveness of DNS filtering as a control plane to enhance security, it is currently a wide spread technique that much of the internet uses and finds value with. As Andrew said, we and the IAB should not be making blanket statements that "all DNS filtering is wrong" as that doesn't correctly reflect all of our stakeholders, considering the use case of user approved filtering. acampling> In my view it is unrealistic to expect that governments and acampling> regulators will be content to allow the Internet's acampling> infrastructure and those who run to be exempt from acampling> cooperation with law enforcement activities, and totally acampling> unregulated. Indeed the many privacy, antitrust and other acampling> issues that have surfaced relating to the tech sector over acampling> the last several years have led to an environment where an acampling> increase in oversight is both pretty much guaranteed and acampling> necessary. Agreed. Recent government panels in the UK and Australia on DoH and concerns that this will break DNS filtering, even in cases where the users wish to have it, shows that governments and law enforcement will push back on technical standards. This is particularly likely if we don't include them as stakeholders in discussions and help them understand what these protocols do (and don't do). This doesn't mean I'd advocate for government approval of IETF documents but avoiding misunderstandings we can predict in advance does make it less likely we'll be saddled with excessive and possibly ineffective regulation. acampling> It would be nice if we could understand better what is the acampling> objective that the IAB wants to achieve with this statement acampling> and what does it actually recommend, before commenting acampling> further. Agreed and something I'd love to see discussed next week. This is touchy stuff and face to face discussions seem useful. From nobody Wed Nov 13 15:37:37 2019 Return-Path: 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 D49F9120842 for ; Wed, 13 Nov 2019 15:37:35 -0800 (PST) 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=mnot.net header.b=2m3Nfr96; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A6BSUo91 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 LFiRJf9fd6rs for ; Wed, 13 Nov 2019 15:37:32 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA80120837 for ; Wed, 13 Nov 2019 15:37:32 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DC7D7220AF; Wed, 13 Nov 2019 18:37:31 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 13 Nov 2019 18:37:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=2 RHEzPBFSV3pci9CojcMzBmFPx0q2qFMoeBzPsrT7WI=; b=2m3Nfr96suXQd/cY/ iqHEKiyOWqjELImIsV4xxulwNgGCVy+KAWSmz3oO0tYdGAcgbq2Gq7aHFprR+VYE GtTHYj5zW8NiR6y1Tz0MwS8s0C5t4KDvvyCboaW2jpoLj2/s6nVoM7ehVqFk2Zyw oOc/Rb3MtgCefRxO76JNAiJwXMKBkLXsfTOZKv1E2nOkQb91hpZVov8RmHEpKI5Z mNZDOg7TP/K/sTTEQ7dFfbRHpX4+M1fuEVvtsUfdxcJM3qqpd5/raJL9u/oRk8KJ bPBvRKLLGwkAyO4unVZyxfmt0pq33W+I0D4LmCd7dfJgpVNu46sB1V+6IDyoWsFR J8hFg== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=2RHEzPBFSV3pci9CojcMzBmFPx0q2qFMoeBzPsrT7 WI=; b=A6BSUo91Dw85fBuwED+mXVu1TwBGUsFwfliKAhZTBXxuyjWZyV0tF3KzK 2uFdWWFZ1Qpo0XRJ48LQTHEWEv+LQWVyPjwWCR0JqbdW7sOEWpVhavOkm9fgphmy RNyYKFJOBKX1RJEkIOs/Mg8EWG1arerf6XoCRnwxOsy0LjEnVHFtd2HJbLrOxrpT w/f2j3eNXeW2aawI8BkevBKriJnqAlT4snB984Z9iQPB/2FMDRLU7Mf4uW4etEw0 cgQWq4zKIcOcp0KXfX2UmpO1xj+1Ll6vNBqq/8bXSL/Hu6VfezhiQIBx5XxoVzrn gkh82G2xsDZY1Wzjm90cLTW0svCzA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudefvddguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucfrrghrrghm pehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id F26FE306005F; Wed, 13 Nov 2019 18:37:27 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Mark Nottingham In-Reply-To: <20191113222929.E72EC194CFA1@fafnir.remote.dragon.net> Date: Thu, 14 Nov 2019 10:37:24 +1100 Cc: Andrew Campling , "architecture-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <89C3177C-5F83-4477-8B9E-7EF6844C7049@mnot.net> References: <20191113222929.E72EC194CFA1@fafnir.remote.dragon.net> To: Paul Ebersman X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 23:37:36 -0000 On 14 Nov 2019, at 9:29 am, Paul Ebersman = wrote: >=20 > My take from RFC 7258 is that the key differentiator is user knowledge > and/or consent, i.e. if the user is not aware they are being monitored > and/or has not consented explicitly to altered data (in this case DNS > answers), that is what RFC 7258 considers an attack. >=20 > In the use case of DNS filtering, if the user is both aware of the > alteration of DNS answers (and why/how they might be altered) and has > consented via opt-in, that is a *service*, not an attack. 7258 doesn't say anything about consent or "user knowledge," so I don't = know how you took that away from the document. Putting that aside, assuming that consent (or its oft-relied upon = variant, "informed consent") is adequate to protect users relies on = users' ability to understand how the Internet works, how their data will = be used, how it could be misused, how changes in policy, law, or entity = ownership might affect its handling, the nature of any security = vulnerabilities introduced by third parties involvement in their = communication. If the consent is long-lived (as it would be with DNS), = they have to remember it over that period of time, for each interaction. = They also have to intersect this consent with others that they give -- = often leading to "consent fatigue" (see: GDPR cookie notices and privacy = policy changes). That doesn't mean that we should never allow a user to make a choice, = but we need to think carefully about the systemic effects of the points = where we allow such a choice; there is ample evidence that most users = _don't_ understand the choice they're making, and can be led into pretty = hazardous situations as a result. Right now, unencrypted DNS via DHCP doesn't give users a choice at all; = they use the DNS results returned by their network, without any consent = (beyond using the network -- which in most peoples' minds is "the = Internet."). They can, however, choose to use a different DNS server by = configuring it, or they can choose to configure an encrypted DNS server.=20= The sticking point here is that DoH allows someone to avoid their = network making that choice for them (with a lot of fuzziness about how = consent is obtained). There are user-centred arguments as to why it's = necessary to impose that policy at the network level (eg., lack of = interfaces to configure IoT devices), but let's not start from the = assumption that the best place to interpose those services is by having = the network transparently handle them, just because that's how it's been = done before. Let's also not assume that obtaining consent explicitly = from the user to interpose those services is easy or without risks of = various sorts; we have lots of examples where allowing random devices on = networks to ask permission to do things ended up badly. > As Andrew said, we and the IAB should not be making blanket statements > that "all DNS filtering is wrong" as that doesn't correctly reflect = all > of our stakeholders, considering the use case of user approved > filtering. That is not a quote from the document. In context, the statement is = cautioning that legislation or regulation that requires DNS servers to = give false answers could have systemic effects on trust. > Agreed. Recent government panels in the UK and Australia on DoH and > concerns that this will break DNS filtering, even in cases where the > users wish to have it, shows that governments and law enforcement will > push back on technical standards. Australian here; could you point me to the event you're talking about? = Because I see no evidence yet that the Australian government will "push = back" on DoH. There are some people who are trying to stir up a = controversy around it, and a lot of misinformation flying about, but = nothing from the government itself, AFAICT. > This is particularly likely if we > don't include them as stakeholders in discussions and help them > understand what these protocols do (and don't do). >=20 > This doesn't mean I'd advocate for government approval of IETF = documents > but avoiding misunderstandings we can predict in advance does make it > less likely we'll be saddled with excessive and possibly ineffective > regulation. I agree that we need to do better in working with the various parts of = the Internet community, including governments. I'd be loathe to give = them any special status, though, as that would fundamentally change the = nature of the IETF, and the Internet. Chers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Nov 13 15:43:52 2019 Return-Path: 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 B953012004E for ; Wed, 13 Nov 2019 15:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 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_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 5eg8mB8wQ3XE for ; Wed, 13 Nov 2019 15:43:48 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE321120848 for ; Wed, 13 Nov 2019 15:43:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7198FBE39; Wed, 13 Nov 2019 23:43:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSUr2zjnoH01; Wed, 13 Nov 2019 23:43:44 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB772BE2E; Wed, 13 Nov 2019 23:43:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1573688624; bh=E1Nab44Pc4iYG5I9kiPmpT88P3qREPz+hLpYhypj3cM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=1jzGtM8Q22CC6hEgSMf5IU9mAbqGmdpoZP2v0KVBDJgr7vjEZkeaI1KRjHvb07fvg wQB3Vcouzh5tMlWvqY85KRg3r8nPz70EYrfGHmMsfW5hz+Wcz4gJFYuZS0PKs4+25N sJVf9tVEL1UrtuNyUbI9iQz4QRKmA4ILrrrexNrs= To: Paul Ebersman , Andrew Campling Cc: "architecture-discuss@ietf.org" References: <20191113222929.E72EC194CFA1@fafnir.remote.dragon.net> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <439b62c2-5e82-ec48-5639-0e25b33f03e1@cs.tcd.ie> Date: Wed, 13 Nov 2019 23:43:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191113222929.E72EC194CFA1@fafnir.remote.dragon.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oiHQXddpdao2s5I52AgYQrDKF83lBFUbb" Archived-At: Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 23:43:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oiHQXddpdao2s5I52AgYQrDKF83lBFUbb Content-Type: multipart/mixed; boundary="zpQCcyT27ZkiyVInGEB30PQG0DDX7t0Bw"; protected-headers="v1" From: Stephen Farrell To: Paul Ebersman , Andrew Campling Cc: "architecture-discuss@ietf.org" Message-ID: <439b62c2-5e82-ec48-5639-0e25b33f03e1@cs.tcd.ie> Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure" References: <20191113222929.E72EC194CFA1@fafnir.remote.dragon.net> In-Reply-To: <20191113222929.E72EC194CFA1@fafnir.remote.dragon.net> --zpQCcyT27ZkiyVInGEB30PQG0DDX7t0Bw Content-Type: multipart/mixed; boundary="------------16D89090FE494874B9FF2183" Content-Language: en-US This is a multi-part message in MIME format. --------------16D89090FE494874B9FF2183 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm feeling confused as I responded to exactly this para on another list (add) that was explicitly setup to avoid discussion related to DNS privacy and co being spread over multiple lists, so can we please use one list and not have the same discussion in two places? On 13/11/2019 22:29, Paul Ebersman wrote: > My take from RFC 7258 is that the key differentiator is user knowledge > and/or consent, i.e. if the user is not aware they are being monitored > and/or has not consented explicitly to altered data (in this case DNS > answers), that is what RFC 7258 considers an attack. My response on the add list is at [1]. S. [1] https://mailarchive.ietf.org/arch/msg/add/K8D7lVcDd8uheDVoo6wnMjtrZ9g= --------------16D89090FE494874B9FF2183 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------16D89090FE494874B9FF2183-- --zpQCcyT27ZkiyVInGEB30PQG0DDX7t0Bw-- --oiHQXddpdao2s5I52AgYQrDKF83lBFUbb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3MlTAACgkQWrL68XsX K+q3+Q//bgFk8nDHlMF0H0CcYrWQQIprLcOb/NKxR4oEButBx0wUjUNemKA4jjss 1cCDkKUWmrua+ze7VCtxEJzlihnx1Z8pFgi7KR/+SeMmdHupiXC7fbjyY+e0h8KQ StjQhMK5iXA6/qrX1qwnWoNbHghBGHX9J0T1LpicG388FFY5UL90fKv23vbb1f8o 8SeeMS9nqy68n36Icmx6Icz/cDlDw3l+ANtxuuAjBzQQdgusIY4d661TNfwIuc7e MTpbtGAkSpwm3BRCvKSNeB+xq9UCSj78epFIbEKv7pNQrB1VzqddeE+VGoW+fxPF wjGWbKAmQfDIIyYmiH4RRq/Ar53SiZfneOy2jffx5ebGyEU5c9W6271NYmmh6Pa5 bNXONTz8UEWV2SA2+Oj3y6EYntxHJz48voY0mPT0Oumm3q6z/2VTND7TJo41sZf0 cTP/fSg+kr4VSPs8lb2zKzu/qHx1ePOGr4TiX5AjgiU3JjMNjxA1zL9jnAdqZLBM rULf2rt1SQbO0ddVaH4iuCvVL3z7tejsFxI6pspin1AVrQqlj2GLNsAFRgn5Z87Z WZW9yCunKJX1zitK7ZafXwg9rn3YKiH43n3feGooZ6ftdtYSLW4WJ/UskIAh6A16 JnqncIMGA7j/yQxK0BTxgvndPGZbmUJCHjwllkH22l4rWO2hcuM= =KDx6 -----END PGP SIGNATURE----- --oiHQXddpdao2s5I52AgYQrDKF83lBFUbb-- From nobody Wed Nov 13 15:47:40 2019 Return-Path: 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 7D48C120848 for ; Wed, 13 Nov 2019 15:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3xpA1OaPa-cO for ; Wed, 13 Nov 2019 15:47:37 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3171120018 for ; Wed, 13 Nov 2019 15:47:36 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 990F03740304; Wed, 13 Nov 2019 15:47:36 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 734E4194D9B1; Wed, 13 Nov 2019 16:47:36 -0700 (MST) Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 72B21194D9B0; Wed, 13 Nov 2019 16:47:36 -0700 (MST) From: Paul Ebersman To: Stephen Farrell cc: "architecture-discuss@ietf.org" In-reply-to: <439b62c2-5e82-ec48-5639-0e25b33f03e1@cs.tcd.ie> References: <20191113222929.E72EC194CFA1@fafnir.remote.dragon.net> <439b62c2-5e82-ec48-5639-0e25b33f03e1@cs.tcd.ie> Comments: In-reply-to Stephen Farrell message dated "Wed, 13 Nov 2019 23:43:44 +0000." X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72970.1573688856.1@fafnir.local> Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Nov 2019 16:47:36 -0700 Message-Id: <20191113234736.734E4194D9B1@fafnir.remote.dragon.net> Archived-At: Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 23:47:39 -0000 +1 DoH was invoked here but without the benefit of a bunch of discussion already on ADD. Would love to see anything DNS/DoH related moved back there until we have some consensus. Stephen. Sorry. Saw this here first and responded. Should have done redirect then. sfarrell> I'm Feeling Confused As I Responded To Exactly This Para On sfarrell> Another List (Add) That Was Explicitly Setup To Avoid sfarrell> Discussion Related To Dns Privacy And Co Being Spread Over sfarrell> Multiple Lists, So Can We Please Use One List And Not Have The sfarrell> Same Discussion In Two Places? = stephen.farrell> My response on the add list is at [1]. stephen.farrell> [1] https://mailarchive.ietf.org/arch/msg/add/K8D7lVcDd8u= heDVoo6wnMjtrZ9g From nobody Sat Nov 16 08:26:41 2019 Return-Path: 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 8DF0B12011C; Sat, 16 Nov 2019 08:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=elandsys.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 7dJf34eWDUhe; Sat, 16 Nov 2019 08:26:33 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 77A9312008C; Sat, 16 Nov 2019 08:26:33 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.196.83]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xAGGQGjq012621 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Nov 2019 08:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1573921589; x=1574007989; i=@elandsys.com; bh=4z1VndO5L+c81v6WaKz6DQBRndxslNithvuWVCUYdBc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=F1pkjiMQCRJjTBZV6dkt04TM4Vefk42HEdkqjbqIb1W2Ye1c8UrQ4AHve1UcrAV6w RWjCRTuMpFawojCuQ2cC9CjyabzPc1I1uiQIXLFZ3RzhF/IrS1AziU8NjQt8nIHMHM hinODdsQc7q0KQ9TpZQpf+8UX79UyzbohCzyhQ3c= Message-Id: <6.2.5.6.2.20191116065825.0de02ba0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 16 Nov 2019 07:19:01 -0800 To: architecture-discuss@iab.org From: S Moonesamy Cc: tech-plenary@iab.org In-Reply-To: <7f516417-415b-367c-f8c5-a508942c034b@iab.org> References: <7f516417-415b-367c-f8c5-a508942c034b@iab.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] IAB report to the community 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 16:26:34 -0000 Hello, At 05:23 PM 15-11-2019, Ted Hardie wrote: >Here is the IAB report for the period between IETF 105 and IETF >106. If you have topics or issues you want to discuss by email, >feel free to send your comments to architecture-discuss@iab.org (our >public discussion list) or iab@iab.org (to reach just the IAB). The Tech Plenary is expected to be on a topic of interest to at least several IETF Areas and to "inform our work". I went through the past plenaries and noticed that there wasn't any Tech Plenary for three consecutive IETF meetings. Is it because it was difficult to get interesting speakers? Regards, S. Moonesamy From nobody Sat Nov 16 16:15:14 2019 Return-Path: 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 E49F012006E for ; Sat, 16 Nov 2019 16:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 B98uoL0xacwg for ; Sat, 16 Nov 2019 16:15:10 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 71C0912002E for ; Sat, 16 Nov 2019 16:15:10 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id e3so7340890plt.7 for ; Sat, 16 Nov 2019 16:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=TY7AM19yGYsG0fgUS94jbZmLmonzfdcGIgN1Dd1afAY=; b=wjicl+Et6ZmanQNCUKowy2rAdGlIPZvza8xVloYl/eFDQUp9mFU5c6/6d1CVj7Ci11 8B7iTZk+7UfJJiXZrLfanukxtltllvAmdMrZ0auQOjM2N2D+kycG1XFcal8073/cyobF 4Cztc7Xd00xVebZsAHdsuq2ajIC2R4GT8hW597Xa1TZAdTKLTv/JhLZxHkVKYrUu6Pov fzPl3ijBz9hfumgb0jomAiwgQkzTQn5ha5USDq1ohH8J/u1MXfjvriCDSyRBZVJHRTUl mCZxQ3mXGMN4s6jrmHOPHxwz48i+WK/E/Gto3rb6GYnyq5O578zHjNi9yy2fCTPcs3YM PFqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=TY7AM19yGYsG0fgUS94jbZmLmonzfdcGIgN1Dd1afAY=; b=ubHyfQxkVvNHe7KUw2tc3T7+QeUWyxPF7LDh7iGXKfEEOyTgK0lMB14GAsZZLWtk3d TGejc328OnRA5XHVWEsBBaW2hKyLzSVTjMUXR436n0IeY2kJis9UVyGMhE3Cpa962N/H eZnlLjUbsmKf9KmLl2NSV+kmK/5Xdh/WLY+y31MylR02ApWhzq6RDj2v474p8MQM2qYY 3FuZB5vKgWvue//09a2R/f/qJ8GZ8DjAthw5cx1pffwaW9eBuiQcF6ZYBujT73TGC4fD PemK0VpqD105SD4ONVA+XJpOVcGyfhQWihFWVWDXMcds6rshNNYYo/nPVlSOE5rkLAvC 7cmQ== X-Gm-Message-State: APjAAAX+TUZn/gLAJeZRVCnFkE/dK5AYXzCzJVHl1el0w/A8x3tnH5ha vz8EMs++EfnbJzdDvqKGyyrO X-Google-Smtp-Source: APXvYqysW0lLYzRk6FlMxiGdG6UOZVtzg+/nUlWT5vIaYhXNz9VndB2jY7VGuLO/sCfQvYGWpnoCHA== X-Received: by 2002:a17:902:8208:: with SMTP id x8mr23014517pln.6.1573949709709; Sat, 16 Nov 2019 16:15:09 -0800 (PST) Received: from dhcp-9dd2.meeting.ietf.org ([2001:67c:1232:144:d1bc:7a06:2c46:4b7e]) by smtp.gmail.com with ESMTPSA id v3sm14893036pfn.129.2019.11.16.16.15.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Nov 2019 16:15:08 -0800 (PST) To: S Moonesamy , architecture-discuss@iab.org Cc: tech-plenary@iab.org References: <7f516417-415b-367c-f8c5-a508942c034b@iab.org> <6.2.5.6.2.20191116065825.0de02ba0@elandnews.com> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: Date: Sun, 17 Nov 2019 08:15:06 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20191116065825.0de02ba0@elandnews.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="06RQDvmHbl11tLRytnYMjNlKlcmBEj8bp" Archived-At: Subject: Re: [arch-d] [Tech-plenary] IAB report to the community 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 00:15:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --06RQDvmHbl11tLRytnYMjNlKlcmBEj8bp Content-Type: multipart/mixed; boundary="fj79cFjsaAGwxhLsop2b9qcf8rnIvWhzr"; protected-headers="v1" From: Melinda Shore To: S Moonesamy , architecture-discuss@iab.org Cc: tech-plenary@iab.org Message-ID: Subject: Re: [Tech-plenary] IAB report to the community References: <7f516417-415b-367c-f8c5-a508942c034b@iab.org> <6.2.5.6.2.20191116065825.0de02ba0@elandnews.com> In-Reply-To: <6.2.5.6.2.20191116065825.0de02ba0@elandnews.com> --fj79cFjsaAGwxhLsop2b9qcf8rnIvWhzr Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/16/19 10:19 AM, S Moonesamy wrote: > The Tech Plenary is expected to be on a topic of interest to at least > several IETF Areas and to "inform our work".=C2=A0 I went through the p= ast > plenaries and noticed that there wasn't any Tech Plenary for three > consecutive IETF meetings.=C2=A0 Is it because it was difficult to get > interesting speakers? Trying to hit the sweet spot of 1) topics of broad interest, presented by 2) great speakers who are 3) available during an IETF meeting is surprisingly difficult. After a few tech plenaries that didn't work out as well as one might have liked and on which we got substantial negative feedback, we decided to not have technical plenaries unless we're pretty comfortable with the quality. We had some tentative topics lined up during that period but unfortunately speakers weren't available. We're also discussing alternatives to the current format, including things like likely smaller sessions of narrower interest at times outside the IETF plenary, etc. Also, we did get some excellent suggestions in the post-Montreal meeting survey and will be following up on some of those. Melinda --=20 Software longa, hardware brevis PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F --fj79cFjsaAGwxhLsop2b9qcf8rnIvWhzr-- --06RQDvmHbl11tLRytnYMjNlKlcmBEj8bp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl3QkQoACgkQ37iRcpp2 24/s5RAAsifwT3FLS18Fa473l3oYYUXMA9BAxicztKJLvmm2taZYPxeVlQTvaMou kIyNCy8lySkzkTLcHwA1teLEj3CE+YbZMyBBTiBlcSfn1jcxCU8aHAn36B3NUaNw XeAvpVXP7lUA44mYFw483EwE0pafejznBpOvTSTBVspFAHdqKNnfef9ThqngmtbR dEEBKtQyn2OA9e6xO74JBJdUTbaZJqsKgOXff86eIK7AhhAhBrs3M4dMalhBsVmv tdDhG1ZIRCvr9dENqrewrnhJZrP6mAaxj3O5H8sctfp32BtoJQsZ/Kc3Ti8yZkrY hbD+DSMKCTdAL8nlR5lkxURu+6alOKghUYRk/J4nIHZ97WFh3elP9D3tCsm05fsr 7LjN7o0UVUq6G4+6FOsUeAfj8rh84VKdl6MwPGSYHDC/NEK5tYs4/gxjZcfH72IH MhYXET6HUyvfq9b3y5elxVRLjJ20i37QwRpjAvxdccNXMGfY6dxSa6kpfC88ztKE lL7ziYgM72jtvKSt03fBNbC8mUSRELXe3NCJWxr1fg/q4DC/J3dJINIrn5dTI86f T0xLPYiRZRjAZSxfhKy7NW3FaI1pLr8ov2e+ELSRDL8OehfBobNn0r4EIH1XihYB Xd9w9IGP3qBhOHS3Xi9T+2l/o22fOlxx6zt23cNFbO2K7DDlxWU= =QZVb -----END PGP SIGNATURE----- --06RQDvmHbl11tLRytnYMjNlKlcmBEj8bp-- From nobody Sat Nov 16 19:00:46 2019 Return-Path: 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 9B696120823 for ; Sat, 16 Nov 2019 19:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zWK5vk1Yr77f for ; Sat, 16 Nov 2019 19:00:41 -0800 (PST) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872FF120096 for ; Sat, 16 Nov 2019 19:00:41 -0800 (PST) Received: from smtp-3-0000.mail.infomaniak.ch ([10.4.36.107]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id xAH30Wwa023998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 17 Nov 2019 04:00:32 +0100 Received: from dhcp-8264.meeting.ietf.org (unknown [31.133.130.100]) by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 9BC1A10083DE6; Sun, 17 Nov 2019 04:00:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Brian Trammell (IETF) In-Reply-To: <89C3177C-5F83-4477-8B9E-7EF6844C7049@mnot.net> Date: Sun, 17 Nov 2019 11:00:26 +0800 Cc: Paul Ebersman , Andrew Campling , "architecture-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191113222929.E72EC194CFA1@fafnir.remote.dragon.net> <89C3177C-5F83-4477-8B9E-7EF6844C7049@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 03:00:45 -0000 Hi Mark, all, Quoting below for emphasis. > On 14 Nov 2019, at 00:37, Mark Nottingham wrote: >=20 > There are user-centred arguments as to why it's necessary to impose = that policy at the network level (eg., lack of interfaces to configure = IoT devices), but let's not start from the assumption that the best = place to interpose those services is by having the network transparently = handle them, just because that's how it's been done before. This, a few hundred times. We've tried transparent network functions of various forms; for the most = part, they either work while irretrievably changing the architecture = (e.g. NAT have moved the network/transport layer header boundary to = include the transport port numbers), or they tend only to work in a = restricted set of environments (which may or may not be the environments = the functions are sold to work in, but that's a different rant). > Let's also not assume that obtaining consent explicitly from the user = to interpose those services is easy or without risks of various sorts; = we have lots of examples where allowing random devices on networks to = ask permission to do things ended up badly. In a cleaner architectural environment, we could move some of these = functions to the endpoints (e.g., replacing in-network TCP enhancement = with, well, better TCP stacks, which is largely what has happened in = server and end-user platforms space over the past couple of decades), = and transmute the rest into network functions deployed transparently, = where the function's presence is explicit, and ideally exposed to the = endpoint in such a way that the endpoint can negotiate with it. Of course, as you say, the gap between transparency to the = network/transport endpoint and informed user consent is a large one. But = it'd be nice if we could work on solving that problem, as opposed to = pretending that the accidental situation we find ourselves in with a = network cluttered with functions that try and fail to be transparent is = somehow essential to the Internet architecture, and argue about how best = to maintain that situation. It's also not lost on me that "user consent" is a slippery beast for = functions (lawful intercept) where asking for consent is antithetical to = the function at hand. In these situations, consent is given by a third = party, generally someone from the judiciary in common law jurisdictions. = But control over who gives consent is key to how the function is used = and misused even in the most pervasive cases. What the IAB is trying to do with this statement (IMHO) is to try to = separate these threads. The way most of these functions are built tends = to break things that are well outside the scope of the desired function, = without an analysis of the tradeoffs involved. Without discussion of = these tradeoffs, an informed discussion of the pros and cons of any = given in-network function is not really possible. Hence "avoiding = *unintended* harm". Cheers, Brian= From nobody Sun Nov 17 00:21:06 2019 Return-Path: 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 2F9CD1200C7; Sun, 17 Nov 2019 00:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 bZAXR_4e1h2n; Sun, 17 Nov 2019 00:21:03 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 69DEA1200C4; Sun, 17 Nov 2019 00:21:03 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.196.83]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xAH8Klok009023 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Nov 2019 00:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1573978860; x=1574065260; i=@elandsys.com; bh=WwECiW6DkzyT0SkGLffKjEClTWIlQxYQuAMrXpzJUvE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KF9TG32BDQWkMkq/uVDG6ikPFKZQbcN51gCjFeX3iFK/2bktBY5GaJqnCTxvkRAUv IW7mw6grgwa8+NVq9hvQ2QqQJiIiDfY5mTeDdtRNoo1HV2fjSpfNYnz1D/DeeWNHjZ tiN2pQt5iu8CwOx+GWvDjnFAwcsWMFFPNCOAppzs= Message-Id: <6.2.5.6.2.20191117000609.11a7d1b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 17 Nov 2019 00:20:24 -0800 To: Melinda Shore , architecture-discuss@iab.org From: S Moonesamy Cc: tech-plenary@iab.org In-Reply-To: References: <7f516417-415b-367c-f8c5-a508942c034b@iab.org> <6.2.5.6.2.20191116065825.0de02ba0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] [Tech-plenary] IAB report to the community 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 08:21:04 -0000 Hi Melinda, At 04:15 PM 16-11-2019, Melinda Shore wrote: >Trying to hit the sweet spot of 1) topics of broad interest, presented >by 2) great speakers who are 3) available during an IETF meeting is >surprisingly difficult. > >After a few tech plenaries that didn't work out as well as one might >have liked and on which we got substantial negative feedback, we decided >to not have technical plenaries unless we're pretty comfortable with the >quality. We had some tentative topics lined up during that period but >unfortunately speakers weren't available. We're also discussing >alternatives to the current format, including things like likely smaller >sessions of narrower interest at times outside the IETF plenary, etc. Thank you for the feedback. People usually find time if the event is relevant to them (please see (2) and (3)). Regards, S. Moonesamy From nobody Sun Nov 17 02:49:44 2019 Return-Path: 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 E059812007A for ; Sun, 17 Nov 2019 02:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 HDrin218gFjd for ; Sun, 17 Nov 2019 02:49:41 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A139F120059 for ; Sun, 17 Nov 2019 02:49:41 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.199.155]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xAHAn6oI020749 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Nov 2019 02:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1573987777; x=1574074177; i=@elandsys.com; bh=EeWhzO1mWut5ZB9nyZvoSbSUzH9Sji7YEn4+dHgSOMY=; h=Date:To:From:Subject:In-Reply-To:References; b=dokXoXwAzBu4cZnd8XCdF/Qtm8iJBxuokR+NmRe7f74cq+aioQxqdH5sTvQuMEJ/D ct+T2jPuesR/AHjFQTMND/chjBLhdJW7ifeK+LOjl1z3GY2Jcc5FRQAOlmVwPATeKl J+QRjTx/T7odNhlLLJjpIvt6Li1dZDlY/+cM25LU= Message-Id: <6.2.5.6.2.20191117022756.07532f60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 17 Nov 2019 02:48:19 -0800 To: Andrew Campling , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 10:49:43 -0000 Hello, At 10:53 PM 12-11-2019, Andrew Campling wrote: >In the DNS section, it is disheartening to read the IAB stating that >"[a DNS resolver] returning the wrong (or no) address breaks the >trust that users have in this infrastructure", after having spent >months on the ADD list and elsewhere to explain that there are >indeed lots of use cases in which users expect, or even actively >request, that their resolver applies filters to the responses. In >some cases it is actually the opposite - if I acquire a DNS-based >service to prevent any accidental connection to malware-infected >websites and then I get malware, that's when I lose trust in my DNS >resolver; same for parental controls. The position, in the past, was that it was important to preserve the chain of trust instead of allowing someone along the path to change the information published in DNS. There are use cases where the changes are done for valid reasons, e.g. the user does not wish to download malware. What are the unintended consequences of supporting such cases? Regards, S, Moonesamy From nobody Sun Nov 17 16:49:56 2019 Return-Path: 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 DC8AE1202DD for ; Sun, 17 Nov 2019 16:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=mGMMZ5Ql; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o/EntDoB 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 9n1keEK_F20s for ; Sun, 17 Nov 2019 16:49:48 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149D31207FD for ; Sun, 17 Nov 2019 16:49:48 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7A5AE21FE0 for ; Sun, 17 Nov 2019 19:49:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 17 Nov 2019 19:49:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:mime-version:subject:message-id:references:to :date; s=fm1; bh=gS1Q0AVZOe6rHa0jKWOkd1dKwSMYMauaCo5HIprgRN0=; b= mGMMZ5Ql/PtficJZPbZNbPwDCFVe89DgcmeqrEmpWXGujDpuzbbGTbEJbr7GIbMK ibx2emeekQvO9nH67XhAjKAT+ZQPCeNzp1ZWIjQtpyeSAH6CwxErQ2hxJc+4EAM7 LIVmK2qWP4gac8rVB0NoydYaEjqu9zCY3FmgM2chowAVtWaGcLpO1YJx3D29aEqE rTksXkNQ6NdqJRjFoGP+4kZlXM2/8uMO+pcfuDHMES7lsqvJMW12iqn0r5fv8zWe 9tj7vJKbtFKUBfuYiVMBbarNRqOjUo8ce4+0edJhi9nEpKB/LKVz+/ELVY2uywUi lwcYNxXTUxFxo7Xrf6o1MQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=gS1Q0AVZOe6rHa0jK WOkd1dKwSMYMauaCo5HIprgRN0=; b=o/EntDoB759a+Q1hb1HdbZ0mTVxdjwk2p CTmc7X88sTAAOvSbzzmF5NFwb0nKoLEALBhKfsxXExHLsryOIU2l1YYr+hxotCOZ 4aOe6fjdAGgv01wQKRKs8uy6pYDPySpXKpBWy4+TEVb39UDYQ1voaFKwf2L6E+7m n6P7AY1sKlXDZU96gha8wqxr/KkIj4QmYudJpbDgemvgF/6dqIWbZS8LQQsf3NfD UIZaUDH6h2kQqWTCgUGXBQTscDhCUoQU6hp6Io5PgoQ7ZFqc8y8zkiWlTAqtq4Jb BkMVhAK5EVCJz+KVpLvGLHb9+b4RClsIwN2lB+F/nkJmeKGeHU+RA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeggedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtggguffkfhfvfffosegrtdhmre hhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhho thdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtnecukf hppeefuddrudeffedrudehtddrudegfeenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from dhcp-968f.meeting.ietf.org (dhcp-968f.meeting.ietf.org [31.133.150.143]) by mail.messagingengine.com (Postfix) with ESMTPA id E26EC3060057 for ; Sun, 17 Nov 2019 19:49:43 -0500 (EST) From: Mark Nottingham Content-Type: multipart/alternative; boundary="Apple-Mail=_25D392BD-8568-4F0B-BB3D-A8793E29E00A" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> To: architecture-discuss@ietf.org Date: Mon, 18 Nov 2019 08:49:41 +0800 X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [arch-d] Fwd: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 00:49:54 -0000 --Apple-Mail=_25D392BD-8568-4F0B-BB3D-A8793E29E00A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI; a fairly substantial update, based upon feedback. More feedback = very welcome. Cheers, > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-iab-for-the-users-01.txt > Date: 18 November 2019 at 8:43:38 am GMT+8 > To: "Mark Nottingham" >=20 >=20 > A new version of I-D, draft-iab-for-the-users-01.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Name: draft-iab-for-the-users > Revision: 01 > Title: The Internet is for End Users > Document date: 2019-11-18 > Group: iab > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-iab-for-the-users-01.txt > Status: = https://datatracker.ietf.org/doc/draft-iab-for-the-users/ > Htmlized: https://tools.ietf.org/html/draft-iab-for-the-users-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-iab-for-the-users > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-for-the-users-01 >=20 > Abstract: > This document explains why the IAB believes the IETF should consider > end users as its highest priority concern, and how that can be done. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_25D392BD-8568-4F0B-BB3D-A8793E29E00A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI; = a fairly substantial update, based upon feedback. More feedback very = welcome.

Cheers,


Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-iab-for-the-users-01.txt
Date: = 18 November 2019 at 8:43:38 am = GMT+8
To: = "Mark Nottingham" <mnot@mnot.net>

A new version of I-D, draft-iab-for-the-users-01.txt
has been successfully submitted by Mark Nottingham and posted = to the
IETF repository.

Name: = = draft-iab-for-the-users
Revision: 01
Title:= = The Internet is for End Users
Document date: = 2019-11-18
Group: iab
Pages: 11
URL: =            https://www.ietf.org/internet-drafts/draft-iab-for-the-users-01= .txt
Status: =         https://datatracker.ietf.org/doc/draft-iab-for-the-users/Htmlized:       https://tools.ietf.org/html/draft-iab-for-the-users-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-iab-for-the-users
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-for-the-users-01<= /a>

Abstract:
=   This document explains why the IAB believes the IETF should = consider
  end users as its highest priority = concern, and how that can be done.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
Mark Nottingham  =  https://www.mnot.net/

= --Apple-Mail=_25D392BD-8568-4F0B-BB3D-A8793E29E00A-- From nobody Sun Nov 17 17:29:23 2019 Return-Path: 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 8725712002E for ; Sun, 17 Nov 2019 17:29:21 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 aJ4gQEijeEfq for ; Sun, 17 Nov 2019 17:29:19 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 5ACBA12080E for ; Sun, 17 Nov 2019 17:29:19 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id e17so1420879pgd.7 for ; Sun, 17 Nov 2019 17:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=y/JAWWFOaiPW5Cs4glMWDgllqDrxYUu5U2Kj3GvzKdI=; b=pHw8EzMKDXjqea0+rl4C1MGz+SaGjkIAsYBIkv+sWxzHl3qjU/vL5+6Yrl4d68OEHI 2bDD5Bx1E/J8XsuU6YhUFT7n5/cP3s/pIOh9sFMdsxHJBs5frWonU71uoOFzYaCG3Aww 1wXf+G4xuaPjSRdmlm/uG52jzcIeRTW/r4uh7Ov5LURnIYKbChHb8M/pRVO1CR42nvIt Q6iXZoFQOmQQebN1u1Y9+ZTrCnnqKhJKP7lW35dM2+7Yf5OGP07gx3IDmaC2EJwyd8f2 gxKWLXZht7CqHO2Vv8vaQIWfyOVg6J2TpTB5vyLkku6xsUNs/rb4Dt8ti/abUxbcXdBs ommg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=y/JAWWFOaiPW5Cs4glMWDgllqDrxYUu5U2Kj3GvzKdI=; b=jp7/cgZn27qBqF35tGb/RCX+irgw89WhF1eQM7+tRUJMAuDgnw+VBiNOysJ2bPvltl Kq0m75GAczWBzgXHAchf9m9SJXRKe5BC2lgbcbCdVjirLBae3WkumZjfOVQtuBZ72iME 7w92FWO9YdmF15uxKUI1EsBXeYct0qKNHPU23WTRzjFlVrV9k+FCYq9VANr8A2LJ5Bqi t7itEr9WjnbYfvb6qEui/Q1A7kMhwB+JiZ++rL6dJ6r0KIloFtO75ipzkuewXbVk+BZm 2rpWIUy148H2mCTt3NlM2sTVHvU3KE1E0V2y7L5y0zDfcilWhle6sJGSzxI6joDNMaTF NziA== X-Gm-Message-State: APjAAAWsuaDX+ADQ/HzCFbMFg8NuwZvsseP8vhKhgzuLeQiVifsqqF9t OqZJyyGcsh1bpVyEFsjy03lUhWGf X-Google-Smtp-Source: APXvYqwb/2lSzMZZxEUarC1X5/iUnHPqkSvSMvX5WkSLM1t9IIdXmC1K021/iiAzQsYIHLQSCPum8w== X-Received: by 2002:a63:dd51:: with SMTP id g17mr5202381pgj.388.1574040558298; Sun, 17 Nov 2019 17:29:18 -0800 (PST) Received: from [31.133.129.140] (dhcp-818c.meeting.ietf.org. [31.133.129.140]) by smtp.gmail.com with ESMTPSA id j7sm16323535pgl.38.2019.11.17.17.29.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 17:29:17 -0800 (PST) To: architecture-discuss@ietf.org References: <157403781839.6404.2709540591932973827@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <8a8af789-cf6a-eea1-b21c-d4c90fd9923e@gmail.com> Date: Mon, 18 Nov 2019 14:29:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <157403781839.6404.2709540591932973827@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] I-D Action: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 01:29:22 -0000 Hi, There's a lot of good stuff in this draft. Just one point caught my eye: > 4.6. Deprioritising Internal Needs > > There are a number of needs that are very visible to us as > specification authors, but should explicitly not be prioritised over > the needs of end users. > > These include: convenience for document editors, IETF process > matters, and "architectural purity". I suggest making the last point: "architectural purity" for its own sake. There are certainly many cases where the argument *for* architectural purity is the principle of least astonishment, which directly benefits the user experience. Another point that occurs to me is whether the draft should say something about user interface issues. Of course that topic is out of IETF scope, but the protocol model may affect the UI in ways that have great impact on the user. Regards Brian Carpenter On 18-Nov-19 13:43, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Architecture Board IETF of the IETF. > > Title : The Internet is for End Users > Author : Mark Nottingham > Filename : draft-iab-for-the-users-01.txt > Pages : 11 > Date : 2019-11-17 > > Abstract: > This document explains why the IAB believes the IETF should consider > end users as its highest priority concern, and how that can be done. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-iab-for-the-users/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-iab-for-the-users-01 > https://datatracker.ietf.org/doc/html/draft-iab-for-the-users-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-iab-for-the-users-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Sun Nov 17 17:31:16 2019 Return-Path: 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 028E31200FB for ; Sun, 17 Nov 2019 17:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=H0kFlG20; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hNqS5o82 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 fBJ8WkAHLa6Q for ; Sun, 17 Nov 2019 17:31:09 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7AA12002E for ; Sun, 17 Nov 2019 17:31:09 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 978ED2201F; Sun, 17 Nov 2019 20:31:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 17 Nov 2019 20:31:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=3 BcATmVAzdMY3mxYhUvVYZ/3nI4UuWb2mjzbFy/AlWU=; b=H0kFlG201MVlbqR1V RCCTd1QsnT0LBYk6rJIhIsfhjjjMrn4uX4ejhIHPn61wHY0WhX6fAlR0oa4nEgCq Z6AqgaUi7g0iL/+x23aT9MkbvHQ63l883Q5CS9XOXbZntdQs53Qr5aGuBoLGEHu2 YYFrlVWT4Msj5nHG0L1Cx5lOIoeBoeQkpXBBDOIOjzUnELqhSQRQ1uZ4YRoW+sHr 9D9dXNDZ07tVkg7QlHVckKwLagoMOmnjWYtJxfqs8QXRJlsfBTHMjB2gh4nl2Zfs zrjB2IfN7GNV66T4C4+gQJaKW5tfDltWGeAMGqtSdJyjf73ax+6IulLBAV09WWnU Zuq6g== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=3BcATmVAzdMY3mxYhUvVYZ/3nI4UuWb2mjzbFy/Al WU=; b=hNqS5o82hUkpJnoS0hY8KZh91QRspRwQ/ZbIOgx2r0eInchzrn+apXphQ 2/BrqOWYlrhno9h64xM0zDH/PqapVGdBJxcpEJwKyR/z6GVPwCUeVdIP0Ku0xJXk pZ+2cuJS7D8uuaXODlW2iv3uPk/Vt7UrFd65yWMgwxW0C4761xoh8IFW78HYzoNk pSKYLn2q9r/sVg+gB4+sNdVsqvqqntKPRmcr1Ny+kAaxLjxbKz4lPxnWkanW3dWb iuUsJr3mL13WhJIr9xKZxH5KErNhage2HHpqy6nOpcmVouJ39xKJfI88lafZ7+GA lvY8Q9Z0HtnwVdtSAb8nwK8OtjqLw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeggedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucfkphepfedurddufeefrdduhedtrddu geefnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from dhcp-968f.meeting.ietf.org (dhcp-968f.meeting.ietf.org [31.133.150.143]) by mail.messagingengine.com (Postfix) with ESMTPA id 421248005A; Sun, 17 Nov 2019 20:31:02 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Mark Nottingham In-Reply-To: <8a8af789-cf6a-eea1-b21c-d4c90fd9923e@gmail.com> Date: Mon, 18 Nov 2019 09:30:57 +0800 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <545A2146-41EA-4D80-8E8E-4AC8E93D426E@mnot.net> References: <157403781839.6404.2709540591932973827@ietfa.amsl.com> <8a8af789-cf6a-eea1-b21c-d4c90fd9923e@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [arch-d] I-D Action: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 01:31:14 -0000 > On 18 Nov 2019, at 9:29 am, Brian E Carpenter = wrote: >=20 > Hi, >=20 > There's a lot of good stuff in this draft. Just one point caught my = eye: >=20 >> 4.6. Deprioritising Internal Needs >>=20 >> There are a number of needs that are very visible to us as >> specification authors, but should explicitly not be prioritised = over >> the needs of end users. >>=20 >> These include: convenience for document editors, IETF process >> matters, and "architectural purity". >=20 > I suggest making the last point: "architectural purity" for its own = sake. > There are certainly many cases where the argument *for* architectural > purity is the principle of least astonishment, which directly benefits > the user experience. I like that - thanks. > Another point that occurs to me is whether the draft should say = something > about user interface issues. Of course that topic is out of IETF = scope, > but the protocol model may affect the UI in ways that have great > impact on the user. I think that's a *great* area for discussion. >=20 > Regards > Brian Carpenter >=20 > On 18-Nov-19 13:43, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Internet Architecture Board IETF of = the IETF. >>=20 >> Title : The Internet is for End Users >> Author : Mark Nottingham >> Filename : draft-iab-for-the-users-01.txt >> Pages : 11 >> Date : 2019-11-17 >>=20 >> Abstract: >> This document explains why the IAB believes the IETF should = consider >> end users as its highest priority concern, and how that can be = done. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-iab-for-the-users/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-iab-for-the-users-01 >> https://datatracker.ietf.org/doc/html/draft-iab-for-the-users-01 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-for-the-users-01 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- Mark Nottingham https://www.mnot.net/ From nobody Sun Nov 17 21:58:13 2019 Return-Path: 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 5658A12088C for ; Sun, 17 Nov 2019 21:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 nwC4q1CeCQdY for ; Sun, 17 Nov 2019 21:58:08 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9377F12086C for ; Sun, 17 Nov 2019 21:58:08 -0800 (PST) Received: from smtp-3-0000.mail.infomaniak.ch (smtp-3-0000.mail.infomaniak.ch [10.4.36.107]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xAI5vne0094561 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Nov 2019 06:57:49 +0100 Received: from [IPv6:2001:67c:370:128:bc5e:e297:d32d:b91c] (unknown [IPV6:2001:67c:370:128:bc5e:e297:d32d:b91c]) by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 9A5AB100F703B; Mon, 18 Nov 2019 06:57:44 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Brian Trammell (IETF)" In-Reply-To: <6.2.5.6.2.20191117022756.07532f60@elandnews.com> Date: Mon, 18 Nov 2019 13:57:43 +0800 Cc: Andrew Campling , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20191117022756.07532f60@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 05:58:11 -0000 > On 17 Nov 2019, at 18:48, S Moonesamy wrote: >=20 > Hello, > At 10:53 PM 12-11-2019, Andrew Campling wrote: >> In the DNS section, it is disheartening to read the IAB stating that = "[a DNS resolver] returning the wrong (or no) address breaks the trust = that users have in this infrastructure", after having spent months on = the ADD list and elsewhere to explain that there are indeed lots of use = cases in which users expect, or even actively request, that their = resolver applies filters to the responses. In some cases it is actually = the opposite - if I acquire a DNS-based service to prevent any = accidental connection to malware-infected websites and then I get = malware, that's when I lose trust in my DNS resolver; same for parental = controls. >=20 > The position, in the past, was that it was important to preserve the = chain of trust instead of allowing someone along the path to change the = information published in DNS. There are use cases where the changes are = done for valid reasons, e.g. the user does not wish to download malware. = What are the unintended consequences of supporting such cases? The unintended consequences don't come from "supporting the use case" = per se, they come from the technical details of the approach used to do = so. For example: For your malware example, "change DNS records by intercepting queries = between the client and the recursive resolver and inject NXDOMAIN for = malware domains" is one way to implement such a thing. The unintended = consequences of this are "you can't deploy DNSSEC", "anyone on the same = path can do the same interception, maybe even to add malware", and so = on. Another way to support the same use case would be to add endpoint = defenses to the browser for web-based malware: in this case the browser = checks URLs against a blocklist. The tradeoff here is that you need to = touch every browser, and a possible unintended consequence here is that = the infrastructure to distribute the blocklists is a potential further = centralization of the architecture. Cheers, Brian > Regards, > S, Moonesamy >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Thu Nov 21 02:10:00 2019 Return-Path: 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 81241120980 for ; Thu, 21 Nov 2019 02:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 f_i1DaZV2XMe for ; Thu, 21 Nov 2019 02:09:56 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 913751208B0 for ; Thu, 21 Nov 2019 02:09:56 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id az9so1334736plb.11 for ; Thu, 21 Nov 2019 02:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tu/yutC8f4rBBNLuvBKq4vxcyu/jShJ174DvzrD3vR8=; b=ThLIsadOcW0ENCjXTWIegMz/KsiR75xC303wWGCUlZ0Cvw6WRQtNocY5MEizVmnbfd kHZ23ZYEwl/q+cKuCoj7qQIp6iOmRKn2QqvKRQYb/SnYDzm8R2HKccPXbCcVhXJ16tAS 0p20k8DvlE9qLqJDsLwKWINtET6Q4mgwg8g++q+ogtRQTMf4BjK6r8xNWnO5kgHfU7kz UwGaPhW71RR//BqTVlYjZNnt8rZ/wJ7aLeFlTRsMVnBZ4CNkf4AYHmuY1kkgi11tHn3F YFag+yw4glXI4D5PVXrzAvf3GO3rLiYBGlr/jwyMIbVHwT8epP9cUUg7eCcRD4zlbGhU f+cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tu/yutC8f4rBBNLuvBKq4vxcyu/jShJ174DvzrD3vR8=; b=hggAHYycadhFqCkXNlvK8dEIaLQAgZWJj+VVxGSxbSyzTQwr3rDm0ACvvECcVA2EQ8 XXr14/n1/pK5t9MXCJa1nwWlc6oaZidZkkBkuWeY1YXt/CNTUp5pFS1erEhcXINqR18E xiu+fX/1jArc7MvUrT/FpgXErWPwxx9h1vcHMWsfkMRpUkY9zwM/fdmi/Xj7V/gdob2F R6FlaGuWYVsv9TuzpeEB7us/So0Z9gMgjRUjiCd9OHRh8Q4WDC8CkZ1K6s9wm6460aGH tt43UqzGksa+/oDZ74idtn2HXfy8uyjzsVmpiQ/GBdgaML8vdG/UrzuKTxfqF44Bbgtq A7IA== X-Gm-Message-State: APjAAAV9ian1fFy3g31W2WnpwndDzA/ZvXAiMNZNtccZ2gmpGqSzKsXi x1zqEHbq8tSNbaNNqo7b+GLywwgv X-Google-Smtp-Source: APXvYqxm+Hq+31Odvi1E1gXyEEwjw2J62jc7d+ul3naZuRr71bPVSB0dYE2auJ+TWbvr8VL5oNOUkQ== X-Received: by 2002:a17:902:76c8:: with SMTP id j8mr7961546plt.122.1574330995618; Thu, 21 Nov 2019 02:09:55 -0800 (PST) Received: from [31.133.129.140] (dhcp-818c.meeting.ietf.org. [31.133.129.140]) by smtp.gmail.com with ESMTPSA id z11sm2933668pfg.117.2019.11.21.02.09.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 02:09:54 -0800 (PST) To: Mark Nottingham Cc: architecture-discuss@ietf.org References: <157403781839.6404.2709540591932973827@ietfa.amsl.com> <8a8af789-cf6a-eea1-b21c-d4c90fd9923e@gmail.com> <545A2146-41EA-4D80-8E8E-4AC8E93D426E@mnot.net> From: Brian E Carpenter Message-ID: <00130ecc-486b-4133-8ef3-a2e99e0e756e@gmail.com> Date: Thu, 21 Nov 2019 23:09:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <545A2146-41EA-4D80-8E8E-4AC8E93D426E@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] I-D Action: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 10:09:59 -0000 On 18-Nov-19 14:30, Mark Nottingham wrote: > > >> On 18 Nov 2019, at 9:29 am, Brian E Carpenter wrote: >> >> Hi, >> >> There's a lot of good stuff in this draft. Just one point caught my eye: >> >>> 4.6. Deprioritising Internal Needs >>> >>> There are a number of needs that are very visible to us as >>> specification authors, but should explicitly not be prioritised over >>> the needs of end users. >>> >>> These include: convenience for document editors, IETF process >>> matters, and "architectural purity". >> >> I suggest making the last point: "architectural purity" for its own sake. >> There are certainly many cases where the argument *for* architectural >> purity is the principle of least astonishment, which directly benefits >> the user experience. > > I like that - thanks. > >> Another point that occurs to me is whether the draft should say something >> about user interface issues. Of course that topic is out of IETF scope, >> but the protocol model may affect the UI in ways that have great >> impact on the user. > > I think that's a *great* area for discussion. I was thinking of POP3 and IMAP as a case in point. They differ semantically in a way that is definitely not obvious or intuitive for the normal user. In one case, fetching a message to device A either deletes the message from the server, or marks it as already downloaded, so device B can never fetch it. In the other case, fetching a message to device A leaves it available for device B, but of course deleting it from device A also makes it unavailable for device B. Mixing usage of POP3 and IMAP for the same user+server can be even more confusing. Now, I know that IMAP is considered superior and more modern etc., but this is still a real confusion in the real world. Any other examples? Brian > > >> >> Regards >> Brian Carpenter >> >> On 18-Nov-19 13:43, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Internet Architecture Board IETF of the IETF. >>> >>> Title : The Internet is for End Users >>> Author : Mark Nottingham >>> Filename : draft-iab-for-the-users-01.txt >>> Pages : 11 >>> Date : 2019-11-17 >>> >>> Abstract: >>> This document explains why the IAB believes the IETF should consider >>> end users as its highest priority concern, and how that can be done. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-iab-for-the-users/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-iab-for-the-users-01 >>> https://datatracker.ietf.org/doc/html/draft-iab-for-the-users-01 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-iab-for-the-users-01 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- > Mark Nottingham https://www.mnot.net/ > > From nobody Thu Nov 21 07:31:24 2019 Return-Path: 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 96A7F1200F8 for ; Thu, 21 Nov 2019 07:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 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_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 FWMEFjL0ces8 for ; Thu, 21 Nov 2019 07:31:22 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E86E120096 for ; Thu, 21 Nov 2019 07:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rDEDIZPHUnUmsT6ecEGra9k2duw1i2cmwPEbU7+eLXU=; b=EfxPj6qGACNv931CPdfwcFbCi NinqRxZ6aD98GRWQzPrGp4x7SeVuJhBcZR5ujmpRfepAO76np28uDESyfNp7bNn0lbyo1s8oLMaxA ZzopH1kxHxs4TyrOfYPixGJBBRswcyhe5pmj5Yo6rdO0mGpzc3moSucPl4/gXLin8TwDckthagUdh X9d+j35UVtglJLYWEEzvdw1Ug6I5Vu9k3X0SFQGekFXQ7+snoAi0tYtMtN+Q0fZUuRRAY5RlDdeNU sezW26EyAie25S271s5NE9Sr8brD8NJ6zd2eOxwPthXQYORYMg6iLsuS7l0jjhM1ZzEp5D7knG1Sy YvPnS/zTQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63277 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iXoQO-003od3-N6; Thu, 21 Nov 2019 10:31:21 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_9CE40F3E-9BE5-435F-A4EC-4FD57B3EDDB2" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <00130ecc-486b-4133-8ef3-a2e99e0e756e@gmail.com> Date: Thu, 21 Nov 2019 07:31:15 -0800 Cc: Mark Nottingham , architecture-discuss@ietf.org Message-Id: <7D8D3808-2780-4546-8713-C2F524F47973@strayalpha.com> References: <157403781839.6404.2709540591932973827@ietfa.amsl.com> <8a8af789-cf6a-eea1-b21c-d4c90fd9923e@gmail.com> <545A2146-41EA-4D80-8E8E-4AC8E93D426E@mnot.net> <00130ecc-486b-4133-8ef3-a2e99e0e756e@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] I-D Action: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 15:31:24 -0000 --Apple-Mail=_9CE40F3E-9BE5-435F-A4EC-4FD57B3EDDB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Nov 2019, at 9:29 am, Brian E Carpenter = > = wrote: >=20 > Hi, >=20 > There's a lot of good stuff in this draft. Just one point caught my = eye: >=20 >> 4.6. Deprioritising Internal Needs >>=20 >> There are a number of needs that are very visible to us as >> specification authors, but should explicitly not be prioritised over >> the needs of end users. >>=20 >> These include: convenience for document editors, IETF process >> matters, and "architectural purity". >=20 > I suggest making the last point: "architectural purity" for its own = sake. > There are certainly many cases where the argument *for* architectural > purity is the principle of least astonishment, which directly benefits > the user experience. Current =E2=80=9Cuser needs=E2=80=9D aren=E2=80=99t always benefit the = system as a whole nor the needs of users in the future. "Architectural purity=E2=80=9D can be (and should be) representing the = latter and need not be considered =E2=80=9Cinternal=E2=80=9D. > Another point that occurs to me is whether the draft should say = something > about user interface issues. Of course that topic is out of IETF = scope, I=E2=80=99m trying to understand how that makes any sense for a group = that is writing about protocols and communication architectures. I=E2=80=99m assuming it comes from the =E2=80=9Cthe API is out of = scope=E2=80=9D error that was made many years ago - which confuses the = API *instance* with the upper layer interface architecture. RFC793 gives = a great example of the latter (the abstract =E2=80=9Cuser commands=E2=80=99= ). In subsequent work, the absence of that interface as IETF work was a = mistake. I hope this doc isn=E2=80=99t trying to propagate that error. Joe= --Apple-Mail=_9CE40F3E-9BE5-435F-A4EC-4FD57B3EDDB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 18 = Nov 2019, at 9:29 am, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Hi,

There's a lot of good stuff = in this draft. Just one point caught my eye:

4.6. =  Deprioritising Internal Needs

 There are a number of needs that are very visible to us = as
 specification authors, but should explicitly not = be prioritised over
 the needs of end users.

 These include: convenience for document = editors, IETF process
 matters, and "architectural = purity".

I suggest making the = last point: "architectural purity" for its own sake.
There = are certainly many cases where the argument *for* architectural
purity is the principle of least astonishment, which directly = benefits
the user experience.

Current = =E2=80=9Cuser needs=E2=80=9D aren=E2=80=99t always benefit the system as = a whole nor the needs of users in the future.

"Architectural purity=E2=80=9D can be (and should be) = representing the latter and need not be considered = =E2=80=9Cinternal=E2=80=9D.

Another point that = occurs to me is whether the draft should say something
about= user interface issues. Of course that topic is out of IETF scope,

I=E2=80=99m trying to = understand how that makes any sense for a group that is writing about = protocols and communication architectures.

I=E2=80=99m assuming it comes from the = =E2=80=9Cthe API is out of scope=E2=80=9D error that was made many years = ago - which confuses the API *instance* with the upper layer interface = architecture. RFC793 gives a great example of the latter (the abstract = =E2=80=9Cuser commands=E2=80=99). In subsequent work, the absence of = that interface as IETF work was a mistake.

I hope this doc isn=E2=80=99t trying to = propagate that error.

Joe
= --Apple-Mail=_9CE40F3E-9BE5-435F-A4EC-4FD57B3EDDB2-- From nobody Thu Nov 21 16:02:02 2019 Return-Path: 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 3029D120826 for ; Thu, 21 Nov 2019 16:02:00 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 2i0Wbwyo78pE for ; Thu, 21 Nov 2019 16:01:57 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 B6344120091 for ; Thu, 21 Nov 2019 16:01:55 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id r4so2558968pfl.7 for ; Thu, 21 Nov 2019 16:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/J419yJyfD2881M8vLGtG5184Unah6PdqYTaU8GFOOg=; b=Ur1aZJNqvIDNdW0/S4pbJTCmERffufRL89vVLMmPNQtLhI1RB8ktlPctaSo+tcNiOG ieqKM043jrpVTfcTLjZY993wMEojWDHxiaRVs28rWuolhkSTrTqiH+sL6m9p+J53h0Ah XMAqATxzFYWqlfDxIU37KUYOvzsGXD+Mdxp+5kcn6pDJJruHs4YCYnOD050DA9BZOh6E K1oCcR1EOsb+lHvOYP2AF77NTFkwiuh2VZHxTwmTjNVH+6HM3UMxfrbKNwSxsfnvkxOt kpagb6bfqpOFJ8gn4LoZF2Verqc9ZNOs3CrkvR7WqKnwgisNYEEsHl/BoV2WD1gPOv8b 0Hkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/J419yJyfD2881M8vLGtG5184Unah6PdqYTaU8GFOOg=; b=H5KZrY69CYUfALy5ir7hO3xbEDt0dqe2lvIL973QoAFK8Zitz0l/Z0p69M1h5QdwA4 g1fJOJkM2HPqVaIHtcYx/Q3ZbI6+s1VFKwUt+62cMC95JvUeLauMUNFLARe+AJtao8lZ vZcnxjJkAOixZj8Nvu4sgf7gm//uOpSx/FqHCvMFsJsKjZyRFDKqTiMNGeTZg0AuL0UQ bSDRIgMZTEsnEHTLgpbG/5qMDBTyX/IJbv7SdA9TDPkMH9VF6Ojtw1Er8q4vMobo5uRO DELb7z0DC8Tl1sHaRjpVOCey8M28AL9CUIhrIm/GRpzepGsfMov0AdvwuC08B6vWqlKa xRJw== X-Gm-Message-State: APjAAAXxjQiKBvcbhP4Ml5d0w88KDVldj38OEfcbQphS3g/x0i0Fw4WJ YrFB/qZTEK6JruyVi6oh3ojrjdOj X-Google-Smtp-Source: APXvYqxhK3kqxhtyzSLTNoZsXWQjE0oGqg4kuI+pRrUB/VmTfn5eiD2UCVri5WF+rTSrmJMc9z2gcg== X-Received: by 2002:a63:ec50:: with SMTP id r16mr12593844pgj.284.1574380914685; Thu, 21 Nov 2019 16:01:54 -0800 (PST) Received: from [31.133.151.10] (dhcp-970a.meeting.ietf.org. [31.133.151.10]) by smtp.gmail.com with ESMTPSA id x9sm1698514pgt.66.2019.11.21.16.01.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 16:01:53 -0800 (PST) To: Joe Touch Cc: Mark Nottingham , architecture-discuss@ietf.org References: <157403781839.6404.2709540591932973827@ietfa.amsl.com> <8a8af789-cf6a-eea1-b21c-d4c90fd9923e@gmail.com> <545A2146-41EA-4D80-8E8E-4AC8E93D426E@mnot.net> <00130ecc-486b-4133-8ef3-a2e99e0e756e@gmail.com> <7D8D3808-2780-4546-8713-C2F524F47973@strayalpha.com> From: Brian E Carpenter Message-ID: Date: Fri, 22 Nov 2019 13:01:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <7D8D3808-2780-4546-8713-C2F524F47973@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] I-D Action: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 00:02:00 -0000 On 22-Nov-19 04:31, Joe Touch wrote: >=20 >=20 >> On 18 Nov 2019, at 9:29 am, Brian E Carpenter > wrote: >> >> Hi, >> >> There's a lot of good stuff in this draft. Just one point caught my ey= e: >> >>> 4.6. =C2=A0Deprioritising Internal Needs >>> >>> =C2=A0There are a number of needs that are very visible to us as >>> =C2=A0specification authors, but should explicitly not be prioritised= over >>> =C2=A0the needs of end users. >>> >>> =C2=A0These include: convenience for document editors, IETF process >>> =C2=A0matters, and "architectural purity". >> >> I suggest making the last point: "architectural purity" for its own sa= ke. >> There are certainly many cases where the argument *for* architectural >> purity is the principle of least astonishment, which directly benefits= >> the user experience. >=20 > Current =E2=80=9Cuser needs=E2=80=9D aren=E2=80=99t always benefit the = system as a whole nor the needs of users in the future. >=20 > "Architectural purity=E2=80=9D can be (and should be) representing the = latter and need not be considered =E2=80=9Cinternal=E2=80=9D. I agree. The point is quite subtle, but I thought that "for its own sake"= covered it.=20 >=20 >> Another point that occurs to me is whether the draft should say someth= ing >> about user interface issues. Of course that topic is out of IETF scope= , >=20 > I=E2=80=99m trying to understand how that makes any sense for a group t= hat is writing about protocols and communication architectures. We don't design UIs. But what we do constrains and biases the choices tha= t the UI designer makes.=20 =20 > I=E2=80=99m assuming it comes from the =E2=80=9Cthe API is out of scope= =E2=80=9D error that was made many years ago - which confuses the API *in= stance* with the upper layer interface architecture. RFC793 gives a great= example of the latter (the abstract =E2=80=9Cuser commands=E2=80=99). In= subsequent work, the absence of that interface as IETF work was a mistak= e. I think the argument is indeed quite similar. The protocol design constra= ins and biases the API design. And I don't think "out of scope" is really= such a bright line. The POSIX API follows RFC3493 quite closely, as does= WinSock. Sadly POSIX doesn't support RFC3542, which is a fail. Please look at draft-ietf-anima-grasp-api-04 for a current example. Brian >=20 > I hope this doc isn=E2=80=99t trying to propagate that error. >=20 > Joe