Re: draft minutes from Chicago meeting

[Tim Howes <howes@netscape.com>]

What is the case where it's needed?      -- Tim

"Russel F. Weiser" wrote:
> 
> Regarding  4. Sorting, Paging and Scrolling
> 
> I was one of the people that asked  about the addition of a cookie exchange for
> virtual list views, and have a known case where it is needed.  I think that this
> should be added to the current draft prior  to going to last call.
> 
>     There was one question asked on virtual list views: there didn't seem to
>     be a cookie exchange in the protocol, which Mark Smith said was by
>     design.
> 
>     WG ACTION: The Virtual List Views and Server-side Sorting drafts will be sent
>     to working group last call to become standards track.
> 
>     WG ACTION: The simple paged draft will be published as Informational, not as
>     standards track.
> 
> Cheers
> RFW
> 
> Mark Wahl wrote:
> 
> > Minutes for LDAPEXT Meeting at Chicago IETF
> > Reported by Mark Wahl
> >
> > 1. Recommended Authentication Methods for LDAP draft
> >
> > There is a requirement for interoperability between implementations
> > that perform updates to the directory.  The IESG had added a note to the
> > LDAPv3 RFCs stating this interoperability would potentially only be
> > possible with exchange of passwords in the clear.  Therefore the
> > recommended authentication methods draft and related "Start TLS" draft
> > addressed defining an authentication method better than passwords in the
> > clear that would be mandatory for LDAP implementations to support.
> >
> > It was noted that the mandatory to implement algorithm is not
> > mandatory for any organization to deploy.
> >
> > The Start TLS document passed last call with minor edits.
> >
> > The authentication methods draft did not successfully complete last
> > call, primarily as there was significant discussion on the choice of
> > authentication mechanism.
> >
> > There were four options discussed at the meeting:
> >  1) The document as is: make CRAM-MD5 mandatory for updates,
> >  2) Use another existing SASL mechanism,
> >  3) Wait for a new mechanism to be defined,
> >  4) Make Start TLS (encryption service) mandatory
> >
> > The area director Patrik Falstrom advised the WG that other documents
> > produced by the WG that do not depend on this can go forward to IETF
> > last call, so long as progress is being made on the mandatory-to-implement
> > authentication method issued.
> >
> > This discussion focussed on:
> >  - was CRAM-MD5 viable?
> >  - is TLS acceptable to client vendors?  Many vendors of clients present
> >    indicated they planned to implement TLS/SSL, although there were comments
> >    that it would not be acceptable to builders of embedded LDAP clients for
> >    small devices, and that it was overkill to encrypt an entire session just
> >    for a single password exchange.
> >  - Was there a need for a single mandatory to implement for all LDAP
> >    implementations, or could there be different profiles for different
> >    application requirements?
> >  - Would a situation in which there were a choice of mechanisms, of which a
> >    server must implement ALL but a client AT LEAST ONE, be acceptable?
> >
> > A pre-meeting on applications area mandatory to implement mechanisms had
> > resulted in a plan by Chris Newman and Paul Leach to work on a new
> > protected password mechanism that would be acceptable for use in many
> > application area protocols and replace CRAM-MD5 and RFC 2069.
> >
> > The Start TLS draft will have its dependencies on the recommend authentication
> > methods draft removed, and will progress.  Should a new acceptable mechanism
> > become available in a few weeks, the recommended authentication methods draft
> > will have CRAM-MD5 replaced by that mechanism.
> >
> > WG ACTION: Start TLS to IETF last call
> >
> > 2. Access Control
> >
> > The WG chairs had sent a poll on the mailing list on how progress should
> > be made on this topic.  The results had been:
> >  - Should the WG work on this? yes
> >  - Was the requirements draft generally accepted? yes
> >  - Was the ACL Model draft generally accepted? no
> >  - Should X.500 ACLs be investigated further as the basis for LDAP? yes
> >  - Should just a framework, or a framework and model be defined? both
> >
> > A framework draft, based on that of the X.500, will be written and sent to
> > the list before the next meeting.
> >
> > Bob Blakely discussed a new approach for building an access control model:
> > define new protocol operations for "grant", "deny" and "get effective" rights.
> > These could be specified with least common denominator subjects and rights
> > information, and allow clients to modify and test access controls without
> > needing to be aware of the encodings of access control inside the server.
> > A quick poll showed a lot of interest in having minimum semantics, however
> > the majority of the discussion on this approach was centered on the issue
> > of how this information could be replicated.  In particular, did there need to
> > be a transfer syntax, and if so, how this would be different from the vendor's
> > own representation format.
> >
> > WG ACTION: the requirements draft to go to WG last call
> >
> > 3. Language Tags
> >
> > The Use of Language Tags in LDAP draft had completed working group
> > last call.  It is not dependent on authentication methods.
> >
> > WG ACTION: send to IESG for IETF last call
> >
> > 4. Sorting, Paging and Scrolling
> >
> > There was one question asked on virtual list views: there didn't seem to
> > be a cookie exchange in the protocol, which Mark Smith said was by
> > design.
> >
> > WG ACTION: The Virtual List Views and Server-side Sorting drafts will be sent
> > to working group last call to become standards track.
> >
> > WG ACTION: The simple paged draft will be published as Informational, not as
> > standards track.
> >
> > 5. Referrals
> >
> > The referrals document had gone through last call and significant
> > comments on it were received.  This will be split into two separate
> > drafts: one on the hierarchical (superior/subordinate refererence)
> > use of referrals, and the other on a CIP-like mesh on referrals.
> > The two drafts will progress independently, as the hierarchical part
> > appears to have consensus to move to standards track, while the
> > mesh part is still under discussion.
> >
> > 6. SASL mechanism for X.511 authentication
> >
> > There was not much interest seen at the meeting by vendors to
> > implement or standardize this draft.  It will go informational.
> >
> > WG ACTION: send to RFC editor as informational
> >
> > 7. Transactions
> >
> > The draft is going to be revised.
> >
> > 8. Persistent or Triggered Search
> >
> > The two drafts were to be merged into a single draft, and this has not
> > yet occured.  At least another revision will be needed.
> >
> > There were comments that the document does not caution safe use on the
> > Internet and there had been little operational experience, so may not yet
> > be suitable for being a Proposed Standard.  The document may also need to
> > refine or state its domain of applicablilty as a small number of clients.
> >
> > 9. Signed Operations
> >
> > The Signed Operations draft was not discussed as the authors were not
> > present.  Some comments were that it needed better clarification of
> > purpose and a less generic title.
> >
> > 10. LDAP APIs
> >
> > The C API draft is nearly ready for last call after one more revision.
> >
> > The Java draft needs to be revised, and there were at least one set of
> > comments on it.