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