Re: [Endymail] We're not done yet

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 18 November 2014 09:43 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: endymail@ietfa.amsl.com
Delivered-To: endymail@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738121A00E5 for <endymail@ietfa.amsl.com>; Tue, 18 Nov 2014 01:43:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham
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 N6YUxbd86Zhr for <endymail@ietfa.amsl.com>; Tue, 18 Nov 2014 01:43:51 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E87B1A0041 for <endymail@ietf.org>; Tue, 18 Nov 2014 01:43:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1A641BE39; Tue, 18 Nov 2014 09:43:48 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQNaWRa8IZP6; Tue, 18 Nov 2014 09:43:47 +0000 (GMT)
Received: from [10.87.48.11] (unknown [86.42.22.166]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 96C01BE32; Tue, 18 Nov 2014 09:43:46 +0000 (GMT)
Message-ID: <546B14D2.2060109@cs.tcd.ie>
Date: Tue, 18 Nov 2014 09:43:46 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>, endymail <endymail@ietf.org>
References: <CACsn0ck-bueehMDjgx-Co=bL0pLkeJM=Fqc0T_SDT4bdX4nzPg@mail.gmail.com> <20141117063948.GX13179@mournblade.imrryr.org> <alpine.LFD.2.10.1411170150290.7218@bofh.nohats.ca> <20141117072536.GY13179@mournblade.imrryr.org> <alpine.LFD.2.10.1411170229450.7218@bofh.nohats.ca> <20141117074941.GA13179@mournblade.imrryr.org> <CACsn0cmbjTMR__Fh_Z6i=_Ky8z5XPaqUu5NZetVJW0YYnpOC1A@mail.gmail.com>
In-Reply-To: <CACsn0cmbjTMR__Fh_Z6i=_Ky8z5XPaqUu5NZetVJW0YYnpOC1A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/o_vKvlgxJEyg6IJKPPdGh2QLE10
Cc: Dave Crocker <dcrocker@bbiw.net>
Subject: Re: [Endymail] We're not done yet
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2014 09:43:54 -0000


On 18/11/14 05:11, Watson Ladd wrote:
> Do architecture and requirements documents actually work? Or do they
> end up overcomplicating solutions, as designers attempt to address
> things that maybe should be punted on, as they cost too much to
> implement? They certainly don't help with analysis: the requirements
> documents may be wrong themselves!

Oftentimes, those documents don't work in the IETF, I agree.
This might be an exception, since there are a bunch of folks
who're developing full solutions outside of the IETF and part
of the point of this list is to see if there are things the
IETF can do to help multiple of those solutions. (In the
hope that one of 'em cracks it and would then get sufficient
adoption that it'd be worth standardising later.)

I know Dave Crocker has done some work in this space (and he's
the author of RFC5598 as well) - so Dave, do you think there'd
be value in an RFC along those lines describing an architecture
for a modern secure interpersonal messaging system that could
scale and supports implementations with privacy friendly
features? (I'd like to see such a document myself, but am
unsure if doing one now-ish would be effective or not - we
might be too early or late.)

S.