ldup@conference.ietf.jabber.com - 2002/11/20
[08:50] %% MarkSmith has arrived.
[08:51] <MarkSmith> We are here.
[08:51] <MarkSmith> Bye
[08:51] %% MarkSmith has left.
[08:51] %% MarkSmith has arrived.
[08:51] %% MarkSmith has left.
[10:48] %% capple has arrived.
[10:49] %% richm31415 has arrived.
[10:49] <richm31415> Excellent
[10:49] <capple> there've been positive comments about how this is working out so far
[10:49] <capple> hopefully it'll work out well for us also
[10:51] <richm31415> There is no web site for http://atlanta.ietf.org - are the presentations going to be on a different site?
[10:52] <capple> strange
[10:53] <capple> there's no blue signup sheet in the room either
[10:53] <capple> I just posted the presentation I'll use towards the end of the meeting to the LDUP mailing list
[10:53] <richm31415> Ok. I guess other folks can do the same.
[10:58] %% leg has arrived.
[11:10] %% rjs3 has arrived.
[11:11] <capple> we're getting started
[11:14] <capple> went through basic status
[11:14] <capple> no changes to agenda so far
[11:14] %% richm31415 has left.
[11:14] %% edwardsereed has arrived.
[11:14] <capple> Kurt is speaking about eventual convergence for LCUP
[11:14] <capple> present proposal doesn't ensure that the client's copy of data converges with the server's copy
[11:15] <capple> mailing list concensus is a fairly strong requirement for LCUP around eventual convergence exists
[11:15] %% richm31415 has arrived.
[11:15] <capple> a draft was written explaining the problem
[11:16] %% kmurchison has arrived.
[11:16] <capple> have a couple of approaches
[11:16] <capple> one that isn't very chatty but isn't all that good at providing eventual convergence
[11:16] <capple> one that is very chatty, but is better at the same
[11:17] <capple> conclusion was that we really need a protocol that is not overly chatty but still provides reasonable guarantees of eventual convergence
[11:17] <richm31415> I have reviewed Kurt's proposal. Perhaps he can elaborate, but the only convergence mechanism he proposed that is missing from the existing LCUP document is:
[11:18] <richm31415> When doing a refresh, return every entry - _even if no changes to that entry have been made_.
[11:18] <richm31415> This seems very expensive if the DIT is large. For example, I want to do a refresh and I present the server my cookie.
[11:18] <capple> Kurt's says that's indeed the change - but that it is a very chatty change
[11:19] <capple> and that this is his concern
[11:19] <richm31415> Only 1 entry has changed since my last refresh, and the DIT contains 100k entries.
[11:19] <richm31415> So, I get back 1 "real" change notification, and 99999 "empty" no change notifications.
[11:20] <richm31415> In that case, the server might as well return "reload required" and force the client to resync - it's almost the same.
[11:21] <richm31415> Perhaps LCUP could specify another option for the client - the client may request that unchanged entries be returned as part of the synchronization phase.
[11:21] <edwardsereed> yeah, but it's not bad if done occasionally - clearinghouse scheduled a "chatty" database comparison exchange
[11:22] %% ietfwatch has arrived.
[11:22] <edwardsereed> once a day, you provide a record for every entry - with whatever is useful - last change timestamp, checksum, name
[11:22] <richm31415> Then clients (such as Kurt's) could request that "changes only" be returned or return unchanged entries as well.
[11:22] <edwardsereed> right
[11:22] <richm31415> If you are going to do it occassionally, why not just do a full sync? Isn't it the same?
[11:23] <capple> Kurt indicates that your comment is accurate
[11:23] <capple> Kurt is suggesting that we want to have early implementations and that he and John are trying to do
[11:23] <capple> just that
[11:23] <edwardsereed> not necessarily - you can compress it to a name and a signature, not the whole entry...
[11:24] <richm31415> Right. If the entries are large, you could save some time and bandwidth. But if the entries are small, not much savings there.
[11:24] <edwardsereed> true - so do what makes sense
[11:24] <richm31415> So, that being said, wouldn't it just be easier for the client to tell the server if it wants the unchanged entries as part of the LCUP protocol?
[11:25] <edwardsereed> probably
[11:25] <edwardsereed> this is basically a database comparison operation...what Xerox called "antientropy"
[11:26] <richm31415> For clients like the one's Kurt is proposing (LDAP proxy cache, mail server cache) it makes sense to return unchanged entries, but for small PDA like clients it doesn't. I would rather not lock out a whole category of clients from using this protocol.
[11:26] <capple> Kurt indicated that he's been in touch with the LCUP authors and they are working together hard to resolve the issue
[11:26] <richm31415> Yes.
[11:26] <capple> Mark Wahl suggested that he'd like to see a revision resolving the issue by the next meeting - I agree
[11:26] <capple> is that feasible?
[11:27] <richm31415> I don't see why not.
[11:27] <edwardsereed> and their criteria was "statistical probability of convergence" because theirs was server-to-server where once a day each server randomly selected one other server with which to compare its database values
[11:27] <richm31415> Kurt's other changes are: UUID is required, but not an attribute - part of control value only.
[11:27] <capple> so now - lets move on to the next agenda item - we can discuss the LCUP eventual convergence on the mailing list
[11:28] <richm31415> OK.
[11:29] <capple> going through teh charts now
[11:31] <edwardsereed>
[11:32] <capple> went through general deliverables status
[11:33] <capple> have to verify John McMeeking's willingness to continue editing protocol spec
[11:33] <capple> goiing through co-chair's proposal
[11:34] %% roland has arrived.
[11:35] <capple> consider moving usage profile to informational
[11:37] %% leifj has arrived.
[11:38] <capple> comment on second slide from co-chair's proposal
[11:38] <capple> Kurt Z clarifying the role of the LDAP Directorate
[11:39] <capple> review and comment from them should have no special weight - only recommendations to the ADs
[11:43] <capple> Ed Reed feels that the target of June 2003 isn't realistic
[11:44] <capple> largely his concern is based on the issues which have caused delay to date around an administrative model and access control
[11:44] <edwardsereed> We havent' been able to agree to date, what's changed that would make it possible, now?
[11:49] <capple> Ed is concerned that not many folks have an internally consistent view of what LDUP really means
[11:51] <capple> and that it is going to be very difficult to get there by resolving inconsistencies between documents that have been on relatively independent editorial paths for a couple of years
[11:51] <capple> a suggestion from Mark Wahl is to allow authors of documents to work out inconsistencies in the documents as individual contributions rather than WG products
[11:52] <capple> polling the room for additonal comments
[11:54] <capple> Kurt Z suggests that if the WG agrees that its not going to agree on issues that we need to resolve
[11:54] <capple> that this should be a reason for concluding without publishing documents
[11:56] %% rlbob has arrived.
[11:56] <capple> and that a more appropriate way of working might be to remove the deliverables from the charter and allow authors to proceed with resolving issues outside of a WG
[11:56] <capple> any comments or suggestions from folks not in Atlanta?
[11:58] %% ietfwatch has left.
[11:59] %% edwardsereed has left.
[11:59] <capple> we're done
[11:59] %% rlbob has left.
[11:59] %% capple has left.
[12:00] %% rlbob has arrived.
[12:00] %% richm31415 has left.
[12:00] %% rjs3 has left.
[12:00] %% rlbob has left.
[12:03] %% kmurchison has left.
[12:06] %% leifj has left.
[12:07] %% roland has left.
[12:10] %% MarkSmith has arrived.
[12:11] %% MarkSmith has left.
[12:11] %% jmcmeeking has arrived.
[12:12] %% jmcmeeking has left.
[12:12] %% leg has left.
[12:19] %% john loughney has arrived.
[12:20] %% john loughney has left.
[12:30] %% mrose has arrived.
[12:33] %% jm has arrived.
[12:39] %% jm has left.
[12:56] %% mrose has left.