Draft minutes of the San Diego Meeting

Steve Hardcastle-Kille <S.Kille@cs.ucl.ac.uk> Wed, 08 April 1992 12:43 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00535; 8 Apr 92 8:43 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08600; 8 Apr 92 8:46 EDT
Received: from bells.cs.ucl.ac.uk by NRI.Reston.VA.US id aa08596; 8 Apr 92 8:46 EDT
Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.03299-0@bells.cs.ucl.ac.uk>; Wed, 8 Apr 1992 13:08:42 +0100
To: osi-ds@cs.ucl.ac.uk
Subject: Draft minutes of the San Diego Meeting
Phone: +44-71-380-7294
Date: Wed, 08 Apr 1992 13:07:49 +0100
Message-ID: <1466.702734869@UK.AC.UCL.CS>
From: Steve Hardcastle-Kille <S.Kille@cs.ucl.ac.uk>

Thanks to Justin for timely and comprehensive notes.   Please send any comments
or changes.  I have not been able to fill in all of Justin's gaps.


OSI-DS Meetings: 7th meeting of the IETF Directory Services Group

 March 12th 1992, Dan Diego

Minutes  by Justin C. Walker, justin@apple.com, and Steve Hardcastle-Kille


Chair:  Steve Hardcastle-Kille

"Claudio Allocchio"           <claudio.allocchio@elettra-ts.infn.it>
"Harald Alvestrand"           <harald.alvestrand@delab.sintef.no>
"John Ballard"                <jballard@microsoft.com>
"Paul Barker"                 <p.barker@cs.ucl.ac.uk>
"William Biagi"               <bbiagi@cos.com>
"Jodi-Ann Chu"                <jodi@uhunix.uhcc.hawaii.edu>
"Alan Clegg"                  <abc@concert.net>
"Richard Colella"             <colella@osi.ncsl.nist.gov>
"James Conklin"               <conklin@bitnic.educom.edu>
"Urs Eppenberger"             <eppen@verw.switch.ch>
"Stefan Fassbender"           <stf@easi.net>
"Mark Fox"                    <m_fox@took.enet.dec.com>
"James Galvin"                <galvin@tis.com>
"Jisoo Geiter"                <geiter@gateway.mitre.org>
"Tony Genovese"               <genovese@es.net>
"Sang-Chul Han"               <schan@garam.kreonet.re.kr>
"Alf Hansen"                  <Alf.Hansen@delab.sintef.no>
"Steve Hardcastle-Kille"      <s.kille@cs.ucl.ac.uk>
"Alton Hoover"                <hoover@nis.ans.net>
"Tim Howes"                   <Tim.Howes@umich.edu.>
"Erik Huizer"                 <huizer@surfnet.nl>
"Ole Jacobsen"                <ole@csli.stanford.edu>
"Barbara Jennings"            <bjjenni@sandia.gov>
"Darren Kinley"               <kinley@crim.ca>
"Mark Knopper"                <mak@merit.edu>
"Eva Kuiper"                  <eva@hpindda.cup.hp.com>
"Sylvain Langlois"            <sylvain@cli53an.edf.fr>
"Kenneth Lindahl"             <lindahl@violet.berkeley.edu>
"Triet Lu"                    <trietl@sparta.com>
"Scott Marcus"                <smarcus@bbn.com>
"Daniel Matzke"               <matzked@cerf.net>
"David Miller"                <dtm@mitre.org>
"Daniel Molinelli"            <moline@gumby.dsd.trw.com>
"Robert Morgan"               <morgan@jessica.stanford.edu>
"William Nichols"             <nichols@took.enet.dec.com>
"Tracy Parker"                <tracy@utexas.edu>
"Emmanuel Pasetes"            <ekp@enlil.premenos.sf.ca.us>
"Rakesh Patel"                <rpatel@rutgers.edu>
"Geir Pedersen"               <geir.pedersen@usit.uio.no>
"David Piscitello"            <dave@sabre.bellcore.com>
"Jon Postel"                  <postel@isi.edu>
"Marshall Rose"               <mrose@dbc.mtview.ca.us>
"Ursula Sinkewicz"            <sinkewic@netrix.nac.dec.com>
"Mark Sleeper"                <mws@sparta.com>
"Mark Smith"                  <mcs@umich.edu>
"Einar Stefferud"             <stef@nma.com>
"Tom Tignor"                  <tpt%@isi.edu>
"Justin Walker"               <justin@apple.com>
"Chris Weider"                <weider@ans.net>
"Brien Wheeler"               <blw@mitre.org>
"Cathy Wittbrodt"             <cjw@nersc.gov>
"Russ Wright"                 <wright@lbl.gov>
"Peter Yee"                   <yee@ames.arc.nasa.gov>
"Wengyik Yeong"               <yeongw@psi.com>
"Ki-Sung Yoo"                 <ksyu@garam.kreonet.re.kr>

Agenda - A paper copy was distributed that updated the previously 
transmitted electronic version.  A copy is appended.

No comments on the Minutes of the San Jose meeting; they were 
accepted as written.  They are available as OSI-DS-MINUTES-6 on 
your neighborhood OSI-DS document archive server.

Matters arising - Steve to prompt George Brett to circulate documents.
It was not known if this had been done.  Action dropped.

Richard Collela was to send a current list of the OIW documents to the osi-
ds mailing list.  The question was asked whether this was done, and 
no one knew for sure.

Other items of business were to be discussed as specific points on the 

Liaison Reports:
RARE WG3: Erik Huizer reported that the a number of documents 
were discussed.  The "character set" issue was also discussed.  On a 
sad note, the January meeting was for WG3, due to restructuring 
within RARE.  In the future, it will be more like IETF (from may 
onwards).  There will be a followon to WG3, but the form has not yet 

ISO/CCITT - No liaison was present.  Availability of the Directory 
root over CONS has been requested by JANET.  This will cause 
reachability problems for CLNS use.  The issues haven't been fully 
addressed yet.

OIW: Russ Wright reported that agreements on replication have gone
stable (1992); 1988 documents on ??? <<<MISSED THIS>>> are stable.
Trying to distinguish between 88, 92 items.  The X.400 and X.500 SIGs
met.  The X.400 folks complained about lack of attribute types for
routing.  EWOS sent a statement about adding transport requirement
(NSAPs don't specify transports).  Major work on international
standard profiles (dealing with DAP) is underway; this should be out by

NADF: Einar Stefferud reported that the pilot proposed for 2/92 is
"underway"; member participation will be "utopian" <<<NOT SURE WHAT I
MEANT BY THIS>>>.  There are interworking issues between this pilot
and the White Pages pilot, due to different naming schemes and the
listing vs. registration models.  Discussions have been held at NADF
to determine that two pilots could *not* be connected.  According to
Wengyik, there is no common naming of schema.  The major problem is
operational (naming of DSAs, etc.).  PSI can not act as broker (there
are knowledge and data sharing problems).  Desire is there, so it
seems that meetings are needed to discuss this.  The NADF pilot work
needs to stabilize before these can reasonably proceed.  The NADF
wants to push knowledge sharing (open DIT; global system).

The White Pages pilot "caused problems" by presuming that it was a 
national authority (which, it is claimed, it isn't).  It was pointed out 
that these were technical assumptions to help deploy early.

NADF is waiting for the 1992 changes to the directory (X.500) to be 
published to determine what membership will do about compliance.

The NADF has issues of competitiveness, tariffs, etc., guiding its pilot 
development.  These are real world assumptions.  The WP 
assumptions were simplifying.  NADF documents are available, 
modulo media issues.

DISI: Chris Weider reported that three new RFCs are out: 1292, 
1308, 1309 (a "real executive summary").  They now have a clean 
slate, so if new documents are needed, speak up.

AARN: Steve Hardcastle-Kille read the following report:


Report to the IETF OSI-DS WG from the AARNet Directory Project

1. Australian Networkshop in last December

   We conducted a demonstation of the Directory at the recent
   Networkshop which attracted considerable interest, and as resulted
   in 3 more AARNet members joining the pilot.

   The demonstation was spoiled somewhat by the failure of our frame
   grabber and where we had hoped to use colour images, JPEG encoded,
   we had to make do with greyscale imagines (still using JPEG). The
   DIT used for the Networkshop is still available, as
   "c=AU@o=Australian Networkshop", having been migrated from the loan
   machine we had at the Networkshop to one of our project machines.

2. Future of the AARNet Directory Project

   Officially the project has concluded, except for the submission to
   AARNet of our report, but we expect that the Project will continue,
   hopefully with additional funds from AARNet.

   We will continue to champion the Directory as an information
   resource and encourage AARNet members to run their own directories.
   We also intend to use of our machines to provide a service where
   AARNet members can experiment with the Directory without having to
   run their own, as well as providing a registration point for any
   organisation connected to AARNet so that basic information about
   their organisation can be made available through the Directory.

3. Binary distribution of DUAs and DSAs

   The AARNet Directory Project have made available a number of binary
   kits (SPARC, RISC/Ultrix, Sun3 and Pyramid) of the Quipu
   distribution for anonymous ftp on ftp.adelaide.edu.au in the
   pub/white_pages/KITS directory. The main purpose of this is to allow
   other sites to easily access the the pilot, either by making access
   to the Directory available at their site or allow them to easily
   configure a DSA of their own. The kit has been tailored for sites
   wishing to join the pilot in Australia but the binaries could be
   used anywhere.

4. Current state of the Directory in Australia

   There are currently 25 DSAs in Australia, and they master 45,975
   entries. After checking the sites that have fetched a copy of one
   of our binary kits I would hope that there will be 3 more sites in
   Australia starting to run their own DSA shortly.


The following are the status reports of operational pilots:

FOX: Tom Tignor reported that FOX is waiting on NSF funding; final 
reports have been submitted, and nothing is happening now.
Individual efforts:
SRI - x5whois - whois information in a DSA.  Conversion problems 
overcome, but DSA loading is taking a long time (they have added 
more memory, reduced the number of attributes held).  There are 
150000 entries now.   Interoperability testing (between QUIPU and 
CUSTO) is underway.
PSI - x5rfc, a document retrieval gizmo, x5ftp, and usconfig are 
under development or in test. <<<Need to see Wengyik>>>.
MERIT - Working on making information resources (e.g., k-12, NIC )
avail on X.500; schema documents on these are available.  They are 
looking at storing data as pointers to original information.  The 
University of Michigan is looking into developing a Macintosh DSA 
ISI - Currently, they are in a cheerleading mode, and acting as a 
central switchboard for these efforts.  They are just moving to QUIPU 
7.0.  They are looking at a lightweight version of x5whois.

A question was asked regarding the transition to X.500 in Europe: 
have there been real directories mapped into x500?  The consensus 
is no, that most directory efforts have focused on creating new X.500 
databases.  We should then look at any problems arising from 
moving the "whois" base to X.500.

White Pages: <<<MUST GET DETAILS FROM Wengyik >>>. The 
NADF/WP differences were discussed again.

PARADISE: Paul Barker reported that there have been problems 
with (large) getedbs.  PARADISE is moving to ISODE 8.0, and this is 
causing some service upset.  Use of central DUA services on a central 
ULCC  system is rising.  It was 
requested that we all please take some of the lush documents from 
PARADISE.  These describe the services supplied, as well as the user 
interface alternatives provided.  Revisions are being planned for the 
DUA (e.g., loosening up the hierarchy). Multilingual versions of I/F 
are becoming available.  Among others, a management interface for 
simple maintenance; for small or disinterested users (e.g., for those 
with a simple o=, or for lower level updates).  A probe (written in 
C++) is being produced, with better post processing of results.  One 
partner (the Dutch PTT) has sent query to other PTTS on attitudes on 
X500 (most said "X.What"?).  Steve  Hardcastle-Kille and Paul Barker 
are producing 3 metric documents - for DUA, DSA, and Pilots.  These 
will be in the form of questionnaires, and they are looking for details 
on each.

The operational reports being given, we plunged into the individual 
items from the agenda.

Security - The NADF started looking at it last year.  A Directory Bill 
Of Rights has been published as an RFC <<<RFC#?>>>.  Each word of the 
Bill of Rights has been lovingly crafted to both ensure rights and  
require nothing.  Also, security for competitive products has been 
under study.  A revision of this is expected after NADF meeting, 
when it will be revised and published as an RFC (the week of 4/21).

Need for a Directory Operations Group - Does the IETF need a 
WG for Operations, dealing practical issues of running a directory 
service on the Internet.  This group could work on a benchmark 
document, operating specifications, interoperability issues.  During 
the discussion, a question was raised regarding the difference 
between the new group and DISI; the latter was described as an 
educational provider.  Suggested differences: the OSI-DS provides 
implementations of the directory; DISI is for users; and the new 
group is for operators.  It was pointed out that this obeys the Narrow 
Focus admonition of IETF WGs.  A straw poll indicated low interest in 
both having and not having a separate WG for operations (a majority 
abstained from the voting; only a handful cast votes), so the issue 
was put aside for now.

Strategy Document - Some issues need to be resolved, privately, 
before getting closure on this document.  Concern has been raised 
that Steve H-K is generating documents faster than the rest of us can 
read them.  The protagonists are looking for insight on what should 
go into and what should not go into the document.  The problems are: 
the document describes the registration model; attention needs to be 
paid the work of the NADF and listing model.  The document also 
doesn't address deployment issues, e.g., where the resources come 
from.  A section on security is wanting, but should be filled in from 
Steve.  A version is promised by the end of April.  Anyone with 
views should speak with Erik Huizer.

New Object Models - Three papers on new object models have 
been published. The object models are described therein as schemas.
Comments are solicited.  One comment - this doesn't match the X.500 
model of having "objects" that have "real" significance.  What is
"service" (called "resource" in the papers)?  A subgroup meeting was 
suggested for further resolution of the subclass/object definition.
Another comment: how does one search, based on schema?  One must 
distinguish between DIT structure and object models.  The former is 
to be considered in the WAIS BOF.  There followed a discussion of 
how to represent network infrastructure information in the 
directory.  A previous paper thought now to be wrong (by the 
author)   It was suggested that IP representation should be widened 
to include host parts, AD, other information.   Concern was expressed 
that the representation of network addresses not lose information 
(e.g., net masks).

OSI-DS-12 discussion - (and the "list vs. registration" debate)
Earlier, after discussion on the osi-ds mailing list, the document was
modified to add a note on an alternative (championed by Christien
Huitema).  In discussions at RARE, the WG3 folks have
suggested removing the alternative (i.e., going back to the form prior
to Cristien's suggestions were added).  There followed a lively
discussion on the two alternative positions, although noone was
present to support the alternative.  The position taken in the paper
was well and eloquently defended.  Note that the document hasn't been
through the IESG/IAB process yet.  Note also that the disputed section
is really an advisory one, dealing with countries without current
registration authorities.  A straw poll was taken on the question of
removing the "alternative": lots in favor; two abstentions; none

Also, it was observed that Sec 3: the UFN statement makes it (this 
particular UFN syntax) special.  After discussion, it was accepted that 
this section should be deleted.

The subject of "Who Owns The Root?" arose, relating to an ongoing 
concern with resolving the differences between the listing and the 
registration models.  A discussion ensued regarding the effects of 
putting in things to the root, willy-nilly.  o=Internet, small numbers 
of "l="s, , and a small number of DSAs were examples used to 
highlight some of the issues.  No conclusions were reached by the 

Registration vs. Listing discussion - In the Listing corner were 
Einar Stefferud and Marshall Rose.  The NADF is leveraging off US 
civil authority (in particular, that resting with the states, counties, 
and "localities").  There is a problem of looking for a company (or a 
person) without knowing its state of incorporation (that is, Delaware, 
not Confused) (or, in the case of a person, the organization chart of 
his (s/he/it's) company).  From this view, the DIT should be 
organized based on search needs.  Therefore, we need to do this at 
national level.  A basic issue is the mapping from civil authority to 
DIT (need not be 1-1).  This is the Listing view.

It is claimed that registration authentication already exists, except 
for registration under c=US.  ANSI does allow registration here (at 
the c=US level) at $2500 a pop; the details have appeared on the net 
a number of times.  Control of the directory (i.e., assuring that we 
don't pollute the directory at too high a level) comes with listing 

The listing model, following an anecdote from Einar Stefferud, 
emphasizes the need to lose your keys under the light.  The point is 
that you are more likely to find your keys where there is light (even 
if you didn't lose them there).  Similarly, one needs to list oneself in 
the Directory where one would be expected.  Where one is actually 
registered is less of an issue, and depends on vagaries of the domain 
administering your neck of the woods (or DIT).

The membership was advised that no lunch break would be 
forthcoming until this discussion is done.  As a result, our focus 

The registration side view was detailed by Steve Hardcastle-Kille. 
The Directory should leverage off existing civil authority.  It is 
important to separate directory and registration (at least at high 
levels; at lower levels, convenience of the DNS approach may 
override).  Multiple providers are needed, as is naming coherency 
(tied in later).  NADF requires all providers to assure naming 
coherency. There are 3 kinds of registration: ANSI, civil, and derived.
These are the listings.  The point was made that listings are actually 
a form of registration, in that a listing takes up "name space" and 
that listing agents must work to assure that collisions don't occur.  A 
counter argument was made that collisions will naturally clean 
themselves up as a result of the competitive nature of the Directory 
provision market.  The problem seems to be the issue of recursive 
listing authorities.

The debate continued with no clear winner, although the weight of 
evidence seemed to favor the listing folks.  The point was made that 
the NADF model had no implications for components of the DIT 
outside c=US (other than those inherent in its adoption beyond those 
boundaries).  The Listing view starts with the observation that 
names are intellectual property, sanctioned by civil authority within 
some (e.g., c=) boundary.  Listings (following NADF) are 
algorithmically derived from names, hence (at least within the 
domain covered by NADF), no chance for collision.  There was 
disagreement on the issue of listing being an implicit registration.

In the end, the sense of the meeting (by show of hands) was to push 
12 to an RFC.  The Listing vs. Registration debate will continue, with 
efforts being made to align the various pilots for interoperability 
(<<<I don't recall the exact resolution of this>>>).

UFN - Per a suggestion from the IAB, the UFN document will be split. 
The specific string representation (the use of ";" vs. ",") has gotten lots 
of discussion.  The use of UFN itself has received little comment. 
Discussion on the string rep: use ';, ',, or "not both".

On the vote to forward the UFN document, the 'ayes carried (so it will 
be forwarded).

<<<Steve, My notes on this discussion are a little flaky.  Do you or Russ 
remember details?>>>

QOS - There has been no progress on the Quality Of Service issue.
The QUIPU implementation now agrees with "the documentation" 
(the RFC???, not the QUIPU manual).  There are two pieces: the user 
interface and the deployment.  Deployment underway.  To date, 
there has been no user interface defined to allow a user to invoke 
this capability.  A dissenting view on the utility of QOS is that it is up 
to the guy who provides the service to describe QOS, and there is 
little or no uniformity to allow this.  For example, for the provider 
using the ISODE-provided DSA, he may describe it as experimental if 
he is a commercial provider, or as non-experimental if he is a 
university researcher.  The experiments will continue.

JPEG - Support for this should be in the next version of QUIPU.  A 
schema for JPEG photos is not yet ready.  Currently, this is specified 
as an octet string.  There is a conflict with G3Fax, which will be 
resolved by separating attributes (per last meeting).

Character Sets - The paper is partly from discussions in RARE WG3 
and RARE/COSINE groups.  Current DUAs don't support national 
characters and the T61 data type very well.  Europe (at least) has a 
requirement for national characters.  The providers need to add this 
support in a coordinated way.  The directory should have national 
versions of names (I18N).  The solution proposed by the author is

	o Store national characters using T61 string syntax
	o DSA string search algorithms must account for I18N'd names
	o Mapping table
	o DUA presentation to user dictated by the user (to use or not 
use I18N)

Issues include:
	o What are precise requirements?
	o What are the implications for UFN?
	o The necessity to agree on conversion at a national level

Note that UFN is assumed to be defined on abstract character set, so 
I18N not an issue(?).  Remarks:

	o is this only an "operational" issue, or are there other issues?
	o how are I18N strings stored, searched?  X.500 discusses this 
briefly, but that discussion does not seem acceptable.
	o No experimentation is underway, but should be started (e.g., 
between France and Norway).

Counting the DIT - Current work is DSA-specific and is very 
implementation specific.  A suggested new approach is to add new 
attributes (integers all) that count appropriate things at each level.
Counts can be done manually or automatically.  The question arose: 
do we count the # of registered or listed entries?  The sense of the 
meeting was to progress with the experiment; there was a tentative 
volunteer to look at the implementation issues.  <<<DIDN'T GET THE 

RFC1274 - The original intent was for Steve and Colin to maintain 
this document.  Problems have arisen with the time needed to 
maintain it (keep it up to date) and how to maintain it.  A suggestion 
is that we try a structured approach a la SNMP.  We need to 
document each "object class" as with a MIB: what are the mandatory, 
optional, and experimental entries.  Another problem is expressed 
concern over the openness of the process to extend attribute and 
class lists.  We could either establish a small committee or a new WG 
to oversee the development of the Directory.  The consensus was for 
a small committee.  The IAB was previously asked about their 
feeling.  The thought was put forward that this could be more like 
Host Requirements, than like SNMP.  A show of hands called for an 
attempt to tack down what the committee would do.  Five brave 
souls stepped forward.  Paul Barker volunteered to restructure the 
main document.  The new structure will include procedures for 
extending the current definition, a list of other documents and 
general purpose attributes; and a mechanism for generating other 
documents as needed.

Schema Publishing - An alternative to the preceding approach is 
"don't write RFCs".  Instead, just write a new schema into the DIT.
Tim Howes and Mark <<<???>>> volunteered to write this up for public 
consumption.  Code to do this is also needed.  There followed a 
discussion of machine generated schema descriptions, e.g., by 
automatically culling appropriately prepared documents from the 
new RFC1274 structure.  Stay tuned.

preferredName attribute discussion - Others deferred to the 
committee.  The attribute type preferreddisplayname is a subtype of 
CN (for 1988 Directories, this would be a duplicate of the CN).  A DUA 
could use this as the display value for CN.  The attribute would not 
be mandatory.

Administrative limits - In a note sent out in January, the idea of 
size and time limits on searches was proposed.  Also, it would be nice 
to have a value to limit the number of DSAs to which to refer during 
a search.  This is thought to be related to issues of QOS.  A document 
discussing these values was proposed for the next meeting.  Note that 
this puts information about Directory use in the Directory.  Doing this 
may require the use of security above that currently available.  
Should these be represented in MIBs?  Steve Hardcastle-Kille 
discussed the use of SNMP as a tool for the management of 

Adding DNS information to directory - Software has been 
created to load DNS information into the DIT.  "dnsconfig" will create 
the initial EDB hierarchy for the DNS part of the tree.  "dnsupdate" 
loads DNS information into the directory.  "fred" has been modified to 
resolve user@domain.  "dnsconfig" and "dnsupdate" are under test.  
The modified "fred" has not been released yet.  The work is being 
done at PSI, by Wengyik Yeong.

Some comments were offered on RFC1279, based on this work:
using case insensitive string to represent the values of all types of 
DNS records is too simplistic.  However, defining separate attribute 
syntaxes for every DNS record is both impractical and wasteful.  It 
doesn't scale, and the effort is wasted for those less frequently used 
record types.  As a compromise, one can special case those DNS 
records with their own syntaxes.  The others can continue to use case 
insensitive string values.

It was suggested that DNS records that use case insensitive string 
values need to have the sequence in which the TTL, Class, and Type 
fields occur, standardized.  One could fix the sequence (e.g., in the 
order of Class, TTL and Type) with all three mandatory in every 
record; or fix the sequence as above, but let the class be optional and 
default to IN.

Some concern was expressed that ''leaves" in the DNS can be interior 
nodes in the DIT.  This could be a problem, since QUIPU is very slow 
when loading non-leaf entries.

Open Questions
Can we make o=Internet the final resting place for the DNS tree in 
the DIT?

Can we load up all the top level domains (from DNS) without explicit 
consent from domain owners?

Further questions:
1) Where do we put the o=Internet tree?
We assumed this had already resolved, i.e., place it under the root.  It 
was noted that we have no authority to do that, hence perhaps we 
should place it under a c= node.  It is possible that, e.g., CNRI could 
pay ANSI to register it.  One camp says "just do it"; another says "put 
it where it is safe", so we won't have to change further down the 
road.  A straw poll regarding where to place the root was taken.
There were lots for the "under c=somewhere" position, only a few for 
the "under root [few]", and a number of abstentions.

The debate on placement continued for a while, with lots of back and 
forth regarding the effects of each choice of placement of 
"o=Internet".  We ended on the comment that, if we chose to place it 
under the root, this would be one of the few times that Stef would
later say he told us so.

2) Do DSA operators have right to load top level DNS zone files into 
the Directory?  One argument is that, if you permit zone transfers, 
then the door is open.  The counter argument is that DNS never 
agreed to this (X.500) usage, that this is a new usage, and thus 
assumptions should not be made about acceptability.  It was 
uniformly agreed that the following applied: ZONE TRANSFERS 

3) Further discussion of the interaction between X.500 attributes and 
DNS records.  It was suggested that attribute syntax for common DNS 
records be changed (to fit more neatly into X.500), while less 
common DNS records be standardized using string records.

Vint Cerf-
The Internet Society may be able to register "Internet" for OID and 

OIDs- According to Hardcastle-Kille, it doesn't matter where these 
come from.

RDNs- top level o=Internet is desirable.

CAT (Common Authentication Technology) - This discussion was 
concerned with integrating security in a variety of technologies.  The 
presenter (John Linn) was from the <<<???>>> WG, and wanted 
to raise the consciousness of the OSI-DS WG, since many of the issues 
that confronted them involve naming in the X.500 sense.  The CAT 
depends on global naming, in that they are using X.500 DNs in X.509 
certificates.  They are encountering early adopter penalties.

A major issue is that the CAT folks don't want DNs that are used for 
authentication to diverge from those used for other purposes within 
the Directory.  CAT needs to deal with hosts, users, processes (for 
authentication purposes) within the environment and protocols used 
by DNS, accommodating mismatches.  Hosts are currently handled, 
but not users or processes.  This is, fundamentally, a naming issue.

Implementations must support Directory access routines for security 
purposes (i.e., parsing is not needed; the only requirement is for 

Our respective areas could benefit from naming coexistence (API 
definitions,  available support libraries.  The main question the 
presenter had was:  is this part of OSI-DS charter or current plans?

In the discussion that followed, to comment on the presentation and 
answer John's question, the issue of what problem was being solved 
arose.  It is important to not replace DNS host names, but to provide 
unique names for authentication usage.  John will post a brief 
description of his work, with pointers to his documents.

The sense of the meeting was that this was best pursued in the 
context of the discussion list rather than during the meeting, because 
a clear understanding of the issues is wanting.

Lightweight Protocols - Dixie and DAS are recent alternatives to 
the full OSI stack implementation of a Directory user agent.  They are 
incompatible.  Wengyik Yeong, Tim Howes, and Steve Hardcastle-Kille 
have designed other alternatives.

LDBP - This is the first in a series of protocols.  It is targeted to 
browsing (no name service).  It is session oriented and supports few 
operations.  Its error structures have been flattened (they contain 
only a code and a string).  There is no BER (and no authentication!!), 
and instead, uses its own binary rules (the so-called "string 
encoding").  Passwords are sent in the clear.  This could be used in a 
DUA, bridge, or it could be embedded in a DSA for direct support.

SOS - Based on the observation that many applications make little 
use of the upper layers of OSI, SOS allows direct mapping to a 
transport layer(either CONS or CLNS).  A streaming proposal is 
incompatible with X.400/X.500 security issues (because access to the 
full PDU is required).  Steve Hardcastle-Kille hasn't looked at related 
OSI work on <<<???>>> (application environments) and <<<???>>> 
(reorganizing application layers, putting the session goo in the 
transport layer, removing the presentation layer).

Note that SOS really transcends X.500 - it is a much more general OSI 
issue.  This differs from the "Skinny Stack", a multi-layer collapsing 
of a local stack, due to Van Jacobson.  Note that the presence of the 
skinny stack is not seen at the remote end, unlike the case for SOS.  X 
is the first to use the skinny stack (cf. implementors agreements).
Concern was expressed that, because of the above observation, this is 
beyond the scope of this WG.

Colin's message (on DS 26) is: is LDBP needed in the face of SOS?
Also, Colin had question on "DAP lite" - why not work on this, 
providing interoperability with existing DSAs, rather than new 
protocols (e.g., add skinny stacks).

How do these affect "homogeneity" for having a global directory?
What are motivations, tradeoffs, payoffs.

Final agenda item: Next meeting - it was decided that the next OSI-DS 
meting will be at the 24th IETF meeting (July, 1992, in Boston).  We 
will postpone DSA Naming discussions until then.

Agenda for seventh meeting of
IETF Directory Services Group
Version 3

S. E. Hardcastle-Kille

March 12, 1992

	Monday 16th March 1992


	San Diego IETF
	Hyatt Islandia-B

	Draft Agenda Follows

9:30 Introduction
	o Agenda
	o Minutes of San Jose Meeting (OSI-DS-MINUTES-6)
	o Matters arising

9:45  Liaisons
	o RARE WG3 (Erik Huizer)
	o OIW (Russ Wright)
	o NADF (Einar Stefferud)
	o DISI (Chris Weider)
	o AARN (Steve Hardcastle-Kille)

10:00  Operational Status of Pilots
	o FOX (Tom Tignor)
	o PSI WPP (Wengyik Yeong)
	o Paradise (Paul Barker)

10:10 Security Document (Marshall Rose)

10:15 Need for Directory Operations Group (Steve Hardcastle-Kille)

10:20 Progress on Strategy Document (Eric Huizer)

10:25 Progress on representing Management Information in the 
directory.  The new object models (OSI-DS 14, 16, 17, 19; Chris 
Weider, et alia) *** NEW VERSIONS COMING SOON ***

10:45 Naming Guidelines (OSI-DS 12.4)

11:00 ISOC role in Registration (Message from Vint Cerf)

11:05 User Friendly Naming/String Representation of DN (OSI-DS 
23.1, 24.1)

11:30 The QOS Experiment (OSI-DS 15) Russ Wright, Tim Howes

11:40 Report on JPEG Progress (Russ Wright)

11:25 Character Sets (OSI-DS 32) Geir Pederson

11:40 Counting the DIT (OSI-DS 30) Steve Hardcastle-Kille

11:50 Date of next meeting

11:55 AOB

12:00 Lunch

13:30 Difficulties with RFC 1274 approach to schema

13:45 New approach: Document restructuring + reorganization 
(possible new WG)

14:15 Schema Publishing

14:30 New attributes for DSA objects (Erik Huizer presenting a 
message from Paul-Andre Pays)

14:35 Detailed work on new attributes for RFC 1274

15:30 Tea

16:00 DNS and X.500: progress on RFC 1279 (Wengyik Yeong)

16:20 Relationship to CAT (Common Authentication Technology) 
(John Linn)

16:45 Lightweight directory protocols
		LDBP - Yeong, Howes, Hardcastle-Kille (OSI-DS 26, 27)
		SOS - Hardcastle-Kille (OSI-DS 31)

17:30 DSA Naming (OSI-DS 13)

18:00 Close