Re: [arch-d] Time to reboot RFC1984 and RFC2804?
Toerless Eckert <tte@cs.fau.de> Wed, 14 October 2020 01:34 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 208EA3A12DF for <architecture-discuss@ietfa.amsl.com>; Tue, 13 Oct 2020 18:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 v9gXj7isNrdJ for <architecture-discuss@ietfa.amsl.com>; Tue, 13 Oct 2020 18:34:39 -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 2E55E3A12DA for <architecture-discuss@ietf.org>; Tue, 13 Oct 2020 18:34:38 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9AD65548019; Wed, 14 Oct 2020 03:34:32 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8E294440059; Wed, 14 Oct 2020 03:34:32 +0200 (CEST)
Date: Wed, 14 Oct 2020 03:34:32 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Message-ID: <20201014013432.GF57007@faui48f.informatik.uni-erlangen.de>
References: <e80b6f1e-3949-b2ee-6e61-a2f3dfce9b0c@cs.tcd.ie> <586DC363-B5F8-4727-8734-815F3E17F345@gmail.com> <c5b37390-d463-fa35-215b-569698098d6a@cs.tcd.ie> <65CD5A4A-E7AD-4051-90A6-31AD536AB0AD@gmail.com> <e29dc18a-fd5d-ca0d-90a0-4ec840678054@gmail.com> <LO2P265MB0573F23F5C23ABD3933E49FDC2040@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <20201014001246.GD57007@faui48f.informatik.uni-erlangen.de> <623a0c86-ca51-d07b-34b1-ddec84ac9207@cs.tcd.ie> <20201014005137.GE57007@faui48f.informatik.uni-erlangen.de> <2856893d-f8b0-8259-5316-2f6c0415fb72@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2856893d-f8b0-8259-5316-2f6c0415fb72@cs.tcd.ie>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/AN6eLDrSVIzDlwzj0YNgXwnz8lc>
Subject: Re: [arch-d] Time to reboot RFC1984 and RFC2804?
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2020 01:34:41 -0000
Stephen, You are making all my argument better than i can. I can only predict that if your line of thinking and talking persists in I* leadership then IETF will continue to loose relevance for the industry at large. Too bad. Cheers Toerless On Wed, Oct 14, 2020 at 02:12:50AM +0100, Stephen Farrell wrote: > > > On 14/10/2020 01:51, Toerless Eckert wrote: > > On Wed, Oct 14, 2020 at 01:23:03AM +0100, Stephen Farrell wrote: > >> > >> > >> On 14/10/2020 01:12, Toerless Eckert wrote: > >>> TLS 1.3 is the best example. The abuse of IETF principles by its > >>> rough mayority was not the rough consensis on rfc8446, but how it was > >>> made clear that dissenting profiles, even if mean to be used only for > >>> controlled networks would not find a home in the IETF. > >> > >> If I understand your grammar correctly, I consider that > >> counterfactual nonsense. > > ^^^^^^^^^^^^^^^^^^^^^^^ > > > > Offensive, dismissive judgements are not a technical argument. > > Asserting that something is counterfactual should not be > offensive. Well perhaps it might to someone who found some > facts offensive, I'm not sure;-) Nonsensical statements are > the opposite of sensible ones, and are common on IETF > lists. I'm quite surprised any of that is surprising to > anyone that posts often. > > All that said, I do think a bit of dismissal is warranted > though - the TLS WG wasted a year and a bit on that stuff > for no good reason, so yes I do think those who claim those > nonsense arguments don't deserve to be dismissed are wrong. > (Surely we're ok to dismiss zombie arguments like these, > if for no other reason than efficiency in the face of an > utter lack of new [or actually also of old!] facts?) > > > > >> TLS1.3 was quite a good example > >> of running the process and even of extending the set of > >> people participating to bring in lots of new and real > >> expertise. > > > > Thanks for rephrasing the first part of what i said. My criticism was > > about the additional TLS profile RFC(s) that did not happen in the IETF due > > to very clear resistance to them even though there was a big enough > > community supporting them. > > Again, that's counterfactual. The proponents of breaking > TLS1.3 in that way, (draft-green et. al.) had many many > opportunities to make their (weak) case. They did that, > some very badly, some less so. And they failed to be > convincing. > > Then some of them went to a captive group in ETSI and got a > rubber stamp for their (IMO terrible) idea. For me, that > says more about a lack of quality control in ETSI than > anything else. I hope TLS and web implementers continue to > entirely ignore the output of that supposed piece of > "work." > > > Aka: The TLS RFC NOT for the Internet but > > for controlled networks with specific three party trust. > > That discussion was had. TLS is a two party protocol. You > may wish the outcome had been otherwise but it was not. > > S. > > > > > Cheers > > Toerless > > > >> S. > > > > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <stephen.farrell@cs.tcd.ie> > >> sub RSA 4096/36CB8BB6 2017-12-22 > >> > > > > > > > > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <stephen.farrell@cs.tcd.ie> > sub RSA 4096/36CB8BB6 2017-12-22 > -- --- tte@cs.fau.de
- [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? John C Klensin
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Christian Huitema
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Mo Balaa
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? John C Klensin
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Vittorio Bertola
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Joel M. Halpern
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? John C Klensin
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Christian Huitema
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Eliot Lear
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Eliot Lear
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Guntur Wiseno Putra
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter