LDUP Meeting Minutes for the 47th Meeting of the IETF Minutes recorded by John Strassner First and most importantly, humble thanks to all working group participants (which was the overwhelming majority) that stayed over 20 minutes late in order to finish our agenda. The agenda was discussed. We inserted one change to the agenda, the discussion of an alternate proposal to the URP draft. This alternative was presented to the group at the start of the meeting, and the agenda was changed to accommodate it due to its potential ramifications if the working group accepts the work. The revised agenda is below (note that all file names should be prefixed with http://www.ietf.org/internet-drafts): 1) Agenda Bashing 2) Brief Discussion of Alternate URP Proposal (This is the new item) 3) General Admonishment for Authors Being Late ;-) 4) LDAP Replication Architecture file: draft-ietf-ldup-model-02.txt 5) LDAP V3 Replication Requirements file: draft-ietf-ldup-replica-req-02.txt 6) LDUP Replication Information Model file: draft-ietf-ldup-infomod-00.txt 7) LDUP Update Reconciliation Procedures file: draft-ietf-ldup-urp-02.txt 8) LDAP Subentry Schema file: draft-ietf-ldup-subentry-01.txt 9) The LDUP Replication Update Protocol file: draft-ietf-ldup-protocol-00.txt 10) Drafts that are Missing In Action: LDAPv3 Mandatory Replica Management I-D LDAPv3 Master-Slave Replication Profile I_D LDAPv3 Multi-Master Replication Profile I-D 11) Discussion of addition of LBURP to the Charter 12) Discussion of addition of LCUP Work to the Charter 1. Discussion of Agenda Items (John Strassner) The agenda was discussed. A new item was added: discussion of a new alternate URP proposal and its effects on the requirements document. The rest of the agenda remained unchanged. 2. Brief Discussion of an alternate URP Proposal (moderated by John) This item came up because the LDUP Replication Requirement Document completed WG last call, and actually should have gone to IETF Last Call. We had decided to put this document to IETF Last Call at the meeting. However, there was one major objection raised by Mr. Langer. He was concerned that the requirements are too open and subject to interpretation in one specific area (atomicity of updates), and that his alternative method for update resolution would therefore be ruled out. It was decided to do the following: - since nothing can be formally considered by the working group until it is in the form of an Internet Draft, we decided to wait one week (till 7 April) to allow Mr. Langer to publish his URP alternate approach as an individual submission - in addition, Mr. Langer should write a brief e-mail that explicitly defines the problem with the requirement doc. Note that this does NOT mean that Mr. Langer has to redo and/or present an alternate requirements draft. Once these two steps have been completed, the working group will discuss the points on the mailing list. We would like to decide by the end of the month at the latest whether to go forward with the existing requirements draft and URP proposal, or to delay these while we adjust the requirements document and then either add Mr. Langer’s URP document, or to replace our existing document with that of Mr. Langer. 3. General Admonishment ;-) (John) Your co-chairs are concerned that we're showing the signs of starting to die a flailing death. So, if this work is important for your LDAP implementations, please redouble your efforts to move these drafts along. Your co-chairs are here to help and facilitate this. We will be collecting expected times of updating the drafts today, so that we can update our charter. Working groups have, can, and will be killed for lack of activity, so please try and keep these new sets of dates. 4) LDAP Replication Architecture (Uppilli) file: draft-ietf-ldup-model-02.txt (Intro from John) This draft completed working group last call. The lone item to fix was a removal of references to other WG deliverables (per joint recommendation of the WG Chairs and the Applications Area Directors). This is because this document, being an architecture document, is supposed to stand on its own and not be held up waiting for other deliverables to clear IESG Review, IETF Last Call, and the RFC Editor. (Uppilli) The current status is that the above changes were made and the document was resubmitted. The authors tried to decouple references, but in their opinion additional work needs to be done to ensure that those documents are tightly coupled to this architecture document. In addition, Helmut pointed out that there are some errors with respect to naming contexts. He also pointed out that since some things operate fundamentally differently in a multi-master environment, this should be pointed out and affect the architecture document. A brief call for input was taken, and other people are willing to add requirements. Plus, the other architecture authors should also contribute. It was decided to solicit general comments up to 24 April, and then reissue this document in mid-May. 5) LDAP V3 Replication Requirements (Ellen) file: draft-ietf-ldup-replica-req-02.txt This document also successfully completed working group last call, but has not yet been sent to an IETF last call. And now, we have an objection from Mr. Langer. The basic problem is that Mr. Langer wants to offer up an alternate replication method, one that is different from URP. He is worried that the replication requirements draft, in its current form, would prohibit his document from being considered. This is because, in his view, the document is ambiguous. The ambiguity lies in the fact that although transactions are beyond the scope of the current work, nothing will be done to add in transactions. In addition, the term atomic update as implemented in a single master means that you were reading just that entry, and that no interleaved operations carried out. The replication requirements document (in its present form) allows interleaving of operations, in anticipation of multi-master operation. Recommendation of the chair and AD: Until an Internet draft is an RFC there is always time to discuss things. However, it is not fruitful to discuss anything until a formal counter-proposal, in the form of an Internet Draft, is submitted (as an individual submission) for consideration by the working group. Thus, it is incumbent on Mr. Langer to produce such an Internet Draft. Once this new draft is submitted, the working group will consider it. The first order of business is for the replication requirements team and authors to respond on the mail list, and then for the working group to consider whether Mr. Langer’s concerns are justified. If they are, then the requirements draft will have to be modified to take this into account, and another working group last call issued. If not, then the requirements draft will go to IETF last call either as is, or with a small editorial modification that further clarifies the requirements draft in response to Mr. Langer’s objections. The working group will make a decision by Easter. Note that this is independent of the URP decision. 6) LDUP Replication Information Model (Ed) file: draft-ietf-ldup-infomod-00.txt (Chair intro): This was supposed to go through WG Last Call a while ago. However, it is doubtful that it is ready to go in its current form. (Ed): The Engineering Team met and is simplifying this draft even more. The UUID spec was a dangling reference, but the working group decided (thanks Harald for chipping in here) that we can use the UUID ISO spec. The reference for this spec is: http://www.opengroup.org/onlinepubs/009629399/apdxa.htm Ed notes that the process of trying to describe scheduled policy is really hard. We can start to do this by perhaps defining a cron-like process with hysteriesis. However, it isn’t clear that this is suitable for all applications. In fact, the Engineering Team is favoring leaving this undefined. If we do this, then there are two classes and a lot of attributes that don’t need to be specified in this document. The current proposal is to define a (may) DN attribute that may point to a scheduler class. When absent, the default is to send the replication immediately. ( please refer to the subsequent exchange between Harald and Ed regarding particulars of this. Ed points out that the Engineering team are actively trying to avoid the cron(1) directory schema (or at least punt to a separate document). Ed's proposal is thus: scheduling policy information MAY be described in published schema and be referenced by replicationAgreementSubentries governed by entries (or groups of entries) using such schema descriptions, but such schema descriptions are outside the scope of LDUP, and will generally be implementation specific until concensus develops on what constitutes good schema design for them. LDUPers, please comment on the list. ) In Washington, we decided to eliminate ldapAccessPoint in favor of replicaURI. We moved the replicaID translation table to the protocol spec. This is one of the things that we need to ensure is updated in all of the appropriate draft. The current draft is defined so that the replication agreement subentries use name subordination to define whose replica this is. This brought up a discussion on which naming attributes to use. Here is a summary: Mark notes that some vendors have objected to using cn for naming ldapSubEntry entries in the directory. The primary objection is that these entries are not normally visible to users and administrators. Thus, you get the rather ugly problem that naming clashes with other entries named by cn will occur, and the administrator or user won’t have a clue as to why this is happening. In addition, many ldapSubEntry entries will be created automatically by software. If this is to succeed, then we must guarantee that name clashes are avoided. The group defined the following possible solutions: 1) define a new attribute (name TBD) of type DirectoryString, for exclusive use of naming ldapSubEntry entries 2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information, but this seems to have problems because the ldapSubEntry class is a structural class and therefore probably requires a specific naming rule that will end up interfering with user definitions 3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators. 4) keep cn as the naming attribute but recommend a specific convention for naming subentries that makes a name clash unlikely. A brief summary of the opinions of the group is: 1) Option 1 moves this farther away from the X.500 definition, which is OK if that is really what we want to do. However, it doesn’t seem that we should change just for the sake of changing. So if someone really wants this option, it is incumbent on them to come up with a compelling reason (last sentence from Editor). 2) Option 2 seems an even further departure from X.500, and seems to be recommending that ldapSubEntry be an AUXILIARY, not a STRUCTURAL, class. 3) Option 3 seems to be a safe decision. If people can’t come up with compelling scenarios, then there is no need to change. 4) This option seems next most feasible, though there is some concern as to how the naming convention can be specified so as to always avoid collisions. 7) LDUP Update Reconciliation Procedures (Steven) file: draft-ietf-ldup-urp-02.txt This draft did seem ready for last call, but now we may need to reconsider it given Mr. Langer’s alternate proposal. The authors are looking at making a future revision to accommodate the updating of partial replicas. Steven and Alison point out that the main difference between URP and other approaches is whether conflicts are merged or resolved immediately. Steven and Alison also note that this subject keeps coming up. Therefore, Steven and Alison have volunteered to write up a new document that describes why URP ended up the way it did. The working group members that that this was a good idea, and Patrick OKed it. Chairs to revise the charter and send to list. 8 LDAP Subentry Schema (Ed) file: draft-ietf-ldup-subentry-01.txt This document is ready for last call, but LDAPEXT wants additional information and guidance stating that auxiliary classes should be used wherever possible instead of structural classes (editor’s note: remember that this document is going through a joint last call between the LDUP and LDAPEXT working groups). When that is revised, this doc should be ready for last call. However, the naming problem discussed above rears its ugly head here too. So if we change the naming convention, then we need to update this document. So at the very least we need some weasel words to allow this. Conclusion: this last issue needs to be taken to the list. Ed to write mail message, everyone please respond and help, else we will use X.500’s definition. Target date for new publication: end of May 9) The LDUP Replication Update Protocol file: draft-ietf-ldup-protocol-00.txt and file: draft-ietf-ldup-framing-00.txt The main change since the last issue of this draft is to split the ldup-protocol-00.txt draft into 2 drafts: Ldup-protocol-01.txt and ldup-framing-00.txt The framing draft defines four framing operations: start framed protocol request and response, and end framed protocol request and response. This is intended to group together a set of related operations. For example, in URP, there would be a series of URP actions. Note that a session is defined as Start framed protocol request contains a protocol OID and a protocol-specific payload. LBURP, for example, specifies this protocol OID and specifies the payload format. Framing does not address push or pull models that are a function of the protocol implementation. Open questions: - Does protocol-01.txt enumerate all necessary error conditions (probably not) - Anything else? (replica ID translation table, advertisement) A general question was raised as to why the framing document is necessary (i.e., why not just use an extended response)? The concern is that you might need more semantics than just a Start doing something, and then tell me when you’re done. Also, there is concern that since we only have 2 customers, we might not get it right. Conclusion: take this to the list. Discussion period should go no later than middle of May. Then, we need a damage assessment, and to decide if we merge the drafts back into one, or keep them separate. 10) Drafts that are missing in action 10a) LDAPv3 Mandatory Replica Management I-D (Mark) The LDAPv3 Mandatory Replica Management I-D is being turned over to Ed Reed because Mark has negative cycles ;-) . Ed's target date for revising this document is the end of June (to ensure time to finish the other important work that he is already committed to). 10b) LDAPv3 Master-Slave Replication Profile I-D (Uppilli/Ed) These documents will be combined into one, with Uppilli taking the lead. Solicited and received help to fill out some of the sections. New time frame is the end of June to release this document. 10c) LDAPv3 Multi-Master Replication Profile I-D (Uppilli/Ed) This draft has stagnated somewhat because it is still unclear how applications will make use of this information. The original motivation of this draft was to be able to answer questions on configuration, and guide the implementor in making decisions that support the configuration of the directory server to single or multi-master replication. After some discussion, we decided that this should be tied closely to the requirements document, and to have use cases drive their functionality. Also, we should talk about who should use single- vs. multi-master replication, and how the inherent differences between these two modes affect the applications that use them. Uppilli needs more input as to what type of applications would use this and how this could break an application. Alison will help, as will the co-chairs. Purpose: see what types of operations are different between single- and multi-master. This will be written as one document, not two. Time frame: end of June. 11) Discuss LBURP (Roger) The latest version of this draft include using the LDUP Framing draft, removing LDUPisms (e.g. replica update vectors), adding sequencing (to help implementation we need to determine which updates were sent in what order), and adding grouping of updates (for better wire efficiency, especially on responses) Remaining questions: Need to tighten error handling procedures (what happens if an error occurs in the middle of a set of operations). Also need to consider how much parallelism is desired between LDUP and LBURP. Should this be added as a WG item? Unclear right now. Roger to revise it again and we will ask again on or before the next IETF meeting. 12) Discuss addition of LCUP to charter (Olga) The purpose of LCUP is to synchronize LDAP clients with content stored by LDAP servers. As such, there are three main problem areas that are addressed: (1) mobile clients that maintain local data caches, (2) meta-directory applications, and (3) event triggers (both triggered as well as persistent search). Problem areas that are not addressed include server to server synchronization (addressed by LDUP). LCUP combines features of DirSync, Persistent search and Triggered search. Its motivation is that the ideal solution needs parts of each of these solutions. So, LCUP is intended to replace persistent and triggered search. DirSync has a number of desirable features that are included in LCUP for convenience sake, but LCUP does not have all of the functionality of DirSync. The protocol supports one-way synchronization only. Server does not maintain any state info on behalf of the clients. Clients maintain the state information passed to them by the server in a cookie. A key point is that LCUP does not support pre-defined agreements. Rather, it is up to the client to decide from which server and when to get the information. Thus, the client always initiates the synchronization session, and the client is always responsible for pulling data from the server that it selects. The specific protocol elements proposed include four extended operations: a client update control, an entry update control, a client update done control, and a stop client update. There are three basic ways of using LCUP: event triggering, non-persistent, and persistent synchronization. Please see the draft for more specific information. There are a number of features under discussion. These are features that have been proposed in one or more of the persistent search, triggered search, and dirSync proposals, but which are not currently implemented in LCUP. The reason is that each of these are very difficult to implement, and so we are trying to avoid implementing these unless there is an important need for these. They are as follows: Persistent search defines a change type. This is defined in persistent search. It defines a reason for return to each entry sent to the client. Hard to implement for historical reasons. Sending changes: present in DirSync; only modified attributes (as opposed to all attributes) are sent. Size limit: present in DirSync; specifying amount of data that can be sent to the client. LCUP prefers to use a standard LDAP mechanism instead. Data ordering: present in DirSync; guarantees that parent is sent before child for adds and vice-versa for deletes. Very hard to implement, may not catch all problems (e.g., DN pointers). LCUP is scoped by a single LDUP replica. One thing that needs better definition is access control (e.g., if access control changes, how does that affect the client?). Note that a number of items are currently unspecified, such as: - Access control enforcement on the data - How to restrict the use of the protocol to trusted clients - Mechanism to identify and disconnect malicious clients - Server behavior is not specified for the case where data visibility changes due to access control changes - Proper behavior is not guaranteed if access control on the data is changed from a more restrictive to a less restrictive one Disposition? Mark would like to see this be done in LDUP, but is willing to accept it as a formal work item if this working group doesn’t want to accept it. Poll of the room showed overwhelming majority in favor of accepting this. Chairs to describe this work in new charter, which is to be discussed in the list.