Re: [Sidr] Architecture document: narrowing the scope

Shane Amante <shane@castlepoint.net> Tue, 11 March 2008 05:25 UTC

Return-Path: <sidr-bounces@ietf.org>
X-Original-To: ietfarch-sidr-archive@core3.amsl.com
Delivered-To: ietfarch-sidr-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3F828C1C0; Mon, 10 Mar 2008 22:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.761
X-Spam-Level:
X-Spam-Status: No, score=-99.761 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FaBw0UeBLi3; Mon, 10 Mar 2008 22:25:20 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B673A6921; Mon, 10 Mar 2008 22:25:20 -0700 (PDT)
X-Original-To: sidr@core3.amsl.com
Delivered-To: sidr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6243A6921 for <sidr@core3.amsl.com>; Mon, 10 Mar 2008 22:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgIE46+FbdIS for <sidr@core3.amsl.com>; Mon, 10 Mar 2008 22:25:18 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 33D7F3A6826 for <sidr@ietf.org>; Mon, 10 Mar 2008 22:25:18 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id A0662268037; Mon, 10 Mar 2008 23:22:58 -0600 (MDT)
Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; Mon, 10 Mar 2008 23:22:58 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=50498; data-bytes=0
Message-ID: <47D6172F.1040502@castlepoint.net>
Date: Mon, 10 Mar 2008 23:22:55 -0600
From: Shane Amante <shane@castlepoint.net>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
References: <alpine.LRH.1.00.0803110039560.26663@netcore.fi> <p06240516c3fb6e75c7b9@[10.150.134.25]> <D38AE639-2669-44BF-8544-8FBF8D2BE3BD@tcb.net> <p06240501c3fb8387cbbb@[10.150.132.243]>
In-Reply-To: <p06240501c3fb8387cbbb@[10.150.132.243]>
Cc: sidr@ietf.org
Subject: Re: [Sidr] Architecture document: narrowing the scope
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

All,

FWIW, I agree with the sentiments echo'ed by Pekka & Danny and would 
support a narrowing of the Title, etc. to more accurately reflect the 
present architecture being discussed.

-shane


Stephen Kent wrote:
> At 5:46 PM -0600 3/10/08, Danny McPherson wrote:
>> On Mar 10, 2008, at 5:22 PM, Stephen Kent wrote:
>>
>>> Pekka,
>>>
>>> I agree that a title with a narrow scope is appropriate, but I
>>> believe that you suggested revision is too narrow. The RPKI is
>>> broader in scope than just route origination, as Geoff noted. For
>>> example, the SBGP and soBGP proposals,  which were debated
>>> extensively in RPSEC, both address path validation and both rely on
>>> the sort of PKI that is being covered in this document. I think some
>>> additional wordsmithing on the title and abstract is needed.
>> But RPKI provides an infrastructure *to enable those*, OR a static
>> route filter, or any of a number of other things.  Listing the array
>> of things that might be done and implying that SIDR itself provides
>> that capability is misleading.
>>
>> -danny
> 
> Listing the capabilities that the RPKI enables seems reasonable to 
> me, so long as we don't claim that the near term work items will 
> yield solutions to all of them.  The RPKI is not designed to support 
> "any number of things." It is designed to support a set of near and 
> longer term BGP routing security solutions.
> 
> Steve
> _______________________________________________
> Sidr mailing list
> Sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr