IETF Logo Mail Archive

Re: [sidr] RPKI <-> allocation consistency

Eric Osterweil <eosterweil@verisign.com> Thu, 30 August 2012 14:59 UTC

Return-Path: <eosterweil@verisign.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A4E21F8621 for <sidr@ietfa.amsl.com>; Thu, 30 Aug 2012 07:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.413
X-Spam-Level:
X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHVVgEx1Sg13 for <sidr@ietfa.amsl.com>; Thu, 30 Aug 2012 07:59:15 -0700 (PDT)
Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 10DF621F8619 for <sidr@ietf.org>; Thu, 30 Aug 2012 07:59:15 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUD9/wILbSHUhhve413G15zSyPAm+mwOO@postini.com; Thu, 30 Aug 2012 07:59:15 PDT
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q7UEx9gW021406; Thu, 30 Aug 2012 10:59:11 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Aug 2012 10:59:09 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <503D141F.1060404@bbn.com>
Date: Thu, 30 Aug 2012 10:59:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <D857A4BB-E484-45A4-A09F-FB8FAF2215AC@tcb.net> <C5B88834-3A10-41F7-A4F3-2B7C9B540197@verisign.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 30 Aug 2012 14:59:09.0006 (UTC) FILETIME=[021006E0:01CD86C0]
Cc: sidr@ietf.org
Subject: Re: [sidr] RPKI <-> allocation consistency
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 30 Aug 2012 14:59:15 -0000

On Aug 28, 2012, at 2:55 PM, Stephen Kent wrote:

> Eric,
> 
> Perhaps what you are looking for is some text in an operations doc, suggesting what
> an RP can expect, depending on how it elects to interact with the repository system,
> maintain its local cache, etc.

Actually, I was looking for some intuition/guidance for people in a position to take a systematic look at how to implement the design.  I'm not sure which draft, or which section, etc.  Basically, I'm trying to get things worked out, but I keep having issues w/ ensuring that ingestion of data by a process at (say) one router has something/anything to do with the ingestion of the same thing at (say) another router.  Consistency models tell me what properties I can rely on at time t_0 at location r_0 vs time t_1 at r_1, etc.  Right now, I'm having a lot of trouble ensuring that anything agrees with anything else in the Interwebz and I don't know if I should just let that be the case, or there is some sort of consistency I need to adhere to...

Eric

v2.23.0 | Report a Bug | By Email