Subject: Re: [APPS-REVIEW] Advising SIDR
From: Dave Cridland <[email-masked]>
To: Applications Review List <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>
Date: Fri, 04 Jan 2008 09:30:32 +0000
List-Id: Applications Review List <apps-review.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:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Date: Thu, 3 Jan 2008 15:47:28 -0800
Cc: 
Subject: [APPS-REVIEW] Advising SIDR

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review