Apologies for awakening an old thread, I was on holidays.
There is something that I am stuck on, and since I am in the same
physical location as two of the authors, I have been able to beat on
their door for a discussion. Apologies for not raising it directly on
the SIDR list.
The following is a transposition of a discussion that which fairly
accurately describes my concerns relating to Joe's comment and Rob's
reply.
I am concerned with the current draft's reliance on RSYNC as a base
line (read required) protocol for transport of the certificate
information and the CRL.
I'm not that concerned with the specific protocol, ie RSYNC vs
HTTP/HTTPS vs something else. I am predominately concerned with an
aspect of "lock-in" that will bind operators to running that mandated
service/protocol even _IF_ the protocol selected is found to be wanting
in areas of scale, security, and integrity.
My initial feel for this document suggested two options.
1) change the wording of MUST to SHOULD in stating the protocol.
or
2) Have the URI protocol defined in another draft that could be more
easily changed in IETF process that modifying a RFC that would become
certificate profile/policy.
Cheers
Terry
On 06/10/2006, at 8:01 PM, Robert Loomans wrote:
Joe Abley wrote:
In section 3.9.5, why is an rsync URI preferred over any other kind
of URI? There's no normative language surrounding the stated
preference. Is a preference lacking normative teeth worth mentioning?
If so, might it be an idea to indicate that other URIs MAY be used
instead?
In section 3.9.6 and 3.9.7 the rsync URI is specified again, this
time as a MUST with a note that other URIs MAY be used. While I'm
still interested in why the rsync URI is a MUST, the language and the
associated MAY make these sections clearer than 3.9.5.
There are two issues here:
1) We want *all* certificates, CRLs, etc to be available and accessible
by only having to implement one protocol. Alternative protocols are
fine, but one protocol is mandatory. This will aid in interoperability.
2) We want a protocol with properties that include fetching complete
trees of objects/files, and, if you already have an old tree, just the
changes. We could implement this in any transport, but RSYNC does this
for free.
--
Terry Manderson email: [EMAIL PROTECTED]
Network Operations Manager, APNIC sip: [EMAIL PROTECTED]
http://www.apnic.net phone: +61 7 3858 3100
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
