From owner-ietf-ldup@mail.imc.org Wed Oct 2 04:14:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12223 for ; Wed, 2 Oct 2002 04:14:03 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9287Wo21727 for ietf-ldup-bks; Wed, 2 Oct 2002 01:07:32 -0700 (PDT) Received: from marsha.smtp.stsn.com (p228.n-sfpop03.stsn.com [199.107.154.228]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9287Uv21717 for ; Wed, 2 Oct 2002 01:07:31 -0700 (PDT) Received: from D7ST2111 ([10.5.95.119]) by marsha.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 1 Oct 2002 01:09:11 -0700 Reply-To: From: "Chris Apple" To: Subject: LCUP WG Last Call Issues Date: Wed, 2 Oct 2002 04:07:24 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000201c269ea$bdf4dc80$775f050a@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C269C9.36E33C80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 01 Oct 2002 08:09:12.0218 (UTC) FILETIME=[D37347A0:01C26921] Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C269C9.36E33C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Text file attached. The document editors should respond to the list with a date by which they believe they could incorporate comments for which concensus exists. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com ------=_NextPart_000_0003_01C269C9.36E33C80 Content-Type: text/plain; name="LCUP WG Last Call Issues.txt" Content-Disposition: attachment; filename="LCUP WG Last Call Issues.txt" Content-Transfer-Encoding: quoted-printable Issue Number: 1 Description: Complete LCUP Client Update is Problematic Summary: Concern was expressed over an LCUP Client that repeats an original request may find that the copy "synchronized" by LCUP has changed significantly. Concensus: The protocol basically needs not only to send a copy of all entries which are within scope which have significantly changed, but also send a list of UUIDs and CSNs of all the entries which have not changed. This would not only allows the client to determine the set of entries which have been deleted from the fragment, but also determine if an entry returned but not updated needs to be refreshed. In which case, it can request a copy of those entries which it believes need to be refreshed. This can be done out of band with a persist operation. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01511.html Issue Number: 2 Description: Persist Doesn't Support Eventual Convergence Summary: This issue was raised in the context of Issue #1. It basically states that the server should support eventual convergence of the client's information with equivalent information on the server. Concensus: The server needs to be required to generate the set of events necessary for eventual convergence of the client's copy of the DIT fragment. The spec currently only appears to support "lossy convergence." Relevant Postings: http://www.imc.org/ietf-ldup/mail-archive/msg01511.html http://www.imc.org/ietf-ldup/mail-archive/msg01594.html http://www.imc.org/ietf-ldup/mail-archive/msg01595.html http://www.imc.org/ietf-ldup/mail-archive/msg01596.html http://www.imc.org/ietf-ldup/mail-archive/msg01597.html Issue Number: 3 Description: Confusing Cookie/Scheme Text Summary: The document defines a cookie as representing client state, but it then says it may be sent initially (without value) to indicating the desired scheme. Concensus: The specification would be a lot clearer if the cookie/scheme were defined as: LCUPScheme ::=3D LDAPOID LCUPCookie ::=3D SEQUENCE { scheme LCUPScheme, value OCTET STRING } and request control was defined as: ClientUpdateControlValue ::=3D SEQUENCE { updateType ENUMERATED { synchronizeOnly (0), synchronizeAndPersist (1), persistOnly (2) }, sendCookieInterval INTEGER OPTIONAL, scheme LCUPScheme OPTIONAL, cookie LCUPCookie OPTIONAL } where scheme may only be specified on initial request to indicate desired scheme and cookie must be provided on subsequent requests. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01606.html Issue Number: 4 Description: Clarification of Cookie Specification Summary: Section 4.2 states: "The cookie value MUST be included except when a client has no stored state; i.e., when the client is requesting a full synchronization" Concensus: Clarification is needed as to which of the following this text refers to (or an indication that it refers to all of the following): + ClientUpdateControlValue + EntryUpdateControlValue + ClientUpdateDoneControlValue Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01506.html Issue Number: 5 Description: New Cookie w/No Entry Mechanism Summary: LCUP needs to provide a mechanism which allows the server to send, at any time, a new cookie to the client without requiring the server to send an entry. Concensus: This is useful in cases where the cookie the server previously sent is too old to be useful and a new cookie would allow more efficient resync if the session where to be unexpectedly dropped. In fact, the cookie may be so old to cause a full sync to occur when no changes would be necessary if the cookie were updated. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01518.html http://www.imc.org/ietf-ldup/mail-archive/msg01520.html http://www.imc.org/ietf-ldup/mail-archive/msg01521.html http://www.imc.org/ietf-ldup/mail-archive/msg01522.html http://www.imc.org/ietf-ldup/mail-archive/msg01524.html http://www.imc.org/ietf-ldup/mail-archive/msg01526.html http://www.imc.org/ietf-ldup/mail-archive/msg01532.html http://www.imc.org/ietf-ldup/mail-archive/msg01534.html Issue Number: 6 Description: UUID Syntax and Matching Rule Summary: The syntax of UUID is directory string, and moreover, the matching rule is case ignore match. It was suggested that this combination is overly limiting and that the syntax be changed to octet string. This is made even more apparent by the fact that this document leaves standardization of the value generation to a future specification. Concensus: First and foremost, UUID support needs to be mandatory. The protocol won't work otherwise. Instead of returning the UUID as an attribute value (which are subject to normal access controls), it should be returned within the control (which *should* be subject to some kind of access restrictions). This to avoid having to deal with no UUID as being a valid response to a CRITICAL update request. Instead, if the server is unwilling to provide the UUID, the CRITICAL request will fail. A specification of how the server represents UUIDs (and CSNs) in the directory should be standardized, but suggest this be done in a separate document... as, if UUIDs are passed in the control, LCUP doesn't depend on the particulars representation in the DIT. For the specifications of entryUUID (and entryCSN), using either octetString/octetStringMatch or UUID/UUIDMatch (where UUID was a constrained OCTET STRING with a string syntax). The later is preferable. There is no need to leave the string syntax up to future standardization. ISO/IEC 11578:1996 can be referenced. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01505.html http://www.imc.org/ietf-ldup/mail-archive/msg01508.html http://www.imc.org/ietf-ldup/mail-archive/msg01544.html http://www.imc.org/ietf-ldup/mail-archive/msg01510.html http://www.imc.org/ietf-ldup/mail-archive/msg01546.html http://www.imc.org/ietf-ldup/mail-archive/msg01552.html http://www.imc.org/ietf-ldup/mail-archive/msg01553.html http://www.imc.org/ietf-ldup/mail-archive/msg01555.html http://www.imc.org/ietf-ldup/mail-archive/msg01557.html http://www.imc.org/ietf-ldup/mail-archive/msg01558.html http://www.imc.org/ietf-ldup/mail-archive/msg01563.html http://www.imc.org/ietf-ldup/mail-archive/msg01567.html http://www.imc.org/ietf-ldup/mail-archive/msg01568.html Issue Number: 7 Description: Trigger Mechanism or Not? Summary: The draft states that it "is intended to allow LDAP clients to synchronize with the content stored by LDAP servers". but also states that it wants to solve the problem of triggered actions (Section 3, Bullet 3). Concensus: Most of the rest of the draft is consistent with the notion of synchronization, but tends to downplay support for triggered responses. Do we want this to be a useful event driver, or is the idea that we just preserve the easy stuff of what prior drafts could do? Specifically, the left-out items in Sections 5.1, 5.2, and 5.3 deter from the effectiveness of the "persist" mode. Curent users of Persistent Search rely on the notion of change types. Section 5.2 assumes that change types are used for partial replication, and thus discounts them as useful for LCUP. Triggered actions should be within LCUP's scope. The LCUP authors have tried to balance the server implementation burden with the client implementation burden. In particular, I would really like to=20 avoid creating an LCUP protocol that requires a server to store=20 client-specific state (that just won't scale when their are thousands or hundreds of thousands of clients). A related comment: section 5 should be moved to an appendix that=20 is named "Features Left Out of LCUP." It is not core to LCUP, but is=20 useful to provide historical context and rationale for why some things=20 are not included in LCUP. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01519.html http://www.imc.org/ietf-ldup/mail-archive/msg01554.html http://www.imc.org/ietf-ldup/mail-archive/msg01556.html http://www.imc.org/ietf-ldup/mail-archive/msg01562.html Issue Number: 8 Description: Alias Dereferencing Summary: The server instructions for alias deferencing are found in the Client Side Considerations section. Concensus: Specifically, it says that a server will respond with protocolError if any other than neverDerefAliases or derefFindingBaseObj is specified. This should be moved to, copied to, or referenced in a more = server-centric part of the draft. It should say "... the server MUST return = protocolError..." Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01516.html Issue Number: 9 Description: Laundry List Summary: This posting contains a copy of feedback provided to the document editors privately. Concensus: Some of the specific comments in the postings below have been discussed = and addressed as a part of other issues. Other comments are strictly = editorial in nature and should be incorporated. The document editors should raise comments otherwise classified to the mailing list and obtain = clarification from the WG members. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01514.html http://www.imc.org/ietf-ldup/mail-archive/msg01515.html http://www.imc.org/ietf-ldup/mail-archive/msg01517.html Issue Number: 10 Description: Search Filter and Returned Entries Summary: The draft states in Section 5.2 that "For LCUP, the intention is full synchronization, not partial.". Concensus: LCUP must support both partial (not necessarily all entries within scope) and fractional (not necessarily all attributes of each entry) synchronization. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01523.html http://www.imc.org/ietf-ldup/mail-archive/msg01530.html http://www.imc.org/ietf-ldup/mail-archive/msg01539.html Issue Number: 11 Description: Does entryDeleted break the protocol? Summary: The description for entryDeleted states at first that it indicates that the entry being returned has been deleted--then goes on to say that it also might indicate that the entry has left the result set. In the case of it being due to the entry has left the result set, we need to answer these: 1) If due to a rename, what DN is used (old or new) 2) If the entry is not in the result set, doesn't it break the LDAP protocol to return it (it doesn't match the filter)? Concensus: No change required. Clarification was provided on the mailing list. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01525.html http://www.imc.org/ietf-ldup/mail-archive/msg01545.html Issue Number: 12 Description: Is the EntryUpdateControlValue optional? Summary: First, is the EntryUpdateControlValue supposed to be returned during an initial synchronization session? Next, Section 4.8 states: "Each SearchResultEntry may have an entryUpdate control attached. ". This indicates that the control is optional. Is it? Concensus: No further discussion took place on the list on this topic. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01527.html Issue Number: 13 Description: What is "a while"? Summary: Section 4.8 states "it MUST wait for a while before attempting another synchronization session with the server. " Concensus: If we're going to use an imperative like MUST, we ought to not use vague language like "a while". I suggest we drop the MUST anyway--is there an interoperability issue here? The "MUST wait for a while" would be consistent with most other network algorithms. If it doesn't wait, it may cause unintentional denial of service attacks by swamping the server with connection requests.=20 Since LCUP is proposing persistent open TCP connections and the use of an error code for resources exhaustion, "acceptable" client behavior ought to be specified to help determine a "malicious" client. Since list comments imply that different use cases of LCUP require different back off periods, I'd think that having the server specify the initial backoff period in seconds with the lcupResorcesExhausted = error would be worth consideration. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01528.html http://www.imc.org/ietf-ldup/mail-archive/msg01547.html http://www.imc.org/ietf-ldup/mail-archive/msg01559.html http://www.imc.org/ietf-ldup/mail-archive/msg01569.html http://www.imc.org/ietf-ldup/mail-archive/msg01571.html Issue Number: 14 Description: note about syncing to different servers Summary: What does the "(Note that the client can synchronize with different servers during different synchronization sessions.) " mean in the context of the paragraph it's in? Concensus: No further discussion took place on the list on this topic. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01529.html Issue Number: 15 Description: Need for lcupReloadRequired Summary: Why is this error needed? It seems that if this scenario exists, the server would simply send the full set of entries, and a new cookie. The current specification indicates that the client would try to sync, receive an error, then try to sync again with an empty cookie. Is there a benefit to the extra step? Concensus: Yes, it tells the client to delete everything it has. Otherwise it might be left with entries which should be have been deleted but were not. Of course, given that LCUP doesn't ensure this doesn't happen under success resync is of concern. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01531.html http://www.imc.org/ietf-ldup/mail-archive/msg01535.html http://www.imc.org/ietf-ldup/mail-archive/msg01533.html Issue Number: 16 Description: sync, then sync and persist Summary: Why is there a suggestion in Section 6 to "perform an initial synchronization...(synchronizeOnly)" and then immediately perform a synchronizeAndPersist session? Why not just perform a synchronizeAndPersist session to begin with? Concensus: What's needed is a intermediate response PDU indicating the end of the synchronize phase and provide a new cookie. This not only works when there are no sync events, but also works when there are persist event occurring during synchronization. Calling it an "end of sync phase" marker doesn't prevent an overlapping "persist" phase. There should be no problem with allowing an overlapping "persist" phase (as the current I-D does) AS LONG AS it is clear to the client when it has a complete copy of the DIT fragment. Then, we can work on providing the client with a complete and accurate copy... Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01536.html http://www.imc.org/ietf-ldup/mail-archive/msg01541.html http://www.imc.org/ietf-ldup/mail-archive/msg01550.html http://www.imc.org/ietf-ldup/mail-archive/msg01551.html Issue Number: 17 Description: rename of baseObject (was something else) Summary: At 10:20 PM 2002-09-03, Jim Sermersheim wrote: >The scenario I was thinking of is one where the base existed when a >persistent LCUP session starts, but later is renamed or deleted. Concensus: Client Considerations implies noSuchObject is returned in this case. This needs to be detailed in Section 4 (along with many other protocol details found in sections 6 and 7). Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01538.html http://www.imc.org/ietf-ldup/mail-archive/msg01543.html http://www.imc.org/ietf-ldup/mail-archive/msg01548.html http://www.imc.org/ietf-ldup/mail-archive/msg01549.html Issue Number: 18 Description: subordinate references Summary: The document is quite unclear how references are to be handled. What happens when a named subordinate referral object [RFC 3296] within scope of the search is added, deleted, or modified? Concensus: One approach would be to return a searchResultReference with a control much like the EntryUpdateControl, but with the UUID of the referral object. Or one could just redefine (and rename) the EntryUpdateControl to include the UUID. Another approach would be require the presence of the ManageDsaIT control in the request. This, basically, requests that all referral objects be treated as entry objects. However, the problem with this, is that the ManageDsaIT control may be used to manage other kinds of knowledge information. It selects a management plane within the DsaIT. An LCUP with ManageDsaIT should be treated as a LCUP request within the management plane normally selected by the ManageDsaIt. Another option is to just to say the all referral objects are treated as entry objects when the LCUP control is present. There may be other options. A preference was expressed for something like the first approach (for add, and mod). And a comment was made that a "delete would just be a delete." Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01560.html http://www.imc.org/ietf-ldup/mail-archive/msg01564.html Issue Number: 19 Description: collective attributes, subentries, etc. Summary: Some statement should be made with how LCUP interacts with collective attributes appearing both in the filter and returned entries. The simple approach would be to say: 1) filter should not contain assertions upon collective attributes, 2) changes to an collective subentry will not cause entries within the collection to be "updated", 3) clients are interested in maintaining sync with collective attributes should include the collective subentry within an LCUP request. Which leads to another question: how does a client ask for update of both entry and subentry DSEs subordinate to the baseObject object? This is similar to the subordinate referral issue. One could generalize the question to: How does a client ask for update of all DSEs of a particular combination of DSE types subordinate to the baseObject? Concensus: No other discussion took place on the list on this topic. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01561.html Issue Number: 20 Description: operational attributes Summary: We need to state how updates to operational attributes (both stored and not stored) affect LCUP. Concensus: There are different classes of this: 1) A server internally increments a numSubordinates attribute on the parent of an entry being added or deleted (server responding to client action) 2) A server modifies replication-related information (server responding to bilateral processes) 3) A server updates the state of a transitional attribute (response to an internal, timed operation) 4) An entire set of operations like those above that affect the value of an operational attribute, but the value is generated dynamically, only when read by a client. 5) A client updates an operational attribute. We should also discuss any differences in behavior among the three different types of operational attribute (directoryOperation, distributedOperation, dSAOperation). Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01565.html http://www.imc.org/ietf-ldup/mail-archive/msg01572.html http://www.imc.org/ietf-ldup/mail-archive/msg01573.html http://www.imc.org/ietf-ldup/mail-archive/msg01574.html Issue Number: 21 Description: Changes to attributes not in attributes list Summary: When we implemented psearch, there was contention over whether or not the client should be updated when a modification is made to an attribute that was not requested by the client. Concensus: No other discussion occured on the list on this topic, however, in this case, silence seems to indicate the following intent. The case for NOT sending these entries is pretty strong. I'm not sure what arguments can be made for sending them. In either case, this needs to be spelled out in the draft. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01566.html Issue Number: 22 Description: Interaction with other controls? Summary: How does this control interact with other controls? How does this control interact with existing search controls? Paging? Sorting? Matched Values? Duplicate Entries? VLV? etc. Concensus: There was no further discussion about this topic on the list. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01570.html Issue Number: 23 Description: cookie schemes, why? Summary: The document doesn't adequately describe why cookie schemes are necessary... in particular, why would a client ever want to request a particular scheme? How would a client determine which schemes where supported by the server? And, if the server is allowed to support differ schemes in different subtrees, how would a client determine which schemes where supported in which subtrees.=20 The need to allow the client to request particular cookie schemes is being questioned after prior concensus was established on this topic. It was suggested that there if there is a need for this, then we need to make sure adequate discovery mechanisms are provided so that client can which schemes are supported where (yuk). Which is a topic that has been discussed during the WG meeting prior to the issuance of this WG Last Call. It was also suggested that if there is no reason, that no means be provided to allow a client to request a particular scheme. If later some need arises, LCUP can be extended. That extension would have to deal with scheme discovery issues. Concensus: From past discussions, the main purpose of the scheme was to facilitate protocol operations in replicated environments. That is, where the client resumes an LCUP session on a different server then that which provided the cookie, the scheme allows the server to determine the cookie format used by the other server. If the doesn't recognize the scheme, it can return an error (or a referral to the servers which do understand the scheme?). Concensus in the WG Meeting Prior to the issuance of this WG Last Call was that a cookie discovery mechanism was not needed. This was posted to the mailing list in the form of meeting minutes from that WG Meeting. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01607.html Issue Number: 24 Description: various LCUP issues Summary: A posting was made shortly prior to the end of the WG Last call period containing several comments/issues. Concensus: No further discussion took place on the list in response to this = posting. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01608.html Issue Number: 25 Description: LCUP Draft inline comments Summary: Many comments, some of which were editorial, are included in the posting associated with this issue. Concensus: Some of these issues were discussed separately and would be duplicates = of those above if documented seperately here. Some of them are editorial = and should be incorporated. Comments classified otherwise should be posted = to the mailing list by the document editors for further discussion. Relevant Posting(s): http://www.imc.org/ietf-ldup/mail-archive/msg01598.html ------=_NextPart_000_0003_01C269C9.36E33C80-- From owner-ietf-ldup@mail.imc.org Mon Oct 14 08:26:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16563 for ; Mon, 14 Oct 2002 08:26:27 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9ECD7F25039 for ietf-ldup-bks; Mon, 14 Oct 2002 05:13:07 -0700 (PDT) Received: from jubilee.esoterica.pt (jubilee.esoterica.pt [195.22.0.29]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9ECD5v25034 for ; Mon, 14 Oct 2002 05:13:05 -0700 (PDT) Received: from ptw206 (eol.esoterica.pt [195.22.0.215]) by jubilee.esoterica.pt (8.12.3/8.11.6) with SMTP id g9EC7Tjw025604 for ; Mon, 14 Oct 2002 13:07:29 +0100 From: "Hugo Tavares" To: Subject: Single-Master Failover Recovery and Automated Replication Date: Mon, 14 Oct 2002 13:13:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Greetings I'm doing some search before implementing the LDAP services and I've noticed that there is a big question in synchronizing the information after recovery from a master fail in a single-master environment. As it's written in section 5.2 of "General Usage Profile for LDAPv3 Replication": "If the broken master is returned to service as a slave, then the administrator must, external to LDUP, distribute and resolve whatever pending changes remained undistributed and unresolved from the time immediately before it was removed from service. If the broken master is returned as a new master, then care must be taken with its replacement master to ensure that all of its pending changes are distributed and resolved before it is returned to duty as a slave." For a failover recovery I will use the heartbeat protocol with linux-HA or the LVS software (I still don't know what to use), and this protocol seems to deal fine the services, since when the masters goes down the heartbeat puts the slave being the master for providing updates to the clients, but, when the master comes up the heartbeat puts everything like the original configuration, although the problem of synchronization stills. My questions are: Is there any protocol wich leads with this? (I don't think so) Do you have any perspectives for implementing an autometed system to lead with this? Thank you Hugo Tavares From owner-ietf-ldup@mail.imc.org Mon Oct 14 22:12:22 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08081 for ; Mon, 14 Oct 2002 22:12:21 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9F26VN22865 for ietf-ldup-bks; Mon, 14 Oct 2002 19:06:31 -0700 (PDT) Received: from fp.mirapoint.com (fp.mirapoint.com [63.107.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9F26TW22860 for ; Mon, 14 Oct 2002 19:06:29 -0700 (PDT) Received: from alpo.mirapoint.com (alpo.mirapoint.com [192.168.0.19]) by fp.mirapoint.com (Mirapoint Messaging Server MOS 3.2.1.6 FastPath) with ESMTP id AAI23134; Mon, 14 Oct 2002 18:48:50 -0700 (PDT) Received: from alpo.mirapoint.com (localhost.mirapoint.com [127.0.0.1]) by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.3.0.40) with ESMTP id AHU29142; Mon, 14 Oct 2002 19:06:25 -0700 (PDT) Message-Id: <200210150206.AHU29142@alpo.mirapoint.com> Received: from 192.168.1.27 by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.3.0.40) with HTTPS/1.1; Mon, 14 Oct 2002 19:06:25 -0700 Date: Mon, 14 Oct 2002 19:06:25 -0700 From: Zachary Amsden Subject: Re: Single-Master Failover Recovery and Automated Replication To: Hugo Tavares Cc: ietf-ldup@imc.org X-Mailer: Webmail Mirapoint Direct 3.3.0.40 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This a problem if the master doesn't use a full phase commit for each database operation - i.e replicate the change to all slaves before total commit. If this not the case, then the master can have a backlog of changes which have not yet been replicated to the slaves. If one of these slaves is upgraded to a master server, then converting the original master to a slave is problematic, since the old master has a list of changes which have not been committed to the new master. Basically, this is saying that in this case, administrative action is necessary to correct this problem. It is possible to automate this case. You have several choices of action at this point: 1) Roll back all changes from the old master which had not been replicated to the new master. Either transactional rollback or wipe-overwrite-sync of the database is required. 2) Merge changes from the old master into the new master, using conflict resolution, either automated or manual. 3) Merge changes from the new master into the old master, using conflict resolution, and return the old master to service, downgrading the new master. 4) Discard changes from the new master and return the old master to service. 5) Require manual administrative repair Each of these has various drawbacks - automated conflict resolution may not always be appropriate; implementing some of these is more difficult than others; many slaves may need to be reconfigured; some set of changes may be lost; manual repair may be tedious and prone to irregular human errors. You need to decide what tradeoffs are appropriate based on the application you are using. Since different applications may have different requirements in this area, any interoperable protocol for automated failover recovery should not preclude any of these choices. Designing a recovery protocol that encompasses all of these options is a rather large problem, which is probably why it hasn't been formalized yet (at least not in a public forum). In any case, you are going to need to extend the HA software and the LDAP servers to be intelligent enough to perform one of these actions. Zachary Amsden ---- Original message ---- >Date: Mon, 14 Oct 2002 13:13:34 +0100 >From: "Hugo Tavares" >Subject: Single-Master Failover Recovery and Automated Replication >To: > > >Greetings > >I'm doing some search before implementing the LDAP services and I've noticed >that there is a big question in synchronizing the information after recovery >from a master fail in a single-master environment. As it's written in >section 5.2 of "General Usage Profile for LDAPv3 Replication": > >"If the broken master is returned to service as a slave, > then the administrator must, external to LDUP, distribute and resolve > whatever pending changes remained undistributed and unresolved from the > time immediately before it was removed from service. If the broken > master is returned as a new master, then care must be taken with its > replacement master to ensure that all of its pending changes are > distributed and resolved before it is returned to duty as a slave." > >For a failover recovery I will use the heartbeat protocol with linux-HA or >the LVS software (I still don't know what to use), and this protocol seems >to deal fine the services, since >when the masters goes down the heartbeat puts the slave being the master for >providing updates to the clients, but, when the master comes up the >heartbeat puts everything like the original configuration, although the >problem of synchronization stills. > >My questions are: > Is there any protocol wich leads with this? (I don't think so) > Do you have any perspectives for implementing an autometed system to lead >with this? > > >Thank you > >Hugo Tavares > "A plague upon all your houses" - last words of Waldo Semon, inventor of vinyl From owner-ietf-ldup@mail.imc.org Mon Oct 14 22:57:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09105 for ; Mon, 14 Oct 2002 22:57:14 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9F2rnw24194 for ietf-ldup-bks; Mon, 14 Oct 2002 19:53:49 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9F2rlW24185 for ; Mon, 14 Oct 2002 19:53:47 -0700 (PDT) Received: from sleepycat.com ([12.234.103.164]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021015025332.LZMP24595.sccrmhc02.attbi.com@sleepycat.com>; Tue, 15 Oct 2002 02:53:32 +0000 Message-ID: <3DAB832C.9030809@sleepycat.com> Date: Mon, 14 Oct 2002 19:53:32 -0700 From: John Merrells User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Zachary Amsden CC: Hugo Tavares , ietf-ldup@imc.org Subject: Re: Single-Master Failover Recovery and Automated Replication References: <200210150206.AHU29142@alpo.mirapoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Zachary Amsden wrote: >Designing a >recovery protocol that encompasses all of these options is a rather large >problem, which is probably why it hasn't been formalized yet (at least not >in a public forum). > Well, I'd argue that multi-master is the solution to the single-master recovery problem... so a solution has been formalized in a public forum. John From owner-ietf-ldup@mail.imc.org Mon Oct 14 23:58:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09923 for ; Mon, 14 Oct 2002 23:58:33 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9F3r2c29771 for ietf-ldup-bks; Mon, 14 Oct 2002 20:53:02 -0700 (PDT) Received: from fp.mirapoint.com (fp.mirapoint.com [63.107.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9F3r1W29767 for ; Mon, 14 Oct 2002 20:53:01 -0700 (PDT) Received: from alpo.mirapoint.com (alpo.mirapoint.com [192.168.0.19]) by fp.mirapoint.com (Mirapoint Messaging Server MOS 3.2.1.6 FastPath) with ESMTP id AAI23279; Mon, 14 Oct 2002 20:35:22 -0700 (PDT) Received: from alpo.mirapoint.com (localhost.mirapoint.com [127.0.0.1]) by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.3.0.40) with ESMTP id AHU29253; Mon, 14 Oct 2002 20:52:59 -0700 (PDT) Message-Id: <200210150352.AHU29253@alpo.mirapoint.com> Received: from 192.168.1.27 by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.3.0.40) with HTTPS/1.1; Mon, 14 Oct 2002 20:52:59 -0700 Date: Mon, 14 Oct 2002 20:52:59 -0700 From: Zachary Amsden Subject: Re: Single-Master Failover Recovery and Automated Replication To: John Merrells Cc: Zachary Amsden, Hugo Tavares, ietf-ldup@imc.org X-Mailer: Webmail Mirapoint Direct 3.3.0.40 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Granted, multi-master is a solution to single master recovery - there still isn't yet a formalized protocol specification for LDAP multi-master replication. Sorry if it wasn't clear that I was talking specifically about LDAP (not X.500) and standardized, open protocols at the LDAP layer. Zach ---- Original message ---- >Date: Mon, 14 Oct 2002 19:53:32 -0700 >From: John Merrells >Subject: Re: Single-Master Failover Recovery and Automated Replication >To: Zachary Amsden >Cc: Hugo Tavares , ietf-ldup@imc.org > > > >Zachary Amsden wrote: > >>Designing a >>recovery protocol that encompasses all of these options is a rather large >>problem, which is probably why it hasn't been formalized yet (at least not >>in a public forum). >> >Well, I'd argue that multi-master is the solution to the single-master >recovery >problem... so a solution has been formalized in a public forum. > >John > > > "A plague upon all your houses" - last words of Waldo Semon, inventor of vinyl From owner-ietf-ldup@mail.imc.org Tue Oct 15 14:44:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11437 for ; Tue, 15 Oct 2002 14:44:04 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9FIcah18248 for ietf-ldup-bks; Tue, 15 Oct 2002 11:38:36 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9FIcZW18243 for ; Tue, 15 Oct 2002 11:38:35 -0700 (PDT) Received: from sleepycat.com ([12.234.103.164]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021015183822.VCCT11063.rwcrmhc52.attbi.com@sleepycat.com>; Tue, 15 Oct 2002 18:38:22 +0000 Message-ID: <3DAC60A1.2000407@sleepycat.com> Date: Tue, 15 Oct 2002 11:38:25 -0700 From: John Merrells User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Zachary Amsden CC: Hugo Tavares , ietf-ldup@imc.org Subject: Re: Single-Master Failover Recovery and Automated Replication References: <200210150352.AHU29253@alpo.mirapoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Zachary Amsden wrote: >Granted, multi-master is a solution to single master recovery - there still > isn't yet a formalized protocol specification for LDAP multi-master >replication. Sorry if it wasn't clear that I was talking specifically >about LDAP (not X.500) and standardized, open protocols at the LDAP layer. > Why do you view the ldup drafts as not being 'a formalized protocol specification for LDAP multi-master replication'? (Sorry to sound like eliza but I've been off the list for a couple of years and am only just getting back into this...) John From owner-ietf-ldup@mail.imc.org Wed Oct 23 14:14:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28036 for ; Wed, 23 Oct 2002 14:14:37 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NI7Fv01637 for ietf-ldup-bks; Wed, 23 Oct 2002 11:07:15 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NI7EW01633 for ; Wed, 23 Oct 2002 11:07:14 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g9NI78D13719; Wed, 23 Oct 2002 11:07:08 -0700 (PDT) Message-Id: <200210231807.g9NI78D13719@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3384 on Lightweight Directory Access Protocol (version 3) Replication Requirements Cc: rfc-editor@rfc-editor.org, ietf-ldup@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 23 Oct 2002 11:07:08 -0700 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3384 Title: Lightweight Directory Access Protocol (version 3) Replication Requirements Author(s): E. Stokes, R. Weiser, R. Moats, R. Huber Status: Informational Date: October 2002 Mailbox: rweiser@trustdst.com, stokese@us.ibm.com, rmoats@lemurnetworks.net, rvh@att.com Pages: 31 Characters: 66871 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ldup-replica-req-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3384.txt This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol (version 3) (LDAPv3). It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. This document is a product of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <021023110434.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3384 --OtherAccess Content-Type: Message/External-body; name="rfc3384.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021023110434.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Oct 29 21:48:59 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05649 for ; Tue, 29 Oct 2002 21:48:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9U2fsW09290 for ietf-ldup-bks; Tue, 29 Oct 2002 18:41:54 -0800 (PST) Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9U2fmW09285 for ; Tue, 29 Oct 2002 18:41:48 -0800 (PST) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id g9U1q9923416 for ; Tue, 29 Oct 2002 17:52:09 -0800 (PST) Received: from netscape.com ([10.0.198.112]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H4RWT800.CM7 for ; Tue, 29 Oct 2002 18:41:32 -0800 Message-ID: <3DBF4635.7040104@netscape.com> Date: Tue, 29 Oct 2002 19:38:45 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: Re: LCUP Last Call issues Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000807050308090807040002" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000807050308090807040002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I (and the other authors) would like to thank everyone for their comments. I must also apologize for not responding sooner to them. We are working on responding to them. We hope to have an email drafted soon which will answer most if not all of the issues raised. Thank you for your patience. --------------ms000807050308090807040002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6DCC A4MwggLsoAMCAQICAlukMA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5l IEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAyMDUzMDE4MDMzOFoXDTAyMTEyNjE4MDMzOFowfTEL MAkGA1UEBhMCVVMxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixk AQETBXJpY2htMSEwHwYJKoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMT DlJpY2ggTWVnZ2luc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2a3aAuvsFm17d ZvHQwqxJb5wk1vNxdJOr8WhMunW9m8uKFDVqbJPZWGfyugV0bADQcez4BHq5/eqpiOwft8QF 4unGHyWFIQzqQFmND7pAdEUv5CT4HgpIFrsxn/84NupZJ2JAdudPP0Pa542m1wv7+Uq8pow2 waljZI00z9/xKQIDAQABo4H6MIH3MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAO BgNVHQ8BAf8EBAMCBeAwQwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0 aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2Nh cGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDAN BgkqhkiG9w0BAQQFAAOBgQBK3Wgmiix5FP5IFXudFvuCTG1hIP9OqAPvF1UCcOqHddQoyaei T8261hqpU1wM/AIW7OPnfeaaDS2xqx3vdE9GFg4FXaO25FRb+NrMQNvaCBQn98Nv66hQqf1R I2h2aAWKYgryRdd/WBL9Xb7fueDmHcYQ+TMP41xZRFRbJbAhBzCCA4MwggLsoAMCAQICAluk MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcT DU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQ QU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDUzMDE4MDMzOFoXDTAyMTEyNjE4MDMzOFowfTELMAkGA1UEBhMCVVMxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixkAQETBXJpY2htMSEwHwYJ KoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMTDlJpY2ggTWVnZ2luc29u MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2a3aAuvsFm17dZvHQwqxJb5wk1vNxdJOr 8WhMunW9m8uKFDVqbJPZWGfyugV0bADQcez4BHq5/eqpiOwft8QF4unGHyWFIQzqQFmND7pA dEUv5CT4HgpIFrsxn/84NupZJ2JAdudPP0Pa542m1wv7+Uq8pow2waljZI00z9/xKQIDAQAB o4H6MIH3MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBeAw QwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0aWZpY2F0ZSBNYW5hZ2Vt ZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2NhcGUuY29tMB8GA1UdIwQY MBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYl aHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQFAAOB gQBK3Wgmiix5FP5IFXudFvuCTG1hIP9OqAPvF1UCcOqHddQoyaeiT8261hqpU1wM/AIW7OPn feaaDS2xqx3vdE9GFg4FXaO25FRb+NrMQNvaCBQn98Nv66hQqf1RI2h2aAWKYgryRdd/WBL9 Xb7fueDmHcYQ+TMP41xZRFRbJbAhBzCCA9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEF BQAwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMT R1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw0wMTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGT MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEn MCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDi718sdkOJSxpfs+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SI iGne/YNX4KMRGRGq1ty877PSFS5Uxm58v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhCl vMGk0XhMBuVkQfwFJWMm6+8Mx25UoYzOVFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0f BEYwRDBCoECgPoY8aHR0cDovL3d3dzEudXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1i aW4vQ1JML0dURVJvb3QuY2dpMB0GA1UdDgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNV HSAEXzBdMEYGCiqGSIb4YwECAQUwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1v cmUuY29tL0NQUy9PbW5pUm9vdC5odG1sMBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRR ME+hSaRHMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNV BAMTE0dURSBDeWJlclRydXN0IFJvb3SCAgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMw WoEPMjAwMzA5MDEyMzU5MDBaMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0G CSqGSIb3DQEBBQUAA4GBAEpiDtn6RncECmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5 n6RXhoppHwZj0X3uMzZJECAPH5cXLCdsPWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH4 66grg7A1kEwZaHHt8GMiXsJb7CB6tbBRc+kH7oFndnlT95XUMYICpjCCAqICAQEwgZowgZMx CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkG A1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScw JQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAlukMAkGBSsOAwIaBQCg ggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDAy Mzg0NVowIwYJKoZIhvcNAQkEMRYEFA96wQrK08A/wY2q1O1IiffsKKhxMFIGCSqGSIb3DQEJ DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkzELMAkGA1UEBhMC VVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVy aWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHklu dHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICW6QwDQYJKoZIhvcNAQEBBQAEgYBoLcz4 zCXstUL5eDnnP7/+tRMuypLgLlYOfhPOL18GtLZjPaBIQOZmLl8agTHirgYJF3dCibiOgmxo JuY3LTh/ydEgHSGDlyKxjaN3h6a04RO57ZBnGOE8Sxa9VRkwT+95ZjmF3oneRi15jPbKKc1o 0Khilmx27Nd56nwq5cqHbQAAAAAAAA== --------------ms000807050308090807040002-- From owner-ietf-ldup@mail.imc.org Thu Oct 31 13:18:48 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06226 for ; Thu, 31 Oct 2002 13:18:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VIC5n01972 for ietf-ldup-bks; Thu, 31 Oct 2002 10:12:05 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VIC3W01968 for ; Thu, 31 Oct 2002 10:12:04 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g9VIC5DH066447 for ; Thu, 31 Oct 2002 18:12:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021031090527.038d03e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Oct 2002 10:11:32 -0800 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LCUP Eventual Convergence, one possible approach Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As noted during the LCUP I-D's WG Last Call, there are some significant eventual convergence issues with the current LCUP approach. Jong and I have been experimenting with LCUP and exploring different approaches to provide eventual convergence. We believe that "running code" is necessary to ensure we standardize a sound approach. We think we may have workable approach to offer. However, the approach is somewhat experimental. We have not yet convinced ourselves that it "works" (e.g., we haven't coded it yet). A number of complex issues still need to be sorted out. draft-zeilenga-ldup-sync-00.txt describes the basic approach we are pursuing. Your comments are welcomed. Our I-D is not intended to compete with the LCUP I-D. It is provided to further discussions of the LCUP eventual convergence issues. It should be noted that there are likely other viable approaches to providing eventual convergence. Our I-D offers one possible approach. It is our hope that that the LDUP WG can quickly reach consensus on approach and then have the LCUP authors run with it. (We are willing to aid the authors in anyway we can.) To this end, we ask that sufficient time be allocated at IETF#55 to discuss LCUP eventual convergence issues, possible approaches, and next steps. As these issues are quite complex, it may advantageous to have some informal discussions prior to the LDUP session (by telechat if necessary). Kurt & Jong From owner-ietf-ldup@mail.imc.org Thu Oct 31 16:51:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16693 for ; Thu, 31 Oct 2002 16:51:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VLjbh13949 for ietf-ldup-bks; Thu, 31 Oct 2002 13:45:37 -0800 (PST) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VLjaW13944 for ; Thu, 31 Oct 2002 13:45:36 -0800 (PST) Received: from D7ST2111 (dhcp245085.columbus.rr.com [204.210.245.85]) by dns.caledonia.net; Thu, 31 Oct 2002 14:44:06 -0700 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" , Subject: RE: LCUP Eventual Convergence, one possible approach Date: Thu, 31 Oct 2002 16:45:05 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000501c28126$c7d412e0$6401a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5.1.0.14.0.20021031090527.038d03e0@127.0.0.1> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sounds good to me. We'll plan on discussing it at the meeting. However, at least some of the LCUP authors are unable to make it to the meeting. So we'll have to be especially diligent about posting a summary of the discussion on this topic to the WG mailing list. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Kurt D. Zeilenga Sent: Thursday, October 31, 2002 1:12 PM To: ietf-ldup@imc.org Subject: LCUP Eventual Convergence, one possible approach As noted during the LCUP I-D's WG Last Call, there are some significant eventual convergence issues with the current LCUP approach. Jong and I have been experimenting with LCUP and exploring different approaches to provide eventual convergence. We believe that "running code" is necessary to ensure we standardize a sound approach. We think we may have workable approach to offer. However, the approach is somewhat experimental. We have not yet convinced ourselves that it "works" (e.g., we haven't coded it yet). A number of complex issues still need to be sorted out. draft-zeilenga-ldup-sync-00.txt describes the basic approach we are pursuing. Your comments are welcomed. Our I-D is not intended to compete with the LCUP I-D. It is provided to further discussions of the LCUP eventual convergence issues. It should be noted that there are likely other viable approaches to providing eventual convergence. Our I-D offers one possible approach. It is our hope that that the LDUP WG can quickly reach consensus on approach and then have the LCUP authors run with it. (We are willing to aid the authors in anyway we can.) To this end, we ask that sufficient time be allocated at IETF#55 to discuss LCUP eventual convergence issues, possible approaches, and next steps. As these issues are quite complex, it may advantageous to have some informal discussions prior to the LDUP session (by telechat if necessary). Kurt & Jong