Subject: Re: Misuse of the term "association" in [Protocol] - msg#00017

Previous Message by Date: click to view message preview

RE: "LDAP exchange" (was: Misuse of the term "association" in [Protocol])

Ramsay, Ron writes: > I had a look in *protocol*26.txt for a definition of "LDAP exchange" and > got nothing! Here are some quotes: > (...) > > "The term "LDAP exchange" refers to application layer where LDAP PDUs > are exchanged between protocol peers." > > - I wouldn't call this a definition either. a) How can an "exchange" be > a layer? b) It "refers" to an application layer, but what is it? (a) Yes, you have made clear that you find this term misleading, but that's the meaning [Protocol] states that it uses this term for, so that's what it means in [Protocol]. (b) Section 2 contains a list of `The term "foo" refers to bar.' It had never occurred to me _not_ to consider that a list of definitions of those terms, but if you find it unclear, you can always suggest another wording for that too. > Now, tell me, what is your objection to "association". That [Authmeth] already uses that term with another meaning. See section 2 (and my soon-to-be-posted and others' replies in this thread). > Or, to be more > specific, what sentence or paragraph in protocol-26 do you think > requires a term like (ugh) "exchange"? It doesn't require a term like "exchange". It requires some term which has the meaning which [Protocol] gives the term "LDAP exchange". >> (...) If you wish to suggest a better term, read this thread > first: > > http://www.openldap.org/lists/ietf-ldapbis/200404/msg00023.html > > <RR> This seems to be talking about "connections"? Yes, and the thread starting there also talks about rejecting "stream", "LDAP layer" etc for the meaning which we now have "LDAP exchange" (as far as I can see). > Personally I prefer several other terms over "LDAP exchange", but I > don't feel strongly about it. -- Hallvard

Next Message by Date: click to view message preview

RE: "LDAP exchange" (was: Misuse of the term "association" in[Protocol])

Ramsay, Ron writes: > To: "Jim Sermersheim" <jimse@xxxxxxxxxx>, <h.b.furuseth@xxxxxxxxxxx> > > The current definition of 'association' refers to the authN and authZ > state as it applies to the <whatever term you want which describes the > exchange of LDAP PDUs>. If we use 'association' for that, then do we > need a new term for the old association definition? > > <RR> "Association" actually refers to the association between the client > and the server. No, "association" in [Protocol] and [Authmeth] actually refers to what these documents say it refers to. (Section 2 in [Protocol], section 1.2.1 in [Authmeth].) Except that they get their own usage wrong at times. But changing it to mean what you say it means will certainly confuse a lot of [Authmeth] readers. > If you are going to change this then you will probably > confuse a lot of people. I don't see any need for a "relationship" > between authN and authZ - one is derived from the other, end of story. I don't know where you get this "relationship" from - it's not in the definition in the documents, nor in this thread. > Layer 4 (currently LDAP exchange): This represents the application > layer where LDAP PDUs are exchanged (sent and received) between protocol > peers. Is this definition non-descriptive? Does it not make sense? Is it > just the name that sucks? Maybe we should have called it 'LDAP PDU > layer" > > <RR> As Kurt has said, we are not concerned here with the "layer" but > with the "session". Well, I prefer something with the "layer" meaning over something with the "session" meaning, mainly since we already have a number of layers defined, and I find this snippet (section 2) rather telling: The term "LDAP exchange" refers to application layer where (...) Most places where "LDAP exchange" is used, a session works fine (except minor rewordings like "on" -> "in"). A few places, a layer works better: "TLS-protected LDAP exchange" (4.14), "remove the TLS layer and leave the LDAP exchange intact" (4.14.3.1). "A particular operation sent on an association between a client and server" (4.5.3) may also need a little wordsmithing for the "session" meaning. Still, I'll take either variant over "LDAP exchange". > Then there is (or at least there was) the thought that we need to > provide a term which describes the association of the authN and authZ > state as it relates to Layer 4. Kurt's suggestion is that we don't need > to define (nor name) this. But that we instead update the doc in the > places he described. I agree with most of the changes, but the change to > Section 6 makes me feel like the term was useful, and we're rewording > just so we can drop the use of the term. > > <RR> It seems to me that you don't need a term to associate these. Authmeth needs to associate them (or at least the authz ID, see my message 'authmeth: association -= authentication ID') to the LDAP session/exchange/whatever. > Also, > I don't know what was objectionable about Section 6. Is this the > offending paragraph? > > "Server implementors should plan for the possibility of an identity in > and association being deleted, renamed, or modified, and take > appropriate actions to prevent insecure side effects. Likewise, > server implementors should plan for the possibility of an associated > identity's credentials becoming invalid, or an identity's privileges > being changed. The ways in which these issues are addressed are > application and/or implementation specific." > > <RR> If it is, I note that "associated" is being used in a social or > chatty way, and not in a standards-based way. Yes, it is "association" and not "associated" which is defined as a special LDAP term. > If we decide to drop the term 'association' as Kurt suggested, do we > want to re-adopt it as the term to describe Layer 4 (I think this is > what Ron is asking for)? No, because authmeth still uses it. -- Hallvard

Previous Message by Thread: click to view message preview

Re: Misuse of the term "association" in [Protocol]

Kurt D. Zeilenga writes: > I have reviewed each occurrence of the word "association" in > [Protocol] technical specification and believe the following > changes should be made: Some look good to me, others do not: >The 4.6 text: >> If the association changes or the connection fails, >> whether the modification occurred or not is indeterminate. >should read: >> If the LDAP exchange is terminated, or the Modify operation >> is abandoned due to subsequent operation which requires all >> outstanding operations to be abandoned (e.g., the Bind >> operation), whether the modification completed successfully >> or not is indeterminate. Why the "due to..." part - doesn't the same apply to an operation abandoned by the abandon operation? I disagree with the change to "completed sucesssfully". The new language looks like the modification might be partially completed. >The section 4.11 text: >> The function of the Abandon Operation is to allow a client to request >> that the server abandon an uncompleted operation. >should read: >> The function of the Abandon Operation is to allow a client to request >> that the server abandon an uncompleted operation previously requested >> in the LDAP exchange. >(The above clarification facilitates the below change.) > >The section 4.11 text: >> The MessageID is that of an operation which was requested earlier in >> this LDAP association. >should read: >> The MessageID is that of an earlier request whose response is >> outstanding. Why not just s/LDAP association/LDAP exchange/ instead of these two changes? The new text is fine from the client's point of view, but on the server side, the response may no longer be outstanding when the abandon request is received. >The section 6 text: >> Server implementors should plan for the possibility of an identity in >> and association being deleted, renamed, or modified, and take >> appropriate actions to prevent insecure side effects. Likewise, >> server implementors should plan for the possibility of an associated >> identity's credentials becoming invalid, or an identity's privileges >> being changed. The ways in which these issues are addressed are >> application and/or implementation specific. >should read: >> Server implementors should plan for the possibility of that >> information used to establish security factors may change >> (due to protocol or external events) during the course of >> the LDAP exchange, and even during the performance of a >> particular operation, and should take steps to avoid >> insecure side effects of these changes. The ways in >> which these issues are addressed are application and/or >> implementation specific. I'd like to see renaming or deleting an identity (or a DN) retained in the text as at least an example. -- Hallvard

Next Message by Thread: click to view message preview

Re: Misuse of the term "association" in [Protocol]

Kurt D. Zeilenga writes: >At 07:45 AM 10/5/2004, Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >> >>>The 4.6 text: >>>> If the association changes or the connection fails, >>>> whether the modification occurred or not is indeterminate. >>>should read: >>>> If the LDAP exchange is terminated, or the Modify operation >>>> is abandoned due to subsequent operation which requires all >>>> outstanding operations to be abandoned (e.g., the Bind >>>> operation), whether the modification completed successfully >>>> or not is indeterminate. >> >>Why the "due to..." part - doesn't the same apply to an operation >>abandoned by the abandon operation? > > Yes, but it doesn't necessarily apply to the operations > otherwise abandoned (for instance, by the cancel operation). > The original sentence was intended only to cover two cases, > re-bind and connection termination. The other case (abandon > operation) is separately handled. The new text does the same. Do we need this sentence at all? It is mentioned under Abandon, Operation and LDAP Exchange Relationship etc, and it is not mentioned in the sections for the other update operations. The same goes for the preceding sentence: Due to the requirement for atomicity in applying the list of modifications in the Modify Request, the client may expect that no modifications of the DIT have been performed if the Modify Response received indicates any sort of error, and that all requested modifications have been performed if the Modify Response indicates successful completion of the Modify Operation. Though it's useful to keep a reminder that the operation is atomic and will either fail or complete successfully, since its LDAPMessage "looks like" a series of modifications. -- Hallvard