Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 05:41 PM 6/5/00 +0200, Leif Johansson wrote:
>> Section 2:
>> > Encoded packets must be small enough to fit inside a datagram
>> > no bigger than the size of the MTU of the transport mechanism."
>> 
>> Why the MUST?  Would the protocol not work if the MTU was
>> exceeded?  I would think SHOULD would sufficient... with a
>> statement as to why (ip fragmentation?).
>
>Handling fragmentation would (imho) make the protocol too complicated
>to bother with as an alternative to tcp.

CLDAP is not complicated by IP fragmentation.  IP implementations
must support IP fragmentations and applications protocols should
care less of fragmentation occurs or not.  There should be no
interoperability issue.

I concur that fragmentation is expensive, but this fact alone
is insufficient justification for the MUST.

The SHOULD would be sufficient, I suggest something on the
lines of:
  Implementations SHOULD avoid sending PDUs which require
  fragmentation at lower levels as reassembly is expensive.
  Implementations MAY use path MTU discovery or other means
  for determining an MTU restriction.  Implementations
  MUST be capable of accepting and generating PDU of size X.

The latter requirement necessary to ensure an implementation
can respond to a critical (simple) request.  Not sure what
value X should take.

>Do you know the reason why sasl is only specified for
>connection-oriented protocols? Would this be "fixable" by amending sasl or
>is there some "real" reason behind keeping sasl connection-oriented only.

SASL requires connection-oriented, reliable transport by design.
It cannot be easily amended to support connection-less, unreliable
transports.

>In anyway specifying IPSEC would seem to be the "right" thing to do.

Yes, and we'd need to define a secure authentication mechanism
for CLDAP.  I would suggest adding an authentication choice
external [4] which would use lower level credentials exchanged
at lower level to establish CLDAP session level authentication
(and authorization).  That is, it would work like SASL "External",
but be SASL-less.