Re: Some Changes to LDAP ASN for SID (plus incomplete PER primer)

[Steve Kille <[e-mail]>]

Simon,

I've just reviewed your proposal and the subsequent discussion, and
would like to comment.  I think that there are various issues 
being tangled up together.

There are three protocols being discussed.   


LDAP: This is the basic lightweight directory acccess mechanism.
Some changes being discussed might affect this.

CLDAP: A connectionless version of LDAP, targetted at looking up specific
information about known objects (e.g., name to address resolution)

SID:  A proposed new access protocol derived from LDAP.

Comments:


1) Use of PER.  Clearly PER has some advantages over BER.  However,
all existing IETF uses of ASN.1 use BER.  A switch to PER should be
strongly justified.  For example, if there is only a 10-20% saving for
a typical 512 byte packet, I would argue strongly that the benefit
does not justify the change from BER to PER.  I'd like to see some
numbers for typical packets so that we can see what the gains are.


2) Information and Service models.   LDAP was designed as a mechanism
to access X.500.  LDAP functionality is a strict subset of X.500 DAP
(in practice a very high percentage of the function).   Because of
this, LDAP can be written as a protocol only.   All issues of
information model, distributed operation and service specification are
handled by reference to X.500.   This allows LDAP to be a very tight
specification.   CLDAP is the same, and is made even simpler by
adopting LDAP PDU definitions.

If you define a protocol such as SID, which contains function not in
X.500, this simplifying assumption no longer applies.    A viable
specification of SID would need to define:
   - overall information model
   - service definition
   - distributed operations
These could be done relative to X.500.   To be useful, it would
probably also be sensible to define how a SID directory relates to the
X.500 directory.


3) The need for a connection oriented version.  There are clear
reasons why a connection-oriented protocol is useful.   Large search
results and various security issues spring to mind.  




Proposal:   

1) Leave LDAP alone.  We have a working and useful protocol.
Changes should be made with utmost caution, and with strong reason.

2) Proceed with Alan Young's propsal for CLDAP, possibly modulo minor
changes.   Rationale:
   - There is a clear need for CLDAP
   - The proposal is straightforward, and has maximum compatibility
	with the existing deployed LDAP
   - It can be done immediately

I believe that getting this specification out to the world is urgent
and important.  I would like to see this group determine a mechanism
to get this out as an RFC ASAP.

3) Proceed independently with work on SID.  I have expressed my
reservations, but I have no objections to others investigating this
area.  There are enough issues, that it is quite clear that there will
not be a rapid focus.  Because it defines a new directory, and not
just an access mechanism, this work would not conflict with
LDAP/CLDAP.


Steve Kille