Re: [sidr] draft-ietf-sidr-repos-struct to Standards Track

"t.petch" <ietfc@btconnect.com> Sat, 23 July 2011 20:06 UTC

Return-Path: <ietfc@btconnect.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 515D821F8563 for <sidr@ietfa.amsl.com>; Sat, 23 Jul 2011 13:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
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 S1KN5uZkZMdN for <sidr@ietfa.amsl.com>; Sat, 23 Jul 2011 13:06:51 -0700 (PDT)
Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id 028E921F8561 for <sidr@ietf.org>; Sat, 23 Jul 2011 13:06:50 -0700 (PDT)
Received: from host86-174-254-236.range86-174.btcentralplus.com (HELO pc6) ([86.174.254.236]) by c2bthomr10.btconnect.com with SMTP id DUD21979; Sat, 23 Jul 2011 21:05:56 +0100 (BST)
Message-ID: <026301cc496b$235c94a0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Stephen Kent <kent@bbn.com>
References: <CA4F1AA8.1818D%terry.manderson@icann.org> <00f401cc488a$3f562a40$4001a8c0@gateway.2wire.net> <p06240801ca507ca63ba7@[172.17.25.20]>
Date: Sat, 23 Jul 2011 21:02:53 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E2B29A2.0069, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.7.23.183914:17:7.586, ip=86.174.254.236, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_1100_1199, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4E2B29A5.0016, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: Rob Austein <sra@isc.org>, draft-ietf-sidr-repos-struct@tools.ietf.org, sidr@ietf.org, sidr-chairs@tools.ietf.org
Subject: Re: [sidr] draft-ietf-sidr-repos-struct to Standards Track
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: Sat, 23 Jul 2011 20:06:52 -0000

----- Original Message -----
From: "Stephen Kent" <kent@bbn.com>
To: "t.petch" <ietfc@btconnect.com>
Cc: "Terry Manderson" <terry.manderson@icann.org>; "Rob Austein" <sra@isc.org>;
<draft-ietf-sidr-repos-struct@tools.ietf.org>; <sidr-chairs@tools.ietf.org>;
<sidr@ietf.org>
Sent: Saturday, July 23, 2011 3:37 PM
> >...
> >Given the distributed nature of the dynamic database that is RPKI, I
> >would have
> >thought a self identifying first line would be essential.
> >
> >Tom Petch
>
> Repository objects are not text files.  They are binary (CMS). Each
> object DOES begin with its context type (and OID).  So, in the binary
> space, we do just what you suggested. But, it is still very helpful
> to make use of filename extensions, e.g., to allow different types of
> RPs to filter what they retrieve.

Yes, I am well familiar with OIDs and their encoding and assume that
Terry is as well, so I was endorsing what I take to be his disquiet about only
using file extensions before assuming that there is an OID there and
presenting it to the validation regime on the assumption that there is one
to decode.

Tom Petch


>
> Steve