Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/asid/asid-minutes-94jul.txt

Text File | 1994-11-01 | 7KB | 164 lines

CURRENT_MEETING_REPORT_

Reported by Tim Howes/University of Michigan

Access/Synchronization of the Internet Directories Working Group (ASID)


Introduction and Agenda Review

The first official meeting of the group was called to order and the
proposed agenda was reviewed and accepted without changes.  Discussion
proceeded on the following topics.


RWhois Protocol Presentation

Mark Kosters gave a presentation on the RWhois protocol, developed by
the InterNIC and other network service providers in response to the
operational problem of providing contact information for sites,
networks, and domains.  RWhois provides the means to delegate authority
for data in a hierarchical configuration, and for then retrieving that
data given a hierarchically structured key (like an IP address, domain
name, network number, etc.), using a system of referrals designed to
keep getting clients ``closer'' to the data.  It is compatible with the
existing WHOIS query protocol.  RWhois borrows ideas from several
existing directory service protocols, including WHOIS++, X.500, DNS, and
others.  The RWhois developers intend to continue their development
outside the IETF for the moment, with an eye toward bringing RWhois into
the IETF standards process at a later date, when the protocol is more
complete and their operational problems are not as pressing.


SOLO Update

Christian Huitema presented an update on the SOLO protocol work,
including some experience gained with the SOLO centroids implementation.
In SOLO, a server can respond to a centroid poll operation with a ``*''
value, meaning that it wishes to be contacted for any search involving
the attribute for which it might have data.  This functionality is
necessary to support more restrictive privacy requirements that may
prevent servers from exporting a centroid of all names in their
database, but can cause operational problems (the * tends to defeat the
pruning purpose of the centroid).

Other possible solutions to this problem were discussed, including
sending a centroid containing hash values of the data rather than the
data itself.  This method is attractive because it limits the amount of
information transferred, maintains privacy of the data, and could make
searching the data in the centroid server more efficient.  It has the
disadvantage of not easily allowing more complicated queries (e.g.,
substring match) to be processed by the centroid server.  There was much
discussion, particularly between the SOLO and WHOIS++ developers on
these points.

Chris Weider took an action to update the centroids paper to contain
some of the ideas discussed, and to generalize the centroids concept so
that it is usable by multiple protocols.


WHOIS++ Update

Joan Gargano gave a short update on the WNILS Working Group, which had
its last meeting the previous day.  WNILS approved the three WHOIS++
papers, on architecture, query language and centroids, respectively, for
submission as RFCs.  A fourth paper on how to use a centroids mesh when
answering queries, will continue its development in the ASID Working
Group.  Chris Weider and Patrik Falstrom gave an overview of the paper,
which describes how to use WHOIS++ referral responses and polled-by
commands to narrow or broaden a search.  Also described, and soon to be
included in the paper, was a potential ``Directory of Servers''
centroid, that, using the normal centroids polling methods on a server's
``describe'' template, could be built to provide ``short circuit''
referrals to clients based on information in the template.  Finally,
Kevin Gamiel gave a brief overview of the work being done at CNIDR with
WHOIS++.


CLDAP

The remaining issue with Connectionless LDAP was resolved.  The issue
was whether authentication should be included in the CLDAP request, so
that servers could provide access to protected data.  The latest
proposal, reflected in Alan Young's most recent CLDAP draft, includes no
authentication.  The arguments against authentication are that it would
tend to defeat the connectionless nature of the protocol in the
intermediate server implementation approach, and that the proposed
clear-text password is contrary to the IAB's desire to rid the Internet
of such schemes.

The proposal was accepted by the group, and the CLDAP draft should now
be submitted to the area directors for Proposed Standard status.


LDAP

Several small problems with the LDAP syntax and related RFCs were raised
on the net by Elisabeth Roudier and Ascan Woerman.  Most of these
problems were BNF mistakes in RFC 1488, RFC 1485 and RFC 1558, or
unclear language.  All the problems are believed to have satisfactory
solutions designed, either by Elisabeth and Ascan, or Steve Kille and
Tim Howes.

Steve took an action to produce a new version of RFC 1485.  Tim took an
action to produce new versions of RFC 1488 and RFC 1558.

A second problem, with RFC 1487, the LDAP protocol document, had been
raised on the net by Martijn Koster.  The problem is with the Modify RDN
operation.  In X.500 DAP, a choice can be made as to the disposition of
the old RDN attributes (either retained as undistinguished entry
attributes, or deleted from the entry).  LDAP requires the old RDN
attributes to be deleted always, which can cause a problem if the
attributes are required.  Simply switching the choice to always retain
the attributes can cause problems in the case of single-valued
attributes.  The only full solution to the problem is to add a bit to
the protocol so that clients can make the choice as in DAP.

Tim took an action to start a discussion on the OSI-DS list to resolve
this issue.

Finally, a suggestion was made that this might be a good opportunity to
look at incorporating X.500 (1993) support into LDAP. Reactions were
mixed.

Tim took an action to start a discussion on the OSI-DS list about this
issue.



Schema Publishing in X.500

Glenn Mansfield gave a presentation on some work he and his colleagues
have been doing to publish X.500 schema information in the X.500
directory.  The problem to be solved is how a DUA can resolve an unknown
object class or attribute it may come across in the directory.  Their
paper includes schema for representing attributes and object classes in
the directory.  It also describes where this information should be
placed in the DIT, and outlines the procedure a DUA should follow when
it encounters an unknown schema element.

There was also a discussion of the Internet X.500 schema group (late of
the OSI-DS Working Group), which has published an Internet-Draft on
their plans to publish and keep up-to-date the Internet X.500 schema.
The group has finished its work on the draft, and should now start
accepting new schema and begin publishing them.  The group will continue
to track this work in the hopes that it could be used as an on-line
publishing mechanism.

Tim took an action to send the schema group's draft to the OSI-DS list
for last call comments, after which the draft will be submitted to the
area directors for RFC status.

The X.500 schema group (Tim, Russ Wright, Ken Rossen, and Sri Sataluri
in absentia) took an action to finalize the distribution methods
described in the draft, and to begin accepting new schema elements
immediately.  The address for submission is [e-mail].


The Next Meeting

The next meeting of ASID will be at the December IETF in San Jose,
California.