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

[Leif Johansson <leifj@it.su.se>]

Hi Kurt,

Thanks for keeping us on the straight and narrow :-) Your comments
were right on the mark as usual.

> Additional comments:
> 
> The document should be updated to use RFC 2119 terminology
> statement.  I will assume it uses MUST, SHOULD per 2119.

absolutely

> 
> 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. Reordering and retransmission
is "trouble" enough (see below). The note imho MUST be a MUST but the
reason SHOULD (MUST ?) be clearly stated!

> 
> Section 4:
> > Therefore the application using CLDAPv3 have to handle packet loss.
> 
> And duplication.  And reorderring.
> 

agree, but (see below) ...

> > One way of aiding this would be to add something like a
> > packet sequence number in the PDUs sent from the server
> > to the client, how this is to be done is outside the scope
> > of this document.
> 
> I would argue that this complete within the scope of this
> document and should be addressed in the I-D.

Well, any solution would seem to require adding controls (or other protocol
elements). We were hoping to move all such additions to experimental drafts.

> 
> In addition the draft should address issues regarding the
> association (or lack thereof) of a session to a particular
> client.
> 
> > They (servers) must also check the version field of the LDAP PDU
> 
> An LDAP PDU does not have a version request.

You are absolutely right -- I don't know what got into us here. This note 
must go away. I had a thought when writing this but it was unclear which.

> 
> 
> > 6. Security considerations
> 
> Given SASL/TLS are designed for connection-oriented application
> protocols, I suggest looking into use of IPSEC transport mode
> to provide security services.
> 
> 
> 
> 

You are right again. 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.
In anyway specifying IPSEC would seem to be the "right" thing to do.

	Cheers leif