Re: [sidr] Slides for "RPKI Over BitTorrent" presentation

Eric Osterweil <> Sun, 01 April 2012 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE1F321F88CD for <>; Sun, 1 Apr 2012 12:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F9vg2A4TyIJw for <>; Sun, 1 Apr 2012 12:27:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B831D21F88D5 for <>; Sun, 1 Apr 2012 12:27:05 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKT3isBVL7llFytS/oOFjotunrGZeAyQw/; Sun, 01 Apr 2012 12:27:06 PDT
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id q31JQvV8000499; Sun, 1 Apr 2012 15:26:57 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 15:26:56 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <>
In-Reply-To: <>
Date: Sun, 01 Apr 2012 12:26:54 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Rob Austein <>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 01 Apr 2012 19:26:56.0547 (UTC) FILETIME=[66AFF730:01CD103D]
Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Apr 2012 19:27:07 -0000

On Mar 29, 2012, at 12:04 PM, Rob Austein wrote:

> At Wed, 28 Mar 2012 20:33:24 -0400, Danny McPherson wrote:
>> i don't think the rsync scale issues surprise anyone that was paying
>> attention.  If we're already considering new architectures,
>> substrates, et al., here perhaps we shouldn't be so quick on the
>> trigger for Standards Track work and move this and related
>> "investigation" to the IRTF, or at least ensure they're only
>> Experimental until broader experience is gained.


> For the record, this presentation was originally targeted at the IEPG,
> as a direct follow-up to multiple suggestions received at a previous
> IEPG meeting that it might be interesting to see how BitTorrent works
> in this environment.  I presented this at the SIDR WG meeting because
> the chairs thought it might be of interest to the WG.

So, I just want to wade in here very quickly: in the sidr wg we are constantly facing packed agendas, multiple sessions, and now interim meeting extravaganzas... I feel like there is no shortage of feedback that people try to give to many of the drafts (during sessions and obviously on the list), but the session agendas often seem to require the chairs to cut the mic lines (imho) way too early.  This has made feedback harder to give.  I (for one) was a little surprised to see the bittorrent work presented at both the iepg and again during the wg considering the amount of feedback that often comes from pretty much _any_ given draft on the agenda.  I am not claiming it is bad work, inappropriate, or anything like that.  Simply, an interesting scheduling choice...

With all due respect (honestly, I know this can't be easy), I really feel this is symptomatic of a disconnect between the session agendas and the level of comfort that the overall wg members have with some of the drafts.  I really think fewer/more focused sets of presentations are critical to moving forward and I think I've heard _several_ people on the list push very hard for us to return our focus to solid requirements analysis (which I think very much should include drafts like the req's draft, Steve's threats draft, etc) so that we can evaluate the nature of the work we are all trying to do separately from how implementations and designs are being fleshed out.  Getting the wg members on the same page wrt what we are trying to do would likely make a number of points of friction smoother.  I really think this does _not_ necessarily invalidate work that has already been done (though we may still need to examine some of it carefully).  For example, Danny's questions to Rob et al about the scaling requirements that the protocol was aimed at is very apropos of us proceeding in an orderly fashion towards a feasible security system.  Lessons learned from experiments can be used to inform evolving requirements.  That is, this isn't necessarily the waterfall software lifecycle ( ), which only goes forward without feedback loops.  Personally, I would find it helpful to see less packed, more focused, and a return to reqs in future sessions if possible...  And, yes, we should strive for world peace too...