Subject: LDAPBIS @ IETF64

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Oct 2005 11:07:41 -0700

I've requested a 1 hour slot for Vancouver.  It's expected
that we'll have mostly wrapped up work on the revision of
LDAP Technical Specification by then, and hence little need
to discuss the WG's drafts (all of which are hoped to be
progressed to the IESG and/or beyond by then).  So, the
the agenda will (likely*) only have one item:
	conclude or recharter?

That is, we'll discuss what further standardization work(**) are
needed in the LDAP directory space and how to get that work done.

Those with ideas of what further work is needed are welcomed
to enumerate them here so that they can be included in a
summary of possible future work items.

Regards, Kurt

* if it becomes necessary to discuss current WG I-Ds, the
agenda will be changed to allow them.
** is presumed we'll continue our efforts to see the revised
LDAP TS to Draft Standard status, e.g., implementation
reports.  However, discussion of how to get that done is
reasonable within scope of this agenda item.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 18 Oct 2005 16:52:46 -0600

All,
 
Since protocol-31, there have been a few issues raised. Following is a
list of them and my proposed edits. I plan to submit with these changes
pending any concerns.
 
Change 1
In response to the thread "StartTLS responseName became optional"

Section 4.12. In order to clarify why extended response names are
optional:
<old text>
   The responseName is typically not required to be present as the 
   syntax and semantics of the response (including the format of the 
   responseValue) is implicitly known and associated with the request
by 
   the messageID. 
    
   If the Extended operation associated with the requestName is not 
   supported by the server, the server MUST NOT provide a responseName

   nor a responseValue and MUST return with resultCode set to 
   protocolError. 

<new text>
The responseName field, when present, contains an LDAPOID which is
unique for this extended operation or response.  This field is optional
(even when the extension specification specifies an LDAPOID to be
returned in the field).  The field will be absent whenever the server is
unable or unwilling to determine the appropriate LDAPOID to return, for
instance when the requestName cannot be parsed or its value is not
recognized.

Where the requestName is not recognized, the server returns
protocolError (The server may return protocolError in other cases).

Section 4.14.2. To reinforce the above and further clarify:
<old text>
   When a StartTLS request is made, servers supporting the operation 
   MUST return a StartTLS response message to the requestor. The 
   responseName, if present, is also "1.3.6.1.4.1.1466.20037". The 
   responseValue is absent.  

<new text>
When a StartTLS request is received, servers supporting the operation
MUST return a StartTLS response message to the requestor. The
responseName is "1.3.6.1.4.1.1466.20037" when provided (See 4.12). The
responseValue is always absent. 

Section C.2.1
<added text>
-  Removed requirement that the ExtendedResponse.responseName MUST be
present. There are circumstances where this is impossible, and requiring
this is at odds with language in Section 4.12.

Change 2
In response to the message "[Protocol] clarification on StartTLS
resonse (WAS:authmeth-15notes)"

Section 4.14.2.
<old text>
If the server is willing and able to negotiate TLS, it returns with the
resultCode set to success. Refer to Section 4 of [AuthMeth] for
details.
<new text>
If the server is willing and able to negotiate TLS, it returns with the
resultCode set to success. At this point the protocol peers may commence
with TLS negotiation. Refer to Section 4 of [AuthMeth] for details.

Change 3
In response to the message "IESG ldapbis-protocol comment"

Section 10
<added text>
It is requested that IANA assign upon Standards Action an LDAP Object
Identifier [LDAPIANA] to identify the ASN.1 module defined in this
document.

     Subject: Request for LDAP Object Identifier Registration
     Person & email address to contact for further information:
          Jim Sermersheim <[email-masked]>
     Specification: RFC XXXX
     Author/Change Controller: IESG
     Comments:   
          Identifies the LDAP ASN.1 module

[[Note to RFC Editor: please replace the occurrence of
<IANA-ASSIGNED-DIRECTORY-NUMBER> in Appendix B with the IANA assigned
OID.]]

Appendix B
<old text>
Lightweight-Directory-Access-Protocol-V3 

<new text>
Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1
<IANA-ASSIGNED-DIRECTORY-NUMBER>}

---

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 23 Oct 2005 14:53:40 -0600

I'm submitting a new protocol I-D. Following are details of the
changes:

Change 1

<new text>
The responseName field, when present, contains an LDAPOID which is
unique for this extended operation or response.  This field is
optional
(even when the extension specification specifies an LDAPOID to be
returned in the field).  The field will be absent whenever the server
is
unable or unwilling to determine the appropriate LDAPOID to return,
for
instance when the requestName cannot be parsed or its value is not
recognized.

 
   If the server is willing and able to negotiate TLS, it returns with

   the resultCode set to success. Refer to Section 4 of [AuthMeth] for

   details. 

<new text>
When a StartTLS request is received, servers supporting the operation
MUST return a StartTLS response message to the requestor. The
responseName is "1.3.6.1.4.1.1466.20037" when provided (See 4.12). The
responseValue is always absent. 
If the server is willing and able to negotiate TLS, it returns the 
StartTLS response with the resultCode set to success. Upon client 
receipt of a successful StartTLS response, protocol peers may 
commence with TLS negotiation as discussed in Section 3 of 
[AuthMeth].
 
<added to third paragraph>
In cases where a non-success result code is returned, the LDAP session
is left without a TLS layer.

Section C.2.1
<added text>
-  Removed requirement that the ExtendedResponse.responseName MUST be
present. There are circumstances where this is impossible, and
requiring
this is at odds with language in Section 4.12.

Change 2

Section 4.14.2.
<old text>
If the server is willing and able to negotiate TLS, it returns with
the
resultCode set to success. Refer to Section 4 of [AuthMeth] for
details.
<new text>
If the server is willing and able to negotiate TLS, it returns with
the
resultCode set to success. At this point the protocol peers may
commence
with TLS negotiation. Refer to Section 4 of [AuthMeth] for details.

Change 3

Section 10
<added text>

Appendix B
<old text>

<new text>
 
Change 4
In response to the message "nature of the error"
 
Section 4.1.9
<added>
Servers may return substituted result codes to prevent unauthorized
disclosures.
 
Appendix A
<old text>
   Servers may substitute some result codes due to access controls
which 
   prevent their disclosure.
 
<new text>
The descriptions provided here do not fully account for result code 
substitutions used to prevent unauthorized disclosures (such as 
substitution of noSuchObject for insufficientAccessRights, or 
invalidCredentials for insufficientAccessRights).
 
Change 5
Updated various outdated references to AuthMeth sections.