Re: [arch-d] Time to reboot RFC1984 and RFC2804?

Mo Balaa <> Mon, 12 October 2020 07:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8DE43A12EE for <>; Mon, 12 Oct 2020 00:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vaxPl6DEP99t for <>; Mon, 12 Oct 2020 00:42:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02A243A12CD for <>; Mon, 12 Oct 2020 00:42:27 -0700 (PDT)
Received: by with SMTP id k8so12758632pfk.2 for <>; Mon, 12 Oct 2020 00:42:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=UA4ksxA/zRth4AZD0avf1Vx+1QCNtzJgz8J35p2dIyw=; b=JK/mdFAq2C83eWooKwDMKmxzp6nnA4EpR0p0e7ehR1vC9KaQmFsSFJco65odYIDsP+ 5T4RlZPNk8kRt8EH6DXExLA0Dmah+zIeo8Rf7H1/GjUIJCaPgSguSnA6x8ITkRzO/TNo POtSOfU3PZIU4Ce/yfxwqLiYP8NfMsukAKwZ0eCMFXTvAXaOvyxOVOTwBMwZ2nZaoKNw hBK3wuOjEvvxCTcHNEAexiPPV8w6g5PgQmf0Sg73auchX+KOJKYv4T3SSh/sYR94khEP QVA5SX8y/lxBVq4ov7pHWoV9O21XqgYTcnQkKQobNBNTRaly1RJEwwY3ZATQ+KWfkqbH VVFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=UA4ksxA/zRth4AZD0avf1Vx+1QCNtzJgz8J35p2dIyw=; b=pSbFNcKl/9ea9bqBQdRPcUljwpWkP5yj0NiB2RR4gVIJ7Ge12q3EyzFz/4eNsLxsSM S7H5Zmc/2Jlzl/vY84lc0LtBAOdJvZ5GChzcp4X+u+BX41ssB39+HH9+jVLI6/G5HTnr Ay0ZqT9rx7X71aIk8FKjNtGt/XgeefuXiugdY+1Y3Op21ElbGvkQ62y2vtaaszjHnUUn LmOckj6drY3QQW3nI/SGnVOafo/P5G4Sh20p399vppJixgRdqcDqw3x/dwFP07nqYmV0 krrBSlvVHNrgdoj3ojz+nqW+7SKK6bGyrUD0TnNQMNEVsDeQkAmUOKo178xkXdbzpDtW ZE0Q==
X-Gm-Message-State: AOAM533D8BrqnTEHRRhBdYTMBUvA1jVA2AIt2T/yudavwrdOdcgegukV PyaGnoYDr5d4vB0Dnmtk3KgPkbwqcHiF8w==
X-Google-Smtp-Source: ABdhPJzegsffDU9cxA4fzTkK83MO9+DK4uhrOmQvGRPYs21CP0nnZJBC6XBw54+s0elrONDaWc9K2A==
X-Received: by 2002:a63:3205:: with SMTP id y5mr12099648pgy.122.1602488546880; Mon, 12 Oct 2020 00:42:26 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j3sm7115624pjv.20.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2020 00:42:26 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Mo Balaa <>
Mime-Version: 1.0 (1.0)
Date: Mon, 12 Oct 2020 02:42:24 -0500
Message-Id: <>
References: <>
Cc: John C Klensin <>, Brian E Carpenter <>,
In-Reply-To: <>
To: Christian Huitema <>
X-Mailer: iPad Mail (18A393)
Archived-At: <>
Subject: Re: [arch-d] Time to reboot RFC1984 and RFC2804?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Oct 2020 07:42:33 -0000

Shameless plug for some experimental protocols we’ve been developing. We call them Noteworthy (class of) distributed overlay protocols. TBH we aren’t experts at this kind of stuff but are concerned that the window of opportunity to establish these types of FOSS standards/strategies is rapidly closing. We are actively seeking contributors, mentors or advisors. We are imagining meta-protocols build atop decentralized messaging protocols like Matrix. We have a working prototype.

> On Oct 11, 2020, at 5:50 PM, Christian Huitema <> wrote:
> On 10/11/2020 2:20 PM, John C Klensin wrote:
>> It seems to me that we (very broadly defined) may be headed into
>> a period in which:
>> (1) We are forced into a choice between encryption and other
>> technical privacy protections against attacks (borrowing the
>> 7258 language) by individuals and attacks by governments
>> (including law enforcement), especially governments who have
>> jurisdiction over the sender, receiver, or other.  The default
>> if we don't choose and make the distinction clear to others may
>> be "neither".
>> and/or 
>> (2) We are forced into a choice between an open and global
>> Internet and one that is very fragmented with security and
>> privacy protective only within mutually-isolated more local
>> networks.  We would have either no communication among those
>> local networks or content filtering, application-level, gateways
>> at politically selected boundaries.  Refusing to chose might
>> result in both bad outcomes.
> There may be something else. The government actions typically operate
> through application providers acting as gatekeepers, as in "Facebook,
> please provide me a clear-text version of these messages". If there are
> just a few platforms managing a large share of the communications,
> governments merely have to lean onto these platforms to obtain what they
> want. And if a company is running a big communication business, it will
> come to terms with local governments in order to protect that business.
> If the IETF wants to protect individual freedoms, then it might want to
> focus on distributed architecture for communication services.
> -- Christian Huitema
> _______________________________________________
> Architecture-discuss mailing list