Postel's Principle and Layer 9 protocol engineering

Larry Masinter <LMM@acm.org> Sun, 06 June 2021 18:14 UTC

Return-Path: <masinter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6763A2336 for <ietf@ietfa.amsl.com>; Sun, 6 Jun 2021 11:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no 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 LZtTGQoe8hOT for <ietf@ietfa.amsl.com>; Sun, 6 Jun 2021 11:14:01 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 9971E3A2334 for <ietf@ietf.org>; Sun, 6 Jun 2021 11:14:01 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id h12-20020a17090aa88cb029016400fd8ad8so8983867pjq.3 for <ietf@ietf.org>; Sun, 06 Jun 2021 11:14:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:mime-version :content-language:thread-index; bh=cun3BvUNuqBc9sCLCmFjdxjEU9VYYbMctvNZ00nwkj0=; b=hXKwG45ko2BT7hBS8e+rSs74TxMs26OAS3Zf02I9sBiKqR2ki+YOuwvffqFvUC9U39 OvYELFBN9dXrRq8MAuIrLZCLYIybp4lfymBpU0uoHVb7pW4Y8IW4pntaO57m52RFNIkN eQvXckt5mQvHY71mNGvh3SABTA9gq+ttEYcwLDAxfzm/JSAMYcnrdxD1kDEwVXzDqxbA r6HdhTUl7EUzZ4TW6V1hClRPT8ttwW+WUe5phUlhZx+CoM6n2JHX8PKJljOAnwrqNhDv 1HuzFdzXxTK+rSIH8CnCThq9NjU8EPYqbJbUoTj8QPVM3h5We/dhgUzx2gdAF8bRe2ra v7AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:content-language:thread-index; bh=cun3BvUNuqBc9sCLCmFjdxjEU9VYYbMctvNZ00nwkj0=; b=L97KT3JamIGLr/tibHefye+XOSwrp1UBh8xgydl7YeRNM7clw29s6iZbnn6kdjY+Mr kFqVSobYLWI90BjudLQ1S5leRJnvozVgwApZDY2pqCWbvV+bSvPzQfjt/M710mag6nKP i6xBlney43mthwFQfoIArPyosOJvyT/m3A5JfX9drQ8eTGfp4jAiJXPal9MaXeuyy/51 IjDQwI6vbkRoOFF5fHH09tEBxkvqaAlHZ/ChWKZ3AyOop5rhk7q22Bn/aYyVikqdYGHx FyP//lWVdR89QB4YOJIHAcxb52m4LuWSdu3PA4e/JfJCkKuPrK6BbnVifzRwv0BWYUm+ dXoQ==
X-Gm-Message-State: AOAM5335DJIVQI71qI0bupDs7GYUttWhWbrwxBQF5Sg0DqVD1WkO2rjM pd7EoE+mypNs0w+p08FAzmTC/z7bMu0=
X-Google-Smtp-Source: ABdhPJzF+WPczCdEiVXVa/+NZqJ6C9cgQtcC6yT5zFrz8Ur0YX5QleoAaKGQl5HBNXwQkoM0lgEERA==
X-Received: by 2002:a17:902:8645:b029:fd:25ef:3df7 with SMTP id y5-20020a1709028645b02900fd25ef3df7mr14259679plt.48.1623003240242; Sun, 06 Jun 2021 11:14:00 -0700 (PDT)
Received: from TVPC (c-73-158-116-21.hsd1.ca.comcast.net. [73.158.116.21]) by smtp.gmail.com with ESMTPSA id p24sm4269205pfh.17.2021.06.06.11.13.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Jun 2021 11:13:59 -0700 (PDT)
Sender: Larry Masinter <masinter@gmail.com>
From: Larry Masinter <LMM@acm.org>
X-Google-Original-From: "Larry Masinter" <lmm@acm.org>
To: 'Emil Ivov' <emil@jitsi.org>
Cc: 'Dean Willis' <dean.willis@softarmor.com>, 'Jared Mauch' <jared@puck.nether.net>, ietf@ietf.org
Subject: Postel's Principle and Layer 9 protocol engineering
Date: Sun, 06 Jun 2021 11:13:59 -0700
Message-ID: <001b01d75aff$b951dff0$2bf59fd0$@acm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01D75AC5.0CF3CB40"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: Adda++7d3sFpvoabSwqnk3xI7K99zw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/KdTTelQwzEfOswRYy_ohtuyfxl8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Jun 2021 18:14:07 -0000

I wasn’t taking Postel’s Principle as a given, or saying others SHOULD follow it.

I was trying to offer a perspective for reasoning about content moderation

which I thought might be helpful to the protocol engineers amongst us.

 

IETF regularly engages in Layer 9 protocol engineering whenever we 
talk about harassment, NOTE WELLs, working group formation, choice
of technical infrastructure, etc. 

 

FB is faced with intense conflicting pressure to moderate
content or disallow content. 

 

But banning someone is very different from delaying their posting
for a reasonable length of time. Especially if the algorithm used
is clear enough that participants who value the ability to
communicate without delay can readily choose other ways
of expressing their perspective, without resorting to hyperbole.

 

--

 <https://LarryMasinter.net> https://LarryMasinter.net  <https://interlisp.org> https://interlisp.org

 

From: Emil Ivov <emil@jitsi.org> 
Sent: Sunday, June 6, 2021 12:13 AM
To: Larry Masinter <LMM@acm.org>
Cc: Dean Willis <dean.willis@softarmor.com>; Jared Mauch <jared@puck.nether.net>; ietf@ietf.org
Subject: Re: Why we really can't use Facebook for technical discussion.

 

Ironically, advising *others* how *they* should follow Postel’s principle is exactly the opposite of the principle.

 

On Sun, Jun 6, 2021 at 00:44 Larry Masinter <LMM@acm.org <mailto:LMM@acm.org> > wrote:

This is the argument about Postel's principle (conservative in what you send, liberal in what you accept) in layer 9.
It seems to me that Facebook is doing just fine slowing down (24 hours) the possible propagation of violence incitement without requiring a lot of judgement on what does or does not constitute thoughtful vs. inciteful speech.

"Kill them all and let TCP sort it out" can readily be expressed in other terms. A content moderation policy that slowed down frequent postings (by 24 hours) might temper heated conversations and lead to calmer considerations of the actual requirements. 

> I hereby propose we censor Facebook engineers in IETF meetings for promoting stupidity.

Can public forums improve the quality of discussion by delaying frequent, divisive posters?
Is trying to do so really  "promoting stupidity"? (Obligatory 😊)

--
https://LarryMasinter.net https://interlisp.org

-- 

sent from my mobile