[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Changelog entries draft. Do not seem to find it.



LDUP/LCUP should include include enough functionality to achieve a client-side cache. For the other three issues you mention, maybe someone should author an audit draft.

Jim

>>> "James Benedict" <grunt@nortelnetworks.com> 3/2/00 6:38:35 AM >>>
Changelogs seem to be falling between the cracks (LDAP, LDUP, 
LCUP?).  The concept of changelogs is important to replication, but it also
has many other uses.

Accountability (Who did what? When?)
Problem Tracking (Why is my email address X)
Recovery (Whoops, I didn't really want to rename everyone in my directory)
Client-side caching (Give me all the changes to a subtree)

If LDUP is going to subsume the role of maintaining changes for replication
purposes, then I think it is important to make sure that mechanisms are 
in place to deal with these other uses as well.  Otherwise, I think
changelogs should become part of the LDAP standard, not just informational.

It doesn't really matter how the directory server maintains this
information, but clients need to have a consistent way of accessing it.

James A Benedict
Advisor, IP Directory Systems Architecture
Preside Policy Services
NORTEL NETWORKS
Ph:  (613) 763-3909


> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
> Sent: Wednesday, March 01, 2000 1:30 PM
> To: ggood@netscape.com 
> Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R;
> ietf-ldup@imc.org 
> Subject: Re: Changelog entries draft. Do not seem to find it.
> 
> 
> At 10:04 AM 3/1/00 -0800, Gordon Good wrote:
> >While I'm happy to resurrect the changelog draft and discuss 
> publishing it as a standards-track document (informational,
> >probably), it's not going to be a part of  the LDUP specification.
> 
> I would support publication of the Changelog draft as an
> Informational RFC as it would document existing practices.
> The document would have to be amended, of course, to contain
> appropriate statements concerning IETF work in this area.
> 
> Kurt
>