|
If the use case is that one needs to differentiate between local last login time, and global last login time, I agree, two attributes would be appropriate.
But if the use case is that some deployments might prefer no replication, and others might prefer loosely or tightly consistent replication, then I think a single attribute is appropriate. Otherwise, one has to wonder how many attributes being defined (not just in this I-D) fall into the same use case and should also have semi-duplicates defined.
Jim
>>> John McMeeking <jmcmeek@us.ibm.com> 2/24/05 6:47:37 PM >>> I still think single directory first after all these years :-( So I hadn't thought of the replication side. I see the potential for the replication side of this becoming a significant implementation and performance issue. A directory used primarily for authentication generate lots of updates that need to be propagated. Actions on "read-only" replicas affect every server. But if that what someone really needs, they'll accept the price. My first reaction to multiple attributes is to have only one attribute. Then I think of times I have used something like a search for entries with a modifytimestamp > x to find entries that have changed since I last looked. In a replicated environment that may not work. Sometimes I want to know when an entry was changed by a client, and sometimes I want to know when this machine learned of the change. I'll have to think it through some more, but I think it could be a problem having a single attribute that might be the last local login, or might be the last network-wide login. You either need to define a single attribute and say it should always mean X, or define two attributes. It would be a reasonable optimization for a non-replicating server to keep one value but know it by both names. John McMeeking Jim Sermersheim wrote on 02/24/2005 11:05:25 AM: > Sure, but I still don't want to define two attributes for the same > state information. If replicating it seems appropriate, then > defining it as not-DSA Specific is the right thing to do, but beyond > that, it feels like an implementation issue as to whether and how > quickly it's replicated. > > > >>> Ludovic Poitou < Ludovic.Poitou@Sun.COM > 2/24/05 7:25:29 AM >>> > Jim, > > I tend to agree with you. But I also see the point of Howard. X.500 and > LDAP both define different types of Operational Attributes: DSA Specific > and Directory Operation with specific semantic with regards to the > consistence of the attribute value in replicated systems. > Defining an operational attribute and letting implementation (or > administrator) decide if it'll be replicated or not is actually messing > with the distinctions between the various operational types. > > Ludovic. > > Jim Sermersheim wrote: > > > Regarding replication, I favor allowing implementations to solve their > > own consistency problems. A highly usable implementation would allow > > for any state attribute to be configured for different levels of > > replication consistency (from "never replicated", to whatever the > > highest level of consistency available is). This way the admin can > > decide how consistently the state data is replicated. > > I guess what I'm saying is that I see this as a replication problem in > > general, and would rather not solve this level of replication problems > > in the password policy I-D by defining multiple sets of attributes and > > specifying different grades of replication requirements for each. I do > > think it's reasonable to address problems of loose consistency which > > is what caused the use of time to be used for things like failure count. > > Jim > > > > >>> Howard Chu < hyc@highlandsun.com > 2/23/05 9:11:53 PM >>> > > John McMeeking wrote: > > > > > I've had some recent requests for some sort of "last login time" > > attribute > > > or a "unused account" policy so that accounts can be disabled if > > they have > > > not been used for 6 months. Would either of these be appropriate for the > > > password policy draft? > > > > Both of those sound like good things to have, and it does seem to tie in > > to the rest of the password policy features. There would still be > > replication issues here. > > > > It seems to me that one solution to these replicated state attributes > > may be to define a second set of attributes - one that is DSA-specific, > > never implicitly replicated, and another one that serves as an aggregate > > for a collection of servers. Then one can specify policies for each set > > independently, e.g., "number of failed attempts" on a single DSA vs > > across the network. Sites that require total accountability could set a > > policy implementing counts across all replicas, other sites that want to > > avoid the overhead of maintaining centralized counts could set a policy > > using only dsa-specific attributes. > > > > -- > > -- Howard Chu > > Chief Architect, Symas Corp. Director, Highland Sun > > _http://www.symas.com < http://www.symas.com/ >_ > > _http://highlandsun.com/hyc_ > > Symas: Premier OpenSource Development and Support > > > > _______________________________________________ > > Ldapext mailing list > > _Ldapext@ietf.org < mailto:Ldapext@ietf.org >_ > > _https://www1.ietf.org/mailman/listinfo/ldapext_ > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >Ldapext mailing list > > Ldapext@ietf.org > > https://www1.ietf.org/mailman/listinfo/ldapext > > > > > > -- > Ludovic Poitou > Directory Architect. > Directory Server Group, Grenoble, France > Sun Microsystems Inc. > > Sun Microsystems requires the following notice: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > NOTICE: This email message is for the sole use of the intended > recipient(s) and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy > all copies of the original message. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext |
_______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext