From nobody Thu Aug 5 02:01:10 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575A03A08F6 for ; Thu, 5 Aug 2021 02:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 YuF4Ens9kxPP for ; Thu, 5 Aug 2021 02:01:04 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 57DDD3A08F8 for ; Thu, 5 Aug 2021 02:01:03 -0700 (PDT) Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:e16c:7ba0:f69c:5b6]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17590xrY201345 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 5 Aug 2021 11:00:59 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1628154059; bh=WGYXGBFJVEmbyCLDut4sCXCRnlyLuwOX05F0lXwCzQw=; h=To:From:Subject:Date:From; b=ZU35lApE0koG1E57g/T1iIVHHF4ivD92kalKOpmga9ZyZpgBkRogRVQt5lzxk+Uvo qiIlaxscnIDOlbtRwVvR69HbeCtquvb2EtJ4qPglvMM8I+bCAAvCuz6PBWZxLN2fJf fypx9a51Q7eU9XdQLixPWNDV5aOPV9B0qRK9pcSM= To: edm@iab.org From: Eliot Lear Message-ID: Date: Thu, 5 Aug 2021 11:00:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1mRXySGFtijMFQ4vOMmFo2v5reAOdkPDM" Archived-At: Subject: [Edm] On Section 3.2. At what level should versioning occur? X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 09:01:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1mRXySGFtijMFQ4vOMmFo2v5reAOdkPDM Content-Type: multipart/mixed; boundary="3bkZmZOLpAnVhH5r6VaxXVlK2XV2QDsMM"; protected-headers="v1" From: Eliot Lear To: edm@iab.org Message-ID: Subject: On Section 3.2. At what level should versioning occur? --3bkZmZOLpAnVhH5r6VaxXVlK2XV2QDsMM Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Martin and friends, Thanks for this draft.=C2=A0 I also appreciate the lastest PR that reduce= s=20 out the middlebox discussion.=C2=A0 We might want to have a more targeted= =20 revisiting of that section, but by pulling that stuff out you have=20 focused down onto the subject of the draft, which is the risk of disuse. I really like your section 3.2, but it does presume that the lower=20 layers are able to accommodate exposing of version information.=C2=A0 Bel= ow=20 the IP layer, when IEEE 802 is used, we are in very good shape; but does = everything below that hourglass neck have that attribute, and do we want = to demand that in order to implement v4/v6?=C2=A0 To that end, my suggest= ion=20 is that you simply note this as an issue when we interact with other=20 technologies. Back in our little corner of the world, this has some broad IANA policy=20 implications. Interestingly, when we do port allocations, we generally say that=20 applicants SHOULD include versioning information in their protocols=20 because the IANA will not allocate new port numbers for existing=20 services.=C2=A0 But is that the right approach, and what is meant by an=20 existing service?=C2=A0 If the service is accomplishing the same thing, b= ut=20 the encoding of the underlying protocol has shifted, should we really be = so strict?=C2=A0 While some quickly envision the world moving to QUIC, le= t's=20 agree that there are some applications that won't find QUIC to be The=20 Answer, and that port numbers may remain a somewhat scarce resource.=C2=A0= =20 And so maybe a version field ISN'T such a big deal, but requires=20 additional protections for future use for those who are keeping score,=20 yes I'm arguing both sides of the issue].=C2=A0 One example might be that= =20 two-party protocols never FAIL when they see a greased version but=20 simply come back with "version not supported" or "I see grease" or some=20 such. Eliot --3bkZmZOLpAnVhH5r6VaxXVlK2XV2QDsMM-- --1mRXySGFtijMFQ4vOMmFo2v5reAOdkPDM Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmELqMkFAwAAAAAACgkQh7ZrRtnSejNe gggA2Npo0Zr1iWoJ1fdSTy0Xxlyc43GlmdO3UYxFq/orupNsSRIpPE6il1E3hZGhhRpgk5RBc7Oe 2nlHFFfhIlBIcY0jPMqBNFDN4MykrQ9hBYXXzH82QPnDD56MaAvBbRL/5YNqUm8DEPDaQMAX2O2+ XByJmc5BuuGepPq88pggm0lpCZtKdVMtPPEOIGAGVwAiuuViyxADo5uaBxLP0TwRgdZ7GPGUIHrW M+3IrngiUkrrz/VnF1z3/PsbGq+Yb86XgEI/N7ks4tryd1/IAKO4gORtsl8ng0ehUMvmw0NJanKt h3fZyYBISoR48pfUjumRtZzDRYOXFQVjI1lvVfZWPQ== =SDX7 -----END PGP SIGNATURE----- --1mRXySGFtijMFQ4vOMmFo2v5reAOdkPDM-- From nobody Thu Aug 5 02:30:24 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612023A0A9D for ; Thu, 5 Aug 2021 02:30:23 -0700 (PDT) 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 9XNtXqXJFsAA for ; Thu, 5 Aug 2021 02:30:20 -0700 (PDT) Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 D22743A0A9A for ; Thu, 5 Aug 2021 02:30:19 -0700 (PDT) Received: from sushi.unix-ag.uni-kl.de (sushi.unix-ag.uni-kl.de [IPv6:2001:638:208:ef34:0:ff:fe00:65]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 1759UFPh081841 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 5 Aug 2021 11:30:15 +0200 Received: from sushi.unix-ag.uni-kl.de (ip6-localhost [IPv6:::1]) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 1759UFGK018689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Aug 2021 11:30:15 +0200 Received: (from auerswal@localhost) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Submit) id 1759UFeU018688 for edm@iab.org; Thu, 5 Aug 2021 11:30:15 +0200 Date: Thu, 5 Aug 2021 11:30:15 +0200 From: Erik Auerswald To: edm@iab.org Message-ID: <20210805093015.GA17433@unix-ag.uni-kl.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Author: Erik Auerswald User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Edm] On Section 3.2. At what level should versioning occur? X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 09:30:24 -0000 Hello Eliot, On Thu, Aug 05, 2021 at 11:00:57AM +0200, Eliot Lear wrote: > [...] > I really like your section 3.2, but it does presume that the lower > layers are able to accommodate exposing of version information.  > Below the IP layer, when IEEE 802 is used, we are in very good > shape; but does everything below that hourglass neck have that > attribute, and do we want to demand that in order to implement > v4/v6?  To that end, my suggestion is that you simply note this as > an issue when we interact with other technologies. I do not think this I-D section argues against using version information for a protocol, but rather that increasing the version number is not sufficient for implementing and deploying a new version of a protocol at a later time. > [...] > Interestingly, when we do port allocations, we generally say that > applicants SHOULD include versioning information in their protocols I think that is good advice, since IMHO versioning information is a necessary prerequisite for later on introducing another version. > [...] Thanks, Erik From nobody Thu Aug 5 18:34:06 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7003A3A1623 for ; Thu, 5 Aug 2021 18:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=LVvY5Yj2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lOhNKYme 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 3SAb6BQTSwIC for ; Thu, 5 Aug 2021 18:33:49 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537A33A1626 for ; Thu, 5 Aug 2021 18:33:48 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 18C615C0163 for ; Thu, 5 Aug 2021 21:33:48 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Thu, 05 Aug 2021 21:33:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=sXJAC yXXl5JEs0Ao27s1q31KayxCWwewzDyj7DUWWH8=; b=LVvY5Yj2U7J4MdtpdRS24 HtCtTQi48C90xt+GvUYVNTvRyNHPJQ7cVF6NwZ+yI6K/Pk16ZiZvm/ArJTGURtrV Fve5NEiOGs5EVhlbOsf3j0CAHmSgyddI6OuNruHu82oFAh6eRnaYyLFHXhKfDLAU UktJtQJQigePdGv+O2w302aFKksOrTu6u+bpKeuwe6/zCzmxJ5YQSc8N2e1zPt97 PBuGQtGjrl/uTfow0kSOzjvFbXRw3bD8mlRy9cJEZsL9WGa9Mkv040JXl6xDlbdq 7ufgHLImRnFt1zGa1zqFxNXqoQMbCHvycOaqLN48UdHoBNq3n0LmvbjOQnPZ2eJQ g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=sXJACyXXl5JEs0Ao27s1q31KayxCWwewzDyj7DUWW H8=; b=lOhNKYmeNhiAFVlGmSjEXP91fbZwa+T8U4pxktVElF0EctOIKBQYGDoG3 1DdcHDnlu+T8YXr8S0tS8547MQiqWpdGbGy6yedWD3OjIOZMGwxEj7ZvPj0jZgeG w3Q1+OcpcAoTsTJc2Oz7X1f5MehtPqjIBiK0Gr0+ddaBlD2oG+TA3yQNAwJI/Vpw aALSAuOHjxHxH6aT5PqlKP6RdPws/+B0kwtIxWY5LBGhAhuijnWFkARscy0oh2G1 PZ+jhaDahr0th/T2uVT0XXes3Xxy1q09j++ki2z7ulhP0uuubyCUvOfy0a7+xC2E FAVkSoJ8OwnYPPPKeiljGtUbdWRqw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjedtgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgjeeuudeiffeltdegle ehjedvtedtjeduudehgfegfefgkefgueeiteegffdttdenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 888F43C0449; Thu, 5 Aug 2021 21:33:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-552-g2afffd2709-fm-20210805.001-g2afffd27 Mime-Version: 1.0 Message-Id: <63bd41ea-9088-4480-b4bd-107cda212aaa@www.fastmail.com> In-Reply-To: References: Date: Fri, 06 Aug 2021 11:33:18 +1000 From: "Martin Thomson" To: edm@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Edm] On Section 3.2. At what level should versioning occur? X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 01:34:05 -0000 On Thu, Aug 5, 2021, at 19:00, Eliot Lear wrote: > I really like your section 3.2, but it does presume that the lower=20 > layers are able to accommodate exposing of version information.=C2=A0 = Below=20 > the IP layer, when IEEE 802 is used, we are in very good shape; but do= es=20 > everything below that hourglass neck have that attribute, and do we wa= nt=20 > to demand that in order to implement v4/v6?=C2=A0 To that end, my sugg= estion=20 > is that you simply note this as an issue when we interact with other=20= > technologies. More on this below, but I don't read Section 3.2 as declaring a mandate,= but just as making a suggestion. =20 > Interestingly, when we do port allocations, we generally say that=20 > applicants SHOULD include versioning information in their protocols=20= > because the IANA will not allocate new port numbers for existing=20 > services.=C2=A0 But is that the right approach, and what is meant by a= n=20 > existing service?=C2=A0=20 The idea that port =3D=3D service is largely a dead idea, so I don't see= port numbers are relevant to this discussion. (I think that we should = probably not accept more allocations, without exceptional justification.= We have SRV and SVCB and other discovery/configuration things in ample= measure.) Your advice is very much valid there. You are saying that TCP/UDP port = numbers are not good for versioning. That's right because they aren't. = That's not what they were designed for and that is not how they are use= d in practice. > If the service is accomplishing the same thing, but=20 > the encoding of the underlying protocol has shifted, should we really = be=20 > so strict?=C2=A0 While some quickly envision the world moving to QUIC,= let's=20 > agree that there are some applications that won't find QUIC to be The=20= > Answer, and that port numbers may remain a somewhat scarce resource.=C2= =A0=20 > And so maybe a version field ISN'T such a big deal, but requires=20 > additional protections for future use for those who are keeping score,= =20 > yes I'm arguing both sides of the issue].=C2=A0=20 This is probably a different question now, and outside the scope of this= work. (I'll note that you said "strict" here, but I don't see anything= that mandates a particular design direction in the draft. It seems pret= ty clearly optional advice to me.) FWIW, as you mention ports, my position on *transport-level* versioning = goes something like: 1. port numbers are not for versioning 2. consequently new transport protocols need versioning (this includes t= ransport-adjacent protocols like TLS) or some way to allow for their eve= ntual replacement; this is because there is no functioning facility in t= he IP layer (or UDP or TCP for that matter) 3. new transport protocols are expensive to build and should be rare (th= e difficulty of building a versioning scheme is part of that) 4. new uses of transport protocols should be secured and should use TLS = or QUIC 5. new uses of transport protocols that use TLS or QUIC can use ALPN to = manage their own versioning and so do not need their own versioning desi= gn This document covers points 2 and 3 and talks generically about point 5,= which is all it can really do. > One example might be that=20 > two-party protocols never FAIL when they see a greased version but=20 > simply come back with "version not supported" or "I see grease" or som= e=20 > such. That is essentially how QUIC and TLS work (though "I see grease" =3D> "g= rease is just ignored"). From nobody Thu Aug 5 20:32:51 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A44C3A1A6D for ; Thu, 5 Aug 2021 20:32:49 -0700 (PDT) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 bsfphJWQnYTM for ; Thu, 5 Aug 2021 20:32:47 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3C93A1A6A for ; Thu, 5 Aug 2021 20:32:45 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5A0C754804C; Fri, 6 Aug 2021 05:32:38 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 522194E7C58; Fri, 6 Aug 2021 05:32:38 +0200 (CEST) Date: Fri, 6 Aug 2021 05:32:38 +0200 From: Toerless Eckert To: Martin Thomson Cc: edm@iab.org Message-ID: <20210806033238.GN57091@faui48e.informatik.uni-erlangen.de> References: <63bd41ea-9088-4480-b4bd-107cda212aaa@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63bd41ea-9088-4480-b4bd-107cda212aaa@www.fastmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Edm] On Section 3.2. At what level should versioning occur? X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 03:32:49 -0000 On Fri, Aug 06, 2021 at 11:33:18AM +1000, Martin Thomson wrote: > 4. new uses of transport protocols should be secured and should use TLS or QUIC There are lots of good reasons when you do not want to do transport header confidentiality. For example when you have a mission specific network deployment that needs hop-by-hop transport layer quality measurements (per stream latency, loss, jitter reordering etc..) as part of network to subscriber SLA. And your payload is secured anyhow (think ABR in access SP IPTV services). Yes, there are long term hw implementations for per-TCP-flow performance metrics measurements. And probably more now for use not in video as i am familiar with, but also in DCs. There are also a lot of good reasons not to think everything can or should run on top of TLS or QUIC. Think of real-time services whose resilience scheme is not based on ARQ and that have more accurate real time measurement requirements in collaboration between network and endpoints. Anything using RTP for example, or future enhancements variations of such transports. Also, no need to promote TLS and QUIC, they will surely get more adoption then where they are the best choice, because many of the workflows where they hurt are not well thought out during application development time, and then choosing TLS/QUIC will be be a foregone conclusion in the absence of more application developer expertise into the alternatives and other ecosystem reasons to go for the least common, most widely adopted denominator. And not even talking about the problem of building firewalls / IDS with end-to-end encryption i a trustworthy way. And that is just unicast. Cheers Toerless From nobody Sun Aug 8 00:50:55 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6953A2000 for ; Sun, 8 Aug 2021 00:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=gou9j/AW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=boKRBMEM 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 k9x0D6GoxxKG for ; Sun, 8 Aug 2021 00:50:48 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4E23A1FFF for ; Sun, 8 Aug 2021 00:50:47 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 07BEE5C00F5 for ; Sun, 8 Aug 2021 03:34:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 08 Aug 2021 03:34:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=dMGaL4jUKRA INA7TAILoYymn8MjigfVbHRWaC9n8xQI=; b=gou9j/AW003FkB9cqL74k/iU8fu Qk5wS/hTkSgdNO/1C8raOx/IKM9it5VTdXf0YzC5AAbwwKumIBsLVO5cM4dNvyrr G3mE9NQ3dBfUv0xc9cB6uf5iTFxaFpnQEgAnU3paoS4QsYhLNe2B1dM4by4+Ruhm zY3wKz68ihOXbhXgGcf36EbmnsIlzPxYFJRZJ2rorzXmIn98eBohpZ965Jl7LEjA YcyJZ1EPRUnwrvr2gsM5bGbe1iGwYvkyFsyW0WqUzJhY9vzjAgN9yax6HTzq7qFp VPFO77k7lfMhwb1OmaWT8F4kA05F7MehxYKmZ80BkVu3HATKMVjAwdWH4Xg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=dMGaL4jUKRAINA7TAILoYymn8MjigfVbHRWaC9n8xQI=; b=boKRBMEM 1b8ZvG8QiXfUr9Jydy5B9PFqIkMbj7vKCOkiqA/2iDEeso/FP/CGQktfg85VlnDE hqZDEvkAApR/VcV2g3ptiP4e7cmifS5n8CXyKsHtMscBLQ4DU6pWW++3X35mjnRt hEDN5lyHXtkbYKIMaCYYGZFpOpldDAkWhl85daS5xrmtkX0qwG/Hpx0ZH9yD1olp FTb9E3O8VjygcJceHw7Z0YhzAXHyuzIPsMHIgaytAmyG6pHq8xqJRMk9YopvMvLp 3F2unrEZt4yEq1ouAjznxvNcbl5f8g8+82Y5wn+b1DD3FTyVSiZXVo7EkOZeE2ga 74NgjZAfZ44IsQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjeeggddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 8 Aug 2021 03:34:11 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============8049632406387805588==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: edm@iab.org Message-Id: <20210808075048.1B4E23A1FFF@ietfa.amsl.com> Date: Sun, 8 Aug 2021 00:50:47 -0700 (PDT) Archived-At: Subject: [Edm] Weekly github digest (EDM Activity Summary) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2021 07:50:53 -0000 --===============8049632406387805588== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * intarchboard/edm (+1/-0/=F0=9F=92=AC3) 1 issues created: - Discuss greasing as an addition to an existing protocol, versus being p= art of it from the start (by tfpauly) https://github.com/intarchboard/program-edm/issues/11=20 2 issues received 3 new comments: - #11 Discuss greasing as an addition to an existing protocol, versus bei= ng part of it from the start (2 by tfpauly) https://github.com/intarchboard/program-edm/issues/11=20 - #4 How should we coordinate greasing experiments? (1 by tfpauly) https://github.com/intarchboard/program-edm/issues/4 [deployability] [e= volvability]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/intarchboard/edm --===============8049632406387805588== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (EDM Activity Summary)

Sunday August 08, 2021

Issues

intarchboard/edm (+1/-0/=F0=9F=92=AC3)

1 issues created:

2 issues received 3 new comments:

Repositories tracked by this digest:

--===============8049632406387805588==-- From nobody Wed Aug 25 11:44:48 2021 Return-Path: X-Original-To: edm@iab.org Delivered-To: edm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 896043A0774; Wed, 25 Aug 2021 11:43:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF Announcement List" Cc: architecture-discuss@ietf.org, edm@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: architecture-discuss@ietf.org, iab@iab.org Message-ID: <162991703946.25379.3009360954932586670@ietfa.amsl.com> Date: Wed, 25 Aug 2021 11:43:59 -0700 Archived-At: Subject: [Edm] Call for Comment: (Long-term Viability of Protocol Extension Mechanisms) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 18:44:00 -0000 This is an announcement of an IETF-wide Call for Comment on draft-iab-use-it-or-lose-it-02. The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection at: The Call for Comment will last until 2021-09-22. Please send comments to architecture-discuss@ietf.org and iab@iab.org. Abstract: The ability to change protocols depends on exercising the extension and version negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly. From nobody Wed Aug 25 12:01:05 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC353A0AA7 for ; Wed, 25 Aug 2021 12:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=joelhalpern.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 w9fvOJOU8VFe for ; Wed, 25 Aug 2021 12:00:45 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 0D5713A0AB8 for ; Wed, 25 Aug 2021 12:00:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4GvwKl5Qd1z1nwCn; Wed, 25 Aug 2021 12:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1629918043; bh=tI7Nhw8jkGeoIEPP/FR8uD5bAULZ0jeUdJUUc+/8zfk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NqjghSxzIk4guLYQW+VDIiHXkRyEcaGYohQd0rvzi7/W1GbIZeYg7VrvT6OhzvgCt +oyp0cO9JCsg41RadS+nRGDOHmPMD5PfZ40h2L6zAzY+ia1pDPmj97e9/4clxHVyDF iX9+G3APNBrl9chqTOCkYlXjDl4A7oabTZoufXi0= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4GvwKl1k67z1nvFG; Wed, 25 Aug 2021 12:00:43 -0700 (PDT) To: architecture-discuss@ietf.org Cc: edm@iab.org References: <162991703946.25379.3009360954932586670@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <078f0246-6e3f-1a49-38e7-cfdae1539c93@joelhalpern.com> Date: Wed, 25 Aug 2021 15:00:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <162991703946.25379.3009360954932586670@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Edm] [arch-d] Call for Comment: (Long-term Viability of Protocol Extension Mechanisms) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 19:01:00 -0000 I find the ending of the introcution: It is possible that these conclusions are less applicable to protocol deployments that have less scale and diversity, or operate under different constraints. to seriously understate the limitations of this work. The most important different cases I can see are the extremely widely deployed protocols at the Internet and Routing layers. These protocols share the problems that are identified. But the proposed approaches to improving the situation are likely to be problematic at best. I think a much stronger disclaimer is needed. Yours, Joel On 8/25/2021 2:43 PM, IAB Executive Administrative Manager wrote: > This is an announcement of an IETF-wide Call for Comment on > draft-iab-use-it-or-lose-it-02. > > The document is being considered for publication as an Informational RFC > within the IAB stream, and is available for inspection at: > > > The Call for Comment will last until 2021-09-22. Please send comments to > architecture-discuss@ietf.org and iab@iab.org. > > Abstract: > > The ability to change protocols depends on exercising the extension > and version negotiation mechanisms that support change. This > document explores how regular use of new protocol features can ensure > that it remains possible to deploy changes to a protocol. Examples > are given where lack of use caused changes to be more difficult or > costly. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Wed Aug 25 16:18:22 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D38B3A110F for ; Wed, 25 Aug 2021 16:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 dc_KvegU8YjW for ; Wed, 25 Aug 2021 16:18:02 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 B1F3A3A110C for ; Wed, 25 Aug 2021 16:18:02 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id ot2-20020a17090b3b4200b0019127f8ed87so4790281pjb.1 for ; Wed, 25 Aug 2021 16:18:02 -0700 (PDT) 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=sD4fXOLtecsdMQyHYK0G2fNeazc8p8b1A82kjs/Hnj4=; b=HMN2eKDCWj5nmbTMNLo59ZnNhy3+zNeAdCmxCDXolCgM07yPQZDrtsoEYp7MyT05+V b2eI1g3sPr38hTKbnRCxeKJo5NwxVI6HL+tLlbIpeYzLWdVqPD5aNWpzD72onKnUG445 hRUNUwMy7V7pDPQT4QmyLpx7omOuAdbPKjo5maCJxXDiGE2/lvduuCAnjwLXOPYKKR+6 EBbnVgFpi09g5RFFw7/Xfsdb6o3t1nuJ5lthZ7M2MpmYQO6oVWm9U112GC6TV5l6iJNE W/JDvlCb3O6/yjT2ddnj4uGZccr8kOoueuokIWGWV0T/7ODmOnulrYOoJGDy2n9taJnN GUIg== 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=sD4fXOLtecsdMQyHYK0G2fNeazc8p8b1A82kjs/Hnj4=; b=amBPZwBs9dvtMqIkCzm6tx2cEoCAmQhVL3ojU+W/Sz47fo8i0abTqe5OXSxD1vTT/A tK81WO3VokPutTCsS1BWcSrccZ+l/pbIehkB60BTA/YefRtGrIl/qYfxjoJSj7Y7LfxT QTuRdeK/J+Sjsmj+IjS9O5UtOUB6gbycfTHW2SRVdKH+sMjsKjOpN6XMFhrrDvg2M6CI YOOBu8ACMwvhIX01cwNCpXUR5vxK8kb1Vk3HKD3oxvnFB8x5uK+65EmMLRL0id8qpVCJ Vb9Fm44Vn8zxEL2szJ+vAO6KqhqJ3vGw/6g7CRJGTFqxhKdoshrHWY3x9QS1qCWxTJm6 PwXA== X-Gm-Message-State: AOAM5310J666CwSsY9jXquvGLksMhSXW4QWvJwUS7jfHoC+ohRE6bk63 88naD3ymAKkV/ccqTQalCoM= X-Google-Smtp-Source: ABdhPJy05b+vLiZ23x/4lnKjtJdZV5XJpTkaXH6uKLT+uLEWfAy5pyxdCKsxdspk77U3HVrQAhhPHg== X-Received: by 2002:a17:902:7584:b0:12d:8cb5:c7b8 with SMTP id j4-20020a170902758400b0012d8cb5c7b8mr697087pll.84.1629933481120; Wed, 25 Aug 2021 16:18:01 -0700 (PDT) Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id y5sm1033435pgs.27.2021.08.25.16.17.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 16:18:00 -0700 (PDT) To: architecture-discuss@ietf.org Cc: edm@iab.org, "Joel M. Halpern" References: <162991703946.25379.3009360954932586670@ietfa.amsl.com> <078f0246-6e3f-1a49-38e7-cfdae1539c93@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Thu, 26 Aug 2021 11:17:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <078f0246-6e3f-1a49-38e7-cfdae1539c93@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Edm] [arch-d] Call for Comment: (Long-term Viability of Protocol Extension Mechanisms) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 23:18:07 -0000 I support Joel's point, but here are two more. (1) At least for the Internet layer, we have a major problem in deploying new extensions, especially IPv6 extension headers, but this problem goes back 25 years as far as new IPv4 options are concerned. I hoped that section 2.3 "Multi-Party Interactions and Middleboxes" would touch on this, but it doesn't. Looking back in the draft, I see that it intentionally ducks the question: "This document largely assumes that extensions are not deliberately blocked." But what if they are? That's what firewalls do for a living and it's a major block on innovation. In my world, it's much more significant than the concerns in this draft, and none of the suggested techniques help, as far as I can see. I'm not suggesting that this document can solve the problem, but can we have a more complete acknowledgement of it than the sentence quoted above? (2) Again in 2.3 "Multi-Party Interactions and Middleboxes", should there be a discussion of a complex situation where N peers are communicating using protocol P, but each peer potentially supports a different subset of extensions? That gives you up to N^2 possible variants. It's not insoluble, but it needs a bit of care in protocol design (and is different than in a traditional client/server model). Regards Brian Carpenter From nobody Wed Aug 25 16:43:40 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88683A091C for ; Wed, 25 Aug 2021 16:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=lowentropy.net header.b=VnhTUEml; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TP9B6k5X 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 CMkfrYgZshRd for ; Wed, 25 Aug 2021 16:43:32 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DC13A0918 for ; Wed, 25 Aug 2021 16:43:32 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DC2215C00D5 for ; Wed, 25 Aug 2021 19:43:30 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Wed, 25 Aug 2021 19:43:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=ijtVmbzqqUoIJcosLW6LiXIcBuqDGiG 1fZwFpAZIjVM=; b=VnhTUEml1K2qfjBTd15BzkXljsDl5UnePoQ84mdyhEKKZJL XOQynXKR9r7wukx07bF8stbFvSBbuURHrSto6OT5GhPz77YYjK5BpYbYQnZq5act /sOAW9SEQ7Mv6jIHjVTblxhlZC0496S6Ea9USSFB+Z1ePEa37MfjoGyokLAYIRrM aJdsc+clpPCn3tjFIZ+cUnKtEY6t34BLbUTwGM6/bnfkytr+qh1ThnD43oQsEuwn GvKaFd+nZcw1V6XPtoKkH1J9ptcnKUJEvR2DTuNaO/TPFiuT9JT1Dwzel5mQVdCJ IKHSJcw6aGn9Y/VtT2qXQampi2tOELBBcSOWBeA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=ijtVmb zqqUoIJcosLW6LiXIcBuqDGiG1fZwFpAZIjVM=; b=TP9B6k5XwUTTmdlNXx44YZ 3Q4gapUeje+nN+6gf3gF+T0rukHMbkbl2kwSWChwiszVRL7LlxmRdjWOhG7tHJzO 9+PUhZt6/FPBslFkbq+9Q7WTRMH5E0u3XMxXOc2feztwAcUHaN8MDr++95X8bXp2 42UtohXqj83pXknyUwE8/P9ekYfsO2LihT1Gj0XTEVOrma1bYKMf/gswfKvvvSbM WXO18yVj12QYi0//60pZ5UlUx42pRSmb5xf8xZ+PjRCDRzITU1T9OelKpRtkpTAT NoPwTjW4z1lFmWro9SmENmKXh5Wl+Lj32d7aDuPxQSfQqYcBGwcSbKlIFLhmHraQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddutddgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehfeetudduudehtdekhf dvhfetleffudejgeejffehffevkeduiefgueevkeefleenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5A1D53C0F7B; Wed, 25 Aug 2021 19:43:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1125-g685cec594c-fm-20210825.001-g685cec59 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <162991703946.25379.3009360954932586670@ietfa.amsl.com> <078f0246-6e3f-1a49-38e7-cfdae1539c93@joelhalpern.com> Date: Thu, 26 Aug 2021 09:43:11 +1000 From: "Martin Thomson" To: edm@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Edm] =?utf-8?q?=5Barch-d=5D_Call_for_Comment=3A_=3Cdraft-iab-us?= =?utf-8?q?e-it-or-lose-it-02=3E_=28Long-term_Viability_of_Protocol_Extens?= =?utf-8?q?ion_Mechanisms=29?= X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 23:43:39 -0000 On Thu, Aug 26, 2021, at 09:17, Brian E Carpenter wrote: > Looking back in the draft, I see that it intentionally ducks the > question: "This document largely assumes that extensions are not > deliberately blocked." But what if they are? That's what firewalls do > for a living and it's a major block on innovation. Yes, you are not the only one. However, this is very much not in scope for this work. Another document can attempt to convince people that their security goals might need to come second to allowing innovation. (I realize that this might diminish its value for you, but that larger scope is a larger lift than I'm willing to undertake.) > I'm not suggesting that this document can solve the problem, but can we > have a more complete acknowledgement of it than the sentence quoted > above? I can see two angles on this. 1. Where the firewall knows about a feature and specifically chooses to blocks it. 2. Where the firewall doesn't know about a feature and blocks it because it doesn't understand it. Can you agree that there is nothing we gain from trying to do anything about (1)? For (2), I very deliberately avoided making the distinction. My experience with firewalls varies. We had a bunch of really constructive discussions with Web Application Firewall people who very much don't want to block innovation, but who had done so inadvertently. On the other hand, blocking the unknown is very much a stated goal of many SIP SBCs. As far as the pain we all feel as a result of the policies these firewalls apply, that's just part of our job. At best, the only thing we might do is acknowledge that this distinction exists. The conclusion would still be the same though. We might disagree with the policy, or even the right to apply the policy, but as long as we can't prevent someone from applying the policy, it still results in hard constraints for which this document has no answers. > (2) Again in 2.3 "Multi-Party Interactions and Middleboxes", should > there be a discussion of a complex situation where N peers are > communicating using protocol P, but each peer potentially supports a > different subset of extensions? That gives you up to N^2 possible > variants. It's not insoluble, but it needs a bit of care in protocol > design (and is different than in a traditional client/server model). That seems like it is not in scope here, but more of a question of how you might design a multi-party protocol for extension. From nobody Wed Aug 25 17:57:25 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616CD3A07B6 for ; Wed, 25 Aug 2021 17:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 jKFTLxjtAkg7 for ; Wed, 25 Aug 2021 17:57:09 -0700 (PDT) Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (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 35CF23A07BA for ; Wed, 25 Aug 2021 17:57:08 -0700 (PDT) Received: from [66.113.192.7] (helo=xse.mail2web.com) by mx135.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1mJ3hY-000279-9a for edm@iab.org; Thu, 26 Aug 2021 02:57:07 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4Gw4Dv1L6hz9qN for ; Wed, 25 Aug 2021 17:57:03 -0700 (PDT) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1mJ3hX-00012u-2B for edm@iab.org; Wed, 25 Aug 2021 17:57:03 -0700 Received: (qmail 9273 invoked from network); 26 Aug 2021 00:57:02 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.43.180]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Aug 2021 00:57:01 -0000 To: Brian E Carpenter , architecture-discuss@ietf.org Cc: edm@iab.org References: <162991703946.25379.3009360954932586670@ietfa.amsl.com> <078f0246-6e3f-1a49-38e7-cfdae1539c93@joelhalpern.com> From: Christian Huitema Message-ID: Date: Wed, 25 Aug 2021 17:57:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.192.7 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.192.0/27 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.0/27@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zdnjRVD4eEy3TRSD2SvHLmq+mTtWnZRdUcRAwhy3SWIiKw MfCLijpptMpUk9I9PQSzApANqY83rpJh7hdfjGaAYXKidhwbNiuXQkRivKKQJFHwQP/1oFVWjpmQ 3vDgA136BpeseSBELv+0jcKNeZXKWAyXYE7T+LnRZJblNEbj4mpoMTszKjQgH18UMimIMJAsa1lC hqY//n1uao85xWrksiYV62M2tdsFeCLjDbn9kvVLiitsLbvAhupvUnzDINCpfMN2ZXXiUeHbQmLy FsmCMj5faGwFrKq/9lGSwzxN4ah4fdi146VscqgNfYFRJ9QEIQ/iKm3faalwWYaeq3+fdA4PSvr8 BodmIS11My0yWHf8akRJDRRwtEQ5EE4a+1eRN3bkqZd7PvSc10iiaQ7w5YE5enyccp7RH4WQio3u GZgz056Clxvll1wCejDmbqYhEWyJzIkwSFAW0Pw8uiKeiuSXBd2CBcz1/u+XSOBm0rNud3PgzKGZ 88iododq/YfVWMlHoWh7YJ70YBk8N5yx6J1fhOzjF0b4LXcjJZ5lou53frqCMKvmBoMDHzhAW3rr x07Y5Vba0oPc3Nnfyk8Rkh5tVQGbGiB8eIwy9qEj66z1KlI4yatS3mg8yoBRI+JkZaG/BQB+H6f5 aUys/OK6x6fltbaaPuCmX416XzZpXq3zmN1DVbvEznYzgq9IOJt3Nxdc5ZIWF+S4/9qW50lkjaLk xWT3C4wyUk9/uqiMEvpVB9v9zY0h8asEYmbGGsJkWjQ4xyeNtxxq2TXT/AfNBULM95b9J7vkNKjp UoCKnhX0XF3qP/dj48psOHFCwviQxKSBCGH0S84CnKX/NUAV3jR5NeVaJQBh0uawl0Cg8nrgSS6D 7FozWS6JHKREtqdEPzY64lXv2dr2sny4a4Sj0cqzvWDlDrFILmNCVZ/264kd2x35zAiBFPp64JaI ysAWfpirH8g1GOR1IFGt5BWm X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Edm] [arch-d] Call for Comment: (Long-term Viability of Protocol Extension Mechanisms) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 00:57:14 -0000 On 8/25/2021 4:17 PM, Brian E Carpenter wrote: > I support Joel's point, but here are two more. > > (1) At least for the Internet layer, we have a major problem in deployi= ng new extensions, especially IPv6 extension headers, but this problem go= es back 25 years as far as new IPv4 options are concerned. I hoped that s= ection 2.3 "Multi-Party Interactions and Middleboxes" would touch on this= , but it doesn't. In the IP case, I found that using the example of the 4 bit version=20 number is a bit weak. "The version field in IP was rendered useless when = encapsulated over Ethernet" -- AFAIK, that's not just Ethernet. And I=20 don't think anyone seriously considered using the same encapsulation for = v4 and v6, or using the version number for anything besides debugging... The really big example at the IP level would be the IP options (IPv4) or = the IPV6 extension headers. Neither of those really works as intended,=20 pretty much because of the implementation issues that Joel mentions.=20 There is a reason why QUIC runs on top of UDP, not on top of=20 "payload-type =3D QUIC" -- and that's very much in line with the central = point in the draft. > Looking back in the draft, I see that it intentionally ducks the questi= on: "This document largely assumes that extensions are not deliberately b= locked." But what if they are? That's what firewalls do for a living and = it's a major block on innovation. In my world, it's much more significant= than the concerns in this draft, and none of the suggested techniques he= lp, as far as I can see. > I'm not suggesting that this document can solve the problem, but can we= have a more complete acknowledgement of it than the sentence quoted abov= e? I have some sympathy for the assumption in the draft that features are=20 not deliberately blocked. For me, the big issue partial blockage, such=20 as intermediaries allowing some configuration of an e2e protocol but not = others. For e2e deployments, that translates into random failures for=20 obscure reasons. Discussing that will require a fair bit of text, much=20 more than the current section 4.3. I can see why this would be better=20 addressed in a different draft -- like the wire-image draft. But yes,=20 this draft could explicitly point to wire-image for that discussion. -- Christian Huitema From nobody Wed Aug 25 20:39:02 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9DA3A124B for ; Wed, 25 Aug 2021 20:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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 oAUfDaK-39oV for ; Wed, 25 Aug 2021 20:38:58 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 640973A124A for ; Wed, 25 Aug 2021 20:38:58 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id j187so1554609pfg.4 for ; Wed, 25 Aug 2021 20:38:58 -0700 (PDT) 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=If6srtlFuQ50bhAtUiriHnKMh1QeavIqjgEqEDEigJM=; b=ZkkmPRHd4c9/itfjdHFWoUF6G+cnSyauIkPKIC0KWm7p5cNjvrOMiDgVRkCuYrf+dy M0Dhy8Im5pToRkaC9NLq/qah0gP0huhnyo7+JrDFA/aDzCcFw9AVn0DmXu1Eg2gEZAIU /9f7R/t9sj73ZxuXwxzGYkAh4L36jVNkGaTv5sk7L6t27tUYK/YjVQvAInExLft8rPEG P28TYMbIk7JhRabogWv8zcSl2//xr2MbZTxxQatDCZWDkIidR2vn2ty3pfT1gsypIfBy X1SVKFmxXWmluv3weD8c4M1oPHjI+wvE+Jqy3MogSqM7jqsuxdmU7XykeGnicKZNO0de JE/Q== 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=If6srtlFuQ50bhAtUiriHnKMh1QeavIqjgEqEDEigJM=; b=IIJAJ9FXYZvJLatVRuiIgfPXBjeF322jItHv6TUNjOvAn67nM8VXckCEWfmTrqls4O pLfKGwoPeC0cPzsKTCke6i0UVUIGz1fGRcXfdDfMGRYcu89mgmfaMFM9XMZsB9rdJvER PF8pBzlbW0sA0Fa+1YmYbf4TMhBsB9H5yAXd0MJGMUYLBztLYujF/AMYHNbcvEjSUzgV 286L9EoV3EuufBTe4FqvPL9hs5ws1Mz6BsIMhjPPTIkCoSzJ75+Gs1U+Rl75QaCMSZHE uMkZcxJrAjKa6/UCDLgrma/+FzZW8YKAYGMiN756PIGt9dnvgCvSszKVkqkHxW8suS+4 yyhg== X-Gm-Message-State: AOAM532j7Oz2bfba6o7hggaGey4yr+Vni5WgT7s4mMPCZip41TKWJqn5 hSmgGp83Bul0l4Qoj5c0ZU5vN2T2YWiidg== X-Google-Smtp-Source: ABdhPJy3RbInS8ykJMw9RPwYAvkm4Lme9vOWMNYO//X8SZQS0XgZj/bFYmLIbb2IPA+rkxAknVHqMA== X-Received: by 2002:a63:4206:: with SMTP id p6mr1410958pga.449.1629949136107; Wed, 25 Aug 2021 20:38:56 -0700 (PDT) Received: from ?IPv6:2406:e003:11d3:cf01:80b2:5c79:2266:e431? ([2406:e003:11d3:cf01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id b7sm999431pfl.195.2021.08.25.20.38.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 20:38:55 -0700 (PDT) To: Martin Thomson , edm@iab.org References: <162991703946.25379.3009360954932586670@ietfa.amsl.com> <078f0246-6e3f-1a49-38e7-cfdae1539c93@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Thu, 26 Aug 2021 15:38:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Edm] [arch-d] Call for Comment: (Long-term Viability of Protocol Extension Mechanisms) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 03:39:01 -0000 On 26-Aug-21 11:43, Martin Thomson wrote: > On Thu, Aug 26, 2021, at 09:17, Brian E Carpenter wrote: >> Looking back in the draft, I see that it intentionally ducks the >> question: "This document largely assumes that extensions are not >> deliberately blocked." But what if they are? That's what firewalls do >> for a living and it's a major block on innovation. > > Yes, you are not the only one. > > However, this is very much not in scope for this work. Another document can attempt to convince people that their security goals might need to come second to allowing innovation. (I realize that this might diminish its value for you, but that larger scope is a larger lift than I'm willing to undertake.) > >> I'm not suggesting that this document can solve the problem, but can we >> have a more complete acknowledgement of it than the sentence quoted >> above? > > I can see two angles on this. > > 1. Where the firewall knows about a feature and specifically chooses to blocks it. > > 2. Where the firewall doesn't know about a feature and blocks it because it doesn't understand it. > > Can you agree that there is nothing we gain from trying to do anything about (1)? Not much, because sadly Steve Bellovin's "Distributed Firewalls" paper from 1999 failed to revolutionise the industry. (The point being that configuring and applying such blocking *only* at the destination host allows consenting hosts to receive everything they want and drop everything they don't want.) > > For (2), I very deliberately avoided making the distinction. My experience with firewalls varies. We had a bunch of really constructive discussions with Web Application Firewall people who very much don't want to block innovation, but who had done so inadvertently. On the other hand, blocking the unknown is very much a stated goal of many SIP SBCs. Indeed. Also solved 20+ years ago by Bellovin, but such is history. > > As far as the pain we all feel as a result of the policies these firewalls apply, that's just part of our job. > > At best, the only thing we might do is acknowledge that this distinction exists. The conclusion would still be the same though. We might disagree with the policy, or even the right to apply the policy, but as long as we can't prevent someone from applying the policy, it still results in hard constraints for which this document has no answers. I agree. All I'm suggesting is to state it a bit more explicitly. The current sentence is only a . > >> (2) Again in 2.3 "Multi-Party Interactions and Middleboxes", should >> there be a discussion of a complex situation where N peers are >> communicating using protocol P, but each peer potentially supports a >> different subset of extensions? That gives you up to N^2 possible >> variants. It's not insoluble, but it needs a bit of care in protocol >> design (and is different than in a traditional client/server model). > > That seems like it is not in scope here, but more of a question of how you might design a multi-party protocol for extension. True, but the section's title made me expect more than I found in the text. Brian From nobody Wed Aug 25 21:25:14 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BF03A1454; Wed, 25 Aug 2021 21:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=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=lear.ch 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 zIC0UdZNGPsB; Wed, 25 Aug 2021 21:24:48 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 12A7D3A1451; Wed, 25 Aug 2021 21:24:46 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17Q4Obv7234951 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 26 Aug 2021 06:24:38 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629951879; bh=k48LSf7UQd52BKJHc+Bldg364FH9PaAYy0TqqyokC7M=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=X0UjT6nyMcOKFMOSPX1Q1QzJgkFdOsp855t34HN4yB7tZrEHbyiQwdhofS+tod19f EzQhTPCyMsDacCYdWeY5SfVXEJaW2G6V2tYGiE5bmP/I41HB8f7SUl7G9NOE9+1OgV +iYHQRFCcCW+OSGi7i6zetHWjOXWKD9mMb2NlnfE= To: Christian Huitema , Brian E Carpenter , architecture-discuss@ietf.org Cc: edm@iab.org References: <162991703946.25379.3009360954932586670@ietfa.amsl.com> <078f0246-6e3f-1a49-38e7-cfdae1539c93@joelhalpern.com> From: Eliot Lear Message-ID: <59cd4e1c-6fae-8269-e9b9-2eebe0a5a6f3@lear.ch> Date: Thu, 26 Aug 2021 06:24:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SGyirdgn3RUVd5VgsY9Q5krsL6OUZzOe3" Archived-At: Subject: Re: [Edm] [arch-d] Call for Comment: (Long-term Viability of Protocol Extension Mechanisms) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 04:24:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SGyirdgn3RUVd5VgsY9Q5krsL6OUZzOe3 Content-Type: multipart/mixed; boundary="HniV5CgaYlm4whg959y3Zple6PSl3O6uY"; protected-headers="v1" From: Eliot Lear To: Christian Huitema , Brian E Carpenter , architecture-discuss@ietf.org Cc: edm@iab.org Message-ID: <59cd4e1c-6fae-8269-e9b9-2eebe0a5a6f3@lear.ch> Subject: Re: [arch-d] [Edm] Call for Comment: (Long-term Viability of Protocol Extension Mechanisms) References: <162991703946.25379.3009360954932586670@ietfa.amsl.com> <078f0246-6e3f-1a49-38e7-cfdae1539c93@joelhalpern.com> In-Reply-To: --HniV5CgaYlm4whg959y3Zple6PSl3O6uY Content-Type: multipart/alternative; boundary="------------1B52776C6CA5CD787766A4B6" Content-Language: en-US This is a multi-part message in MIME format. --------------1B52776C6CA5CD787766A4B6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I might point out that some features *are* intentionally blocked.=C2=A0=20 Random pings and traceroutes into a network is generally considered=20 unfriendly and have been used as a means to identify points of attack.=C2= =A0=20 There are also features that**are *unintentionally* blocked, simply=20 because they are not understood.=C2=A0 One of the challenges we face is t= he=20 design choices that permit or deny such blocking.=C2=A0 It's made all the= =20 more challenging because protocol designers may not fully understand the = weaknesses in their designs. This having been said, I would be concerned about going too far down=20 that path in this draft, because it really is a work unto itself to explo= re. Eliot On 26.08.21 02:57, Christian Huitema wrote: > I have some sympathy for the assumption in the draft that features are = > not deliberately blocked. For me, the big issue partial blockage, such = > as intermediaries allowing some configuration of an e2e protocol but=20 > not others. For e2e deployments, that translates into random failures=20 > for obscure reasons. Discussing that will require a fair bit of text,=20 > much more than the current section 4.3. I can see why this would be=20 > better addressed in a different draft -- like the wire-image draft.=20 > But yes, this draft could explicitly point to wire-image for that=20 > discussion.=20 --------------1B52776C6CA5CD787766A4B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I might point out that some features are intentionally blocked.=C2=A0 Random pings and traceroutes into a network is gener= ally considered unfriendly and have been used as a means to identify points of attack.=C2=A0 There are also features that are = unintentionally blocked, simply because they are not understood.=C2=A0 One of the challenges we face is the design choices that permit or deny such blocking.=C2=A0 It's made all the more challenging because protocol= designers may not fully understand the weaknesses in their designs.

This having been said, I would be concerned about going too far down that path in this draft, because it really is a work unto itself to explore.

Eliot

On 26.08.21 02:57, Christian Huitema wrote:
I hav= e some sympathy for the assumption in the draft that features are not deliberately blocked. For me, the big issue partial blockage, such as intermediaries allowing some configuration of an e2e protocol but not others. For e2e deployments, that translates into random failures for obscure reasons. Discussing that will require a fair bit of text, much more than the current section 4.3. I can see why this would be better addressed in a different draft -- like the wire-image draft. But yes, this draft could explicitly point to wire-image for that discussion.
--------------1B52776C6CA5CD787766A4B6-- --HniV5CgaYlm4whg959y3Zple6PSl3O6uY-- --SGyirdgn3RUVd5VgsY9Q5krsL6OUZzOe3 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmEnF4UFAwAAAAAACgkQh7ZrRtnSejNQ YAf+OXLFpTqA35BVuFM+YQL2WjP50bciewOOU+heSmE3hKw08HsPAF88vovlRjLh4DKMR7MG2Nxw oB6XyyU3UHlwREvEwjQZer6NZIXuPgI9Ep9A5Ht5uRDFzlEePVf6GVwCkxyxjTxi+hmlhM/dYDZo Ei1CWhSfOb24fbrB4GRXbrdqcSQ3vGfyaFUi5XEoUFSOsHIcmBgkr8aHLrPRt73nso+HR28BJO3D 34/m2M5a4BzJKNxsPAs5+0g+zaGWpVuyClYS15o/tU3PzrUl3/zR0Vr3pK8xbMTkDsmtMswQaBE8 o+2ka4ZdxR9N8oq/Sfn3/oiysD4KcKsQXqAOodWMfw== =aaRe -----END PGP SIGNATURE----- --SGyirdgn3RUVd5VgsY9Q5krsL6OUZzOe3-- From nobody Mon Aug 30 01:50:55 2021 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F4E3A1AC7 for ; Mon, 30 Aug 2021 01:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=open-xchange.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 dBPV--KqeCMr for ; Mon, 30 Aug 2021 01:50:46 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 BAD3F3A1ABC for ; Mon, 30 Aug 2021 01:50:45 -0700 (PDT) Received: from imap.open-xchange.com (imap.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPSA id 98FA56A0CD; Mon, 30 Aug 2021 10:50:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1630313442; bh=z7oZwZzoK7+gogyv/t/fzZ07MaMAPUS7x7MBKFna4QE=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=o9nlQUkMpKgoqisj1Xi+GY3XLSNuNUdI6HbHthZncwnEDHLdL9yYi6wedhDbyNMLb ENWV/h4TAhM6W7GDzv53IqXDr59NSPfeJ7tmQBRmKxDmaVmruro1c4uc+F90ixm5Dj 5KzzCoLM9cA4GmztNmZP1FL0rK+g+Oey8iQzKRbbg3Qy4x4ud1ji9MLHrUEQ0XD3bq 4VjA6MRciDmGnlBg/mM0qIjttN7L7wbD4dDDhT69LaTbC+lMaJm24617vzScFp60Rr KBdG8ntJiobxuKHceOduqkCVgjrsZtSERwr6g/HlpGgnrrJLWrzfL0eHK5wuSo1vda Sz4xag5jgVBIw== Received: from appsuite-gw2.open-xchange.com ([10.20.28.82]) by imap.open-xchange.com with ESMTPSA id RyVaJeKbLGEBGQAA3c6Kzw (envelope-from ); Mon, 30 Aug 2021 10:50:42 +0200 Date: Mon, 30 Aug 2021 10:50:42 +0200 (CEST) From: Vittorio Bertola To: architecture-discuss@ietf.org Cc: edm@iab.org Message-ID: <1498471295.29751.1630313442554@appsuite-gw2.open-xchange.com> In-Reply-To: <59cd4e1c-6fae-8269-e9b9-2eebe0a5a6f3@lear.ch> References: <162991703946.25379.3009360954932586670@ietfa.amsl.com> <078f0246-6e3f-1a49-38e7-cfdae1539c93@joelhalpern.com> <59cd4e1c-6fae-8269-e9b9-2eebe0a5a6f3@lear.ch> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_29749_1809498912.1630313442544" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.5-Rev21 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Edm] [arch-d] Call for Comment: (Long-term Viability of Protocol Extension Mechanisms) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 08:50:53 -0000 ------=_Part_29749_1809498912.1630313442544 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 26/08/2021 06:24 Eliot Lear ha scritto: > > > > I might point out that some features are intentionally blocked. Random pings and traceroutes into a network is generally considered unfriendly and have been used as a means to identify points of attack. There are also features that are unintentionally blocked, simply because they are not understood. One of the challenges we face is the design choices that permit or deny such blocking. It's made all the more challenging because protocol designers may not fully understand the weaknesses in their designs. > The "Limiting participation" section is also affected by this. The first paragraph sounds like advocating that we should have less diversity in Internet operations or protocol implementations, so that we can have the few operators agree among themselves on whatever is necessary to make new features work. (This was indeed the approach of the DNS flag day, which was only possible because there are many DNS operators but very few DNS implementers.) Then, the second paragraph provides examples which are rather related to preventing in-network blocking and meddling by middleboxes and network operators. I think both approaches can help extensibility but create other problems - this should be discussed or at least mentioned. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_29749_1809498912.1630313442544 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 26/08/2021 06:24 Eliot Lear <lear@lear.ch> ha scritto:


I might point out that some features are intentionally blocked.  Random pings and traceroutes into a network is generally considered unfriendly and have been used as a means to identify points of attack.  There are also features that are unintentionally blocked, simply because they are not understood.  One of the challenges we face is the design choices that permit or deny such blocking.  It's made all the more challenging because protocol designers may not fully understand the weaknesses in their designs.

The "Limiting participation" section is also affected by this. The first paragraph sounds like advocating that we should have less diversity in Internet operations or protocol implementations, so that we can have the few operators agree among themselves on whatever is necessary to make new features work. (This was indeed the approach of the DNS flag day, which was only possible because there are many DNS operators but very few DNS implementers.) Then, the second paragraph provides examples which are rather related to preventing in-network blocking and meddling by middleboxes and network operators.

I think both approaches can help extensibility but create other problems - this should be discussed or at least mentioned.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_29749_1809498912.1630313442544--