Re: [sidr] this is possibly Tim Bruijnzeels delta protocol

Tim Bruijnzeels <tim@ripe.net> Mon, 22 December 2014 11:55 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D601A8A61 for <sidr@ietfa.amsl.com>; Mon, 22 Dec 2014 03:55:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 zadWk_T_jHE4 for <sidr@ietfa.amsl.com>; Mon, 22 Dec 2014 03:55:32 -0800 (PST)
Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CAF1A036C for <sidr@ietf.org>; Mon, 22 Dec 2014 03:55:32 -0800 (PST)
Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1Y31a9-0000xt-7b; Mon, 22 Dec 2014 12:55:26 +0100
Received: from tel-sslvpn-1.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e8] helo=[IPv6:2001:67c:2e8:5009::40]) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1Y31a9-0005lA-4O; Mon, 22 Dec 2014 12:55:25 +0100
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_97FB1CFA-3ED9-4293-A78E-73EC0FED0C15"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <A2FA0065-2251-45C9-AF73-945EA6130CCE@ripe.net>
Date: Mon, 22 Dec 2014 12:55:22 +0100
Message-Id: <6DD59BFC-7E1D-4186-AE7E-472203B3E1B2@ripe.net>
References: <E481F170-AF18-47E7-9E55-8436ECC5A953@tislabs.com> <A2FA0065-2251-45C9-AF73-945EA6130CCE@ripe.net>
To: sidr wg list <sidr@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071995f2a5d0afb4e2e366e239337fa9397d
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/wEhuF-gQvycoZOFSmgI70jGeAXQ
Cc: Sandra Murphy <Sandy@tislabs.com>
Subject: Re: [sidr] this is possibly Tim Bruijnzeels delta protocol
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Dec 2014 11:55:34 -0000

Hi all,

On 14 Nov 2014, at 21:38, Tim Bruijnzeels <tim@ripe.net> wrote:
> ...and I hope to post it to the wg within two weeks...

A little later than I was hoping for, but I just uploaded a revised version:
http://www.ietf.org/id/draft-tbruijnzeels-sidr-delta-protocol-03.txt

I would like to ask the working group to read this version and I would like to ask the chairs for a formal call for adoption of this work.

This version of the document is quite different from previous versions that you may have read. The basic principle is unchanged. The format of the protocol messages has been simplified quite a bit and reflects proof of concept implementations that Rob Austein and I have worked on, and tested interoperability on, over the last months. The supporting text (reasoning and text on usage of the protocol etc) has also been revised. Some elements of that text are definitely still up for discussion: e.g. when talking about how *long* a notification file may be cached. We tried to outline these discussions clearly in the document.


Regards,

Tim Bruijnzeels