Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)

Tim Bruijnzeels <> Thu, 16 February 2017 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E594129509; Thu, 16 Feb 2017 07:17:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yDVEabBEGBUU; Thu, 16 Feb 2017 07:17:37 -0800 (PST)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E2351293DF; Thu, 16 Feb 2017 07:17:37 -0800 (PST)
Received: from ([]) by with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1ceNoM-0009oD-G4; Thu, 16 Feb 2017 16:17:35 +0100
Received: from ([] by with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <>) id 1ceNoM-0004lK-BO; Thu, 16 Feb 2017 16:17:34 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="us-ascii"
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Thu, 16 Feb 2017 16:17:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Terry Manderson <>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ---------
X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0001]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719dba7a7c4e2256e22ff301fcd746ad50e
Archived-At: <>
Cc:,,, The IESG <>,
Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Feb 2017 15:17:39 -0000

Hi Terry, all,

> On 16 Feb 2017, at 03:03, Terry Manderson <> wrote:
> Terry Manderson has entered the following ballot position for
> draft-ietf-sidr-delta-protocol-07: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for this work, it is clear and well written. While I have never
> (ever) been enamoured by RSYNC, and I much prefer this direction on a
> personal level, the updates to the existing RFCs regarding RSYNC does two
> things. The first is it demotes RSYNC to 'just another access mechanism',
> and the second is it appears to remove the quality of a mandatory to
> implement retrieval mechanism. Am I reading that correctly? If this is
> intentional and has workgroup consensus so be it and onwards we move..

Initially this was written as an additional protocol, next to rsync. The idea was that rsync would be replaced altogether at some point, but the way to get there was intentionally left out of this document because we felt it should just focus on protocol.

The changes you mention were made following AD review comments on 7 January. The intent as I understood it was to defer the question which retrieval mechanism is mandatory to another document, but leave the specifications generic. 

In itself I understood that this is okay. Because current deployment can follow the unaltered specifications. It does leave the question of defining this better for future implementation though - to make RRDP formally usable. I am not sure how to deal with this and would value direction :)

I believe we need 'something' saying that:

- currently:
  = rsync is mandatory
  = RRDP is allowed as an additional mechanism

- on date x:
  = RRDP is mandatory and rsync is no longer allowed
  = at this point we will also need to address the "URI" in the publication protocol

I am not sure if that A) needs to be described in one migration document with a time line, or that B) it would be better to do something similar to RFC7935 (defining algorithms and key sizes) and have a document that describes the "currently" required and allowed retrieval mechanisms and update it in due time. And I may be missing options C, D, etc here.

Myself I am leaning to doing B in sidr-ops, but again pointers are appreciated.


> _______________________________________________
> sidr mailing list