Lightweight Directory Access Protocol (LDAP) Turn Operation
draft-zeilenga-ldap-turn-03

[Ballot comment]
Non-blocking points from Gen-ART review by Scott Brim:

    turnValue ::= SEQUENCE {
          mutual        BOOLEAN DEFAULT FALSE,
          identifier    LDAPString,
    }

Is that last "," supposed to be there?

In Security Considerations ...

Consider an opening paragraph citing general references for LDAP
security as context.

  - establish each other's identities through appropriate
    authentication mechanism,

Are there default and/or recommended authentication mechanisms for
LDAP?  Just what is considered "appropriate"?  I suggest citations.

  - establish an LDAP association between the initiating peer and the
    responding peer.

Isn't that redundant?  Isn't it impossible to issue a Turn without
having an LDAP association?

IANA Comments:
Upon approval of this document the IANA will assign 1 Object Identifier for the
LDAP Turn Operation and 1 LDAP Protocol Mechanism for LDAP Turn Operation.

[Ballot comment]
I'm concerned about implementation complexity as it relates to SASL
security layers.  I don't think most SASL implementations support the
idea of another SASL association being used in the middle of an
existing association, particularly when that association is in the
opposite direction.  So as a practical matter, implementations will
need to use two SASL contexts.  This may interact badly with the SASL
requirement that if a new security layer is negotiated, that layer
replaces the existing layer.  I don't know if text on this issue is
needed.

[Ballot discuss]
This specification provides insufficient detail to implement
interoperably.  What is the effect on the LDAP state of this operation
successfully completing if any?  I get the impression that the author
intends that other than enabling mutual or reversed p.processing there
is no effect.  However the author seems to be using a model where
there is separate authentication state in each direction.  That's
probably actually the right model since handling authorization needs
to be done somehow.  However since in many cases there is mutual
authentication, the model where there is a single authentication state
used  also suggests itself.

Concretely, the spec should explicitly describe any state changes
accomplished by a successful response code.  The spec should also
describe the authentication model in use.