RE: MUST X.500

["Lloyd, Alan" <Alan.Lloyd@ca.com>]

Comments in line.

> -----Original Message-----
> From:	Kurt D. Zeilenga 
> Sent:	Wednesday, April 12, 2000 3:59 PM
> To:	Lloyd, Alan
> Cc:	ietf-ldapext@netscape.com
> Subject:	RE: MUST X.500
> 
> It's my view that the MUST should be SHOULD per RFC 2119
> guidelines.  That is, LDAPv3 is an application protocol
> of requests and responses.  Interoperability imperatives,
> as referred to in RFC 2119, I believe should be at the level
> of protocol peers.  Protocol peers can (and do) interoperate
> if they understand each other PDUs.  The fact that a given
> request may induce different reply from implementation to
> implementation is not indicative of inoperability, but a
> indication that servers are free to respond with any valid
> protocol construct.
> 
> Though I agree that a general purpose browser should be
> able to browse a distributed directory.  I do not concur
> that we'll ever reach the point where all sophisticated
> applications can operate on any compliant implementation.
> Though one could attempt to tighten the specification, each
> tightening of the specification reduces its flexibility.
> 
> I firmly believe that the success of LDAP will depend
> greatly on it's ability to be flexible and that, in
> spaces require interoperability at higher levels, can
> be handled by standard track elective features designed
> to handle the specific requirements of that space.
	[Lloyd, Alan]  
	However, and as said in the past!! when you design a system - you
add system features - But when you design a protocol - all you can add is
protocol mechanisms - that in most cases with LDAP drafts - only work with a
single (unscaleable) single server - but not with a distributed system -
simply because one cannot verify an access protocol feature to scale when
there is no reference system to place it on.
	[Lloyd, Alan]  
> I should also note that the MUST X.500(93) statement is quite
> problematic for other reasons. 
> 	the MUST X.500 specify states 93 documents. [Lloyd, Alan]   This can
> be updated.
>  
> 	the MUST X.500 does not specify which of the
> 	ITU recommendations must be implemented.  One must
> 	assume the complete series (including elective
> 	recommendations) must be implemented.
	[Lloyd, Alan]  This can be improved.

> 	the MUST X.500 overrules any other SHOULD or MAY in
> 	the document (or related documents) which is counter
> 	to X.500.
	[Lloyd, Alan]  Well its back to what are we are standardising and
building issue - a single server with an access protocol that has
compatability problems and inconsistent security models -  or a distributed
directory SERVICE.

> 	Encoding of directory information in LDAP makes
> 	it actually quite difficult, maybe impossible, to
> 	truely act in accordance to X.500(93) recommendations.
> 	[Case in point: LDAP representation of DNs]
	[Lloyd, Alan]  Have you tried certificate and CRL component , etc
matching rules yet in LDAP ? What will you do with this - upgrade LDAP to
DAP?
> additional comments inline...
> 
> At 09:25 AM 4/11/00 +1000, Lloyd, Alan wrote:
> >
> >
> >Hello all ..
> >
> >Re this change.
> >Does this mean that when a client application accessing a directory via
> LDAP
> >now needs to know what type of directory it is - How many types of LDAP
> >servers are there going to be in the world ?
> 
> many types of LDAP clients and servers... but only one protocol.
> Just like we have today. [Lloyd, Alan]  Set reality Mode:
> 
	  Absolutely not - ever tried to get compatibility with LDAP across
a few famous vendors...
>  
> >Why have "a common access protocol" when the client application and the
> >servers they connect to - for a directory service,  are different...
> 
> Reuse.
> Just like we have today.
	[Lloyd, Alan]  See above...

> >Does this mean we have lots of code in the client apps to detect what
> >features are in the servers, and lots of code in the servers to emulate
> >services for all types of clients
> 
> Yes, they need to detect the features they need.
> Just like we have today.
	[Lloyd, Alan]  I see we are standardising on the way we detect
features - which are variations of the standard..

	EG. ever tried to implement Persistent Search across a 1000 DSAs
with 100 million entries with 40 million users putting on persistent search
on all objects on every other operation - for hours on end.. with replicated
and distributed servers- DSAs  - see the same protocol !!! but the feature
can be implemented on a small scale server with a few users - but on a real
global directory service - it becomes unworkable - now what was it us said
about this common "protocol"..

> >and the protocol is still lightweight ?
> 
> Yes.
> Just like we have today.
	[Lloyd, Alan]  I wont go into that - been there done that - and see
above - lightweight things .. that have restrictions (see above) - have to
evolve to cater for the features applied in other protocols  that the light
ones are based on  and are of the same size and performance - dont they? :-)
>  
> >I dont mind extensions and variances - but what is the end game here - Is
> it
> >standard X.500 distributed directory service that scales and is
> consistent
> >to many LDAP/DAP type applications
> 
> But here lies part of the problem.  If X.500 were truely a MUST,
> then LDAP would just be a DAP replacement.  However, LDAP goes
> beyond replacing DAP but infact attempts to replace the X.500
> information model with it's own.
	[Lloyd, Alan]  well until LDAP designs a distributed directory
system with distributed trust, access control, PKI and an interserver trust
model using distributed mutual authentication - then LDAP (access protocol)
will still be an access protocol to most of the directory experts on this
planet ---- see all the books on LDAP . Is this LDAP development also going
to replace the X.500 name based object oriented model  and its X.509
authentication regimes as well ??? I wonder what with..   a  no name - non
certificate, non object  info things?


> Many LDAPext'ers say LDAP is an access protocol to X.500 directories
> and then, pretty much in the same breath, say LDAP can selective
> replace portions of the X.500 directory model.
	[Lloyd, Alan]  Would you like to list these ... 

	What of the X.500 Object Oriented - Named Based information  model
does LDAP "replace" --- or does LDAP do some of the management of that
information model differently with simpler mechanisms because LDAP aims its
management mechanisms for simpler non distributed servers...? Please note
the difference between an OO information model that LDAP "accesses" and the
management and security and scaleability of it..And the mechanisms in the
serv ers to deal with the difference.


> >- AS WELL AS lots of incompatable
> >unscaleable, non distributed  LDAP servers with odd mechanisms that dont
> >work on distributed directories - for small scale odd ball applications
> and
> >lots of incompatible clients - And the market and business organisations
> of
> >the world working for the next ten years to achieve compatible products?
> 
> You've just described the Internet... funny thing is, it,
> for better or worse, does works.  It's amazing how so-called
> "better" approaches have failed.  History has shown that
> flexible protocols survive where rigid protocols fail...
> and that implementations of flexible protocol specfications
> converge on true interoperabiliity just as fast (if not
> faster) than those of more rigid protocols specfications.
	[Lloyd, Alan]  I think you might find that the Internet product
suppliers are making sure their products are quite compatable with those of
major vendors and the interfaces are solidifying by the day...
> >The words below require some changes.
> >
> >> -----Original Message-----
> >> From:	Kurt D. Zeilenga 
> >> Sent:	Tuesday, April 11, 2000 5:51 AM
> >> To:	ietf-ldapext@netscape.com
> >> Subject:	MUST X.500
> >> 
> >> RFC 2251 contains the requirement:
> >>    An LDAP server MUST act in accordance with the
> >>    X.500(1993) series of ITU recommendations when providing the
> service.
> >> 
> >> This statement imples that LDAP servers must act in accordance
> >> with X.500(1993).  However, it is clear that most servers do not
> >> act in accordance with X.500(1993).  Some act in accordance with
> >> various LDAP specifications which are counter to X.500(1993),
> >> some act in accordance with other revisions of X.500, some use
> >> LDAP to access non-X.500 directories, etc.
> >> 
> >> I would like to change the above requirement (before LDAPv3
> >> is progressed to draft standard) to:
> >>    An LDAP server SHOULD act in accordance with the X.500(1993)
> >>    [or later revisions] series of ITU recommendations unless
> >>    such specifications are conflict with LDAP specifications.
> >>    An LDAP server MAY provide access to non-X.500 directories
> >>    as long as operations behave as defined by this document.
> >	[Lloyd, Alan]  
> >	" An LDAP server may not perform all the functions of an X.500
> >distributed directory - and may provide other features, mechanisms or
> >services as defined in other LDAP specifications, Such features,
> mechanisms,
> >services may cause compatibility issues with directory client and server
> >products from different vendors".
> 
> Your addition could be taken that X.500 is somehow going to solve the
> compatibility issues.  It won't.  There are enough other SHOULDs
> and MAYs which make this addition more appropriate (IMO):
> 	"Different implementations of LDAP MAY behave differently."
> 
> >> Besides allowing the LDAP community to "revise and extend" the
> >> information model, 
> >	[Lloyd, Alan]  X.500 - and an industry strength version of its
> >implementation (with LDAP access) does have an extensible "information
> >model"..
> 
> I agree that X.500 has an extensible "information model".
> I was referring to LDAPext's continuing efforts to supplant
> X.500 with their own Information model [ala LDAPsubentry,
> ala LDAP ACM, referrals, ala ...], which IMO is disallowed
> by the MUST X.500.
> 
> I prefer to allow LDAP to support "pure" X.500 implementations,
> this LDAP directory model (which is like X.500, but not X.500),
> as well as other information models.
> 
> >	The correct term that LDAP standards should be using is - extensions
> >to LDAP server functionality and LDAP server information management
> >mechnisms.
> >> this allows LDAP to be used to access
> >> directories which do not act in accordance with the X.500
> >> series of ITU recommendations.
> >> 
> >> It may also be useful to define a Root DSE attribute type which
> >> describes the directory model in use.  Ie: "X.500(1993)"
> >> or "X.500(2020)" or "LDAP(v3)" or "X-other".
> >	[Lloyd, Alan]  Although this is easy to implement - what would
> >client apps do as the result of reading this attribute..The reason for a
> >"standard "lightweight" access protocol" is to remove the issue of
> clients
> >being complex and service knowledge based  - and having to understand all
> >the server variances..
> 
> I believe lightweight still applies to protocol, but not necessarily
> to applications classes.  However, I see no reason to burden all
> implementations of LDAP to ease the burden for subsets of application
> classes.  In particular, management applications need to know much
> more about the server than a general browswer.  A general browser
> should be easy to implement and require little feature discovery
> and no apiori knowledge of the service it's browsing.  However,
> a management client will likely need a wealth of feature discover
> and some (if not a lot) of apiori knowledge of the service its
> managing.
> 
> I don't believe using MUSTs will solve the management client
> interoperability problem.... vendors will always have
> different (so they can market their wares) and these differences
> will require that some clients use feature discover or have
> apiori knowledge of the differences.
> 
> Attempts to solve this problem, don't.  But they do reduce the
> flexibility of the protocol.
> 
> >	Before we standardise  mechanisms that indicates extensibility
> >- and incompatibility (which are very easy to define)
> >- can someone give any
> >concrete examples of the requirements  and what the outcomes are - in
> terms
> >of end user benefits and directory "service" functionality.
> 
> The current state of LDAP is my example.  It's the flexibility of
> flexibility of LDAPv2 and lazy implementations which enabled
> LDAP to grow to what it is.  Should we have disallowed U-Mich
> from implementing slapd, a very non-X.500 solution?  Should we
> disallow most major LDAP vendors from continuing to provide
> their unique (and often very un-X.500) solutions?  Should we
> continue to define LDAP specifications which remove the complexity
> of X.500 (ie: are not X.500)?  Should we not continue to allow
> LDAP to support other X.500 varients (87,97)?
> 
> MUST X.500 has largely been ignored, and IMO, rightly so.
	[Lloyd, Alan]  
	I think this because the LDAP hype has downgraded the importance of
protected distributed object services  [Lloyd, Alan]  to that of directories
are all about  client - server "protocols"

	 >	I just hate to see a simple access protocol literally bogged
down
> >with twice the size in specifications for all its variances and how one
> >deals with the variances..
> 
> This seems like an argument for discontinuing LDAPext efforts
> that supplant X.500 with an LDAP model.
	[Lloyd, Alan]  

	Lets get back to the basics of what a directory SERVICE  is..
Fundamentally its a set of standard and extensible NAMED objects - object
classes and attributes that have standard identifiers ---  X.500 provides
this BASELINE.  Q - does LDAP want to change this !!!!

	To access, distribute and replicate these objects - one needs OO
based operations that deal with these services.. DAP/LDAP do the smae things
on these objects - from an application service perspective..
	DSP deal with distribution - All to hard for the LDAP work
	DISP deals with replication - and LDUP? re invented this. Howver
what the benefit in the service.. ?

	[Lloyd, Alan]  In addition  a directory is protected by access
controls which is applied via user authentication techniques - such as name
password or certificates, etc
	In a non distributed case - these are simple mechanims and models,
in distributed X.500 these are more sophisticated becuase we are dealing
with distributed trust - some thing that LDAP hasnt addressed in the last 5
years.

	In addition  a directory is managed with schema, naming and
knowledge mechanims/rules- In a non distributed case - these are simple
mechanims and models, in distributed X.500 these are more sophisticated
becuase we are dealing with distributed management and system consistency-
some thing that LDAP hasnt addressed in the last 5 years.

	I think there is a major market for distributed directory services
that deal with mutual trust, common distributed management, etc, etyc  for
obvious  reasons
	 I dont think there is much use for lots of little LDAP servers with
mechanims that cause compatability issues a just dont scale - simply because
all one is building with LDAP servers is an OO database - but with LDAP
accessed X.500 we are building distributed directory services..


	By all means make the changes - To me it comes back to utility a
company wants from a directory SERVICE - to deal with its EC business..

	Why do people want a carrier grade distributed directory service
that can hold 1-500 millions entries - its becuase they want 500m customers
and  to authenticate these distributed customers in the contexts they work
in...
	  

	regards alan