Document: draft-zeilenga-ldup-sync-06.txt Trigger: IESG telechat 17 Feb 2005 Reviewer: Elwyn Davies AD: Ted Hardie Review Date: 16 Feb 2005 Intended status: Experimental Summary: I believe that the General Area AD should register a DISCUSS on this proposal on the grounds that it does not explain properly why it is sufficiently different from and/or technically superior to RFC3928 to merit support even as an experimental protocol. The proposal was pushed as an alternative to what has become RFC3928 during the ldup wg (up to 2003) but was rejected in favour of the alternative proposal. Much of this discussion appears to boil down to technical and philosophical disagreements about implementation details of how to maintain adequate state in the LDAP server to support synchronization operations for client caches rather than differences in the protocol to be employed to perform the sync operation. The actual protocols in RFC3928 and the draft have much in common: one major distinction seems to be that this draft offers a way of more compactly representing unchanged information and maybe reducing the volume of messages involved, but this needs to be brought out in the document in order to help make a decision. Review: After some ferreting in the archives, I see that this proposal represents an alternative solution to the problem of maintaining a copy of some part of an LDAP directory content in sync with a master. [I note that there seem to be a lot of proposals around for this operation.] This solution was rejected by the ldup working group in 2003 before the publication of RFC3928. There was extensive discussion and this represents a prime example of one the issues raised in the 'problem' working group: The authors of this draft believed rightly or wrongly that the solution being adopted was technically flawed and advocated this alternative persistently and repeatedly against what appears to have been consensus of the rest of the ldup wg up to the point where what was to become RFC3928 was sent to the IESG. It has now returned as an 'individual' draft for approval. Ted was closely involved in the later stages of these arguments and may be able to shed more light on the subtle (or not so subtle) distinctions between the proposal in this draft and RFC3928. http://www.imc.org/ietf-ldup/mail-archive/msg01782.html seems to summarize the disagreements which, dispassionately, appear to be about whether the protocols are able to support a range of engineering tradeoffs that may need to be made in the LDAP server to control the amount of history information needed. The following is an extract from this message (ex Ted): ============================= > The second example was intended to illustrate that history information > currently maintained in today's LDAP servers is not "sufficient > history" for LCUP purposes. > Basically, LCUP requires vendors to maintain "sufficient history" > (significantly more than servers currently maintain today for other > purposes) when in many use scenarios that history is ineffective in > reducing traffic. And in use scenarios where that history might be > effective, the protocol doesn't allow the server to fully take advantage > of that history (because it doesn't support entry change > deltas). is a good, short precis of your points. I do see an engineering disagreement here on how to balance increases in state for deployed servers vs. the value it presents. I don't see a show stopper, though, as the draft acknowledges the possibility that maintaining state will not be appropriate for all cases and provides other mechanisms for them. That those are sub-optimal from a consumption perspective is not exactly surprising, given the basic design. =================== As far as I can see (and this based on a very limited understanding of the two proposals), there is a great deal of commonality between the proposals as regards modes of operation and interaction with existing LDAP protocols. The major difference in the protocol appears to be that -zeilenga offers a scheme for a more compressed representation of updates. Much of the rest of the differences between the authors of this draft and the rest of the ldup wg appear to be buried in the implementation details of the history mechanism on LDAP servers which determines what information needs to be sent, and as such is probably orthogonal to the choice of protocol. I may be missing the point here, but it would be easier to understand why I should bother to try out this experimental proposal if there was actually an explicit comparison with the capabilities of RFC3928 in the draft. It would be also relevant to know if the authors' previous strictures on the implementability of RFC3928 have been borne out by actual practice - is anybody supporting RFC3928? If not, then is it because it is not actually a useful feature or is it because it is technically flawed? In either case, would this draft fix the problem? If RFC3928 appears to be in use and meeting user requirements then it is not clear to me that -zeilenga represents a sufficient increment in protocol functionality to merit IETF support, even as an experimental protocol: this is mainly because the comparisons are not brought out to make it possible to make a clear decision. I therefore suggest that the General Area AD register a DISCUSS and request that the comparison is addressed by the authors so that potential users and implementers can see what the purported advantages are before they delve into the details. Couple of editorial nits in passing: S1, 1st para: s/to met the content/to meet the content/ S2, 1st para: s/responses with zero/responds with zero/