Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAitG-0002Up-PC; Fri, 04 Jan 2008 04:30:58 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1JAitF-0002Uj-7L for apps-review-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 04:30:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAit8-0002TP-TE for apps-review@ietf.org; Fri, 04 Jan 2008 04:30:50 -0500 Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAit6-00033j-BT for apps-review@ietf.org; Fri, 04 Jan 2008 04:30:50 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Fri, 4 Jan 2008 09:30:34 +0000 Subject: Re: [APPS-REVIEW] Advising SIDR References: <23BDB414-4748-4525-8972-2373890F9798@osafoundation.org> In-Reply-To: <23BDB414-4748-4525-8972-2373890F9798@osafoundation.org> MIME-Version: 1.0 Message-Id: <23862.1199439032.397252@peirce.dave.cridland.net> Date: Fri, 04 Jan 2008 09:30:32 +0000 From: Dave Cridland To: Applications Review List Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Kurt Zeilenga X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org On Thu Jan 3 23:47:28 2008, Lisa Dusseault wrote: > I'm worried that RSync will be very problematic for them to > reference as a mandatory-to-implement access protocol that ensures > interoperability between vendors; it's not documented anywhere > stable. > > Agreed, although it does make sense as a working prototype. > I can see a whole number of options for their access protocol. > Possibly FTP (depending on how much information is in detailed file > listings), WebDAV to list file change dates, HTTP with some > requirements about directory listings (ick), RFC 3229 (Delta > fetching in HTTP) in conjunction with either of the previous, a > new manifest file format, adapting Atom to be a manifest file > format. ACAP anyone? XCAP? ok, let's not go crazy. > > I know someone, somewhere, is expecting me to bite here, but ACAP isn't suitable in this instance, from what I can gather. You'd want schema validation, and the essential rule of thumb about ACAP doesn't apply - ACAP is for information where you can state "This is my [whatever]", whereas a directory protocol is more suited to statements of the form "This is the One True, Official [whatever]". > Is there anybody who would like to help advise this WG on the > various standard technologies available? I hinted that a directory-like protocol might be best here. LDAP or X.500 would be particularly interesting, and it looks to my slightly glazed morning eyes like they're using ASN.1 anyway, so using LDAP wouldn't be such a stretch. Kurt Zeilenga would be a good person to ask about this, hence the CC. I have vague thoughts that signed operations and replication would be useful here, and I'm under the impression these are X.500 toys, rather than LDAP. I think one required operation will be "I got this BGP announcement, is it valid?", which'd allow the BGP host to be distinct from the repository. If you're an ISP with a few hundred BGP routers, I think it may make sense. Mind you, BGP hosts can, of course, be distinct from the router itself, too, and I don't think anyone's done that either. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAZmk-0001Wf-BA; Thu, 03 Jan 2008 18:47:38 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1JAZmi-0001VM-Dx for apps-review-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 18:47:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAZmh-0001VE-GA for APPS-REVIEW@ietf.org; Thu, 03 Jan 2008 18:47:35 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAZmg-0007nR-RS for APPS-REVIEW@ietf.org; Thu, 03 Jan 2008 18:47:35 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 52C27142217 for ; Thu, 3 Jan 2008 15:47:36 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYGsBi80cgUE for ; Thu, 3 Jan 2008 15:47:32 -0800 (PST) Received: from [10.1.1.107] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BF184142213 for ; Thu, 3 Jan 2008 15:47:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <23BDB414-4748-4525-8972-2373890F9798@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: APPS-REVIEW@ietf.org From: Lisa Dusseault Date: Thu, 3 Jan 2008 15:47:28 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [APPS-REVIEW] Advising SIDR X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org The SIDR WG (http://www.ietf.org/html.charters/sidr-charter.html) is planning on choosing an access protocol for semi-permanent routing information in a repository. From http://tools.ietf.org/html/draft-ietf-sidr-arch-02: > 4.3. Access protocols > > > Repository operators will choose one or more access protocols that > relying parties can use to access the repository system. These > protocols will be used by numerous participants in the > infrastructure > (e.g., all registries, ISPs, and multi-homed subscribers) to > maintain > their respective portions of it. In order to support these > activities, certain basic functionality is required of the suite of > access protocols, as described below. No single access protocol > need > implement all of these functions (although this may be the > case), but > each function must be implemented by at least one access protocol. > > Download: Access protocols MUST support the bulk download of > repository contents and subsequent download of changes to the > downloaded contents, since this will be the most common way in > which > relying parties interact with the repository system. Other > types of > download interactions (e.g., download of a single object) MAY > also be > supported. > > Upload/change/delete: Access protocols MUST also support mechanisms > for the issuers of certificates, CRLs, and other signed objects to > add them to the repository, and to remove them. Mechanisms for > modifying objects in the repository MAY also be provided. All > access > protocols that allow modification to the repository (through > addition, deletion, or modification of its contents) MUST support > verification of the authorization of the entity performing the > modification, so that appropriate access controls can be applied > (see > Section 4.4). > > Current efforts to implement a repository system use RSYNC [10] as > the single access protocol. RSYNC, as used in this implementation, > provides all of the above functionality. A document specifying the > conventions for use of RSYNC in the PKI will be prepared. I'm worried that RSync will be very problematic for them to reference as a mandatory-to-implement access protocol that ensures interoperability between vendors; it's not documented anywhere stable. I can see a whole number of options for their access protocol. Possibly FTP (depending on how much information is in detailed file listings), WebDAV to list file change dates, HTTP with some requirements about directory listings (ick), RFC 3229 (Delta fetching in HTTP) in conjunction with either of the previous, a new manifest file format, adapting Atom to be a manifest file format. ACAP anyone? XCAP? ok, let's not go crazy. Is there anybody who would like to help advise this WG on the various standard technologies available? Lisa _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review