[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LCUP WG Last Call Issues
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@xxxxxxxxxxxxxxxxxx
http://www.dsi-consulting.com
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 ::= LDAPOID
LCUPCookie ::= SEQUENCE {
scheme LCUPScheme,
value OCTET STRING
}
and request control was defined as:
ClientUpdateControlValue ::= 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
avoid creating an LCUP protocol that requires a server to store
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
is named "Features Left Out of LCUP." It is not core to LCUP, but is
useful to provide historical context and rationale for why some things
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.
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.
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