This is only a rough draft - Megan 04/15/92
Here are the revised minutes. Note the action list.
Steve
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
Attendees:
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. Subsequent to the meeting, Rich did
distribute the OIW document list. It is appended here.
Other items of business were to be discussed as specific points on the
agenda.
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
emerged.
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 replication 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 December.
NADF: Einar Stefferud reported that the pilot proposed for 2/92 is
"underway", with all NADF members participating. Due to agreements
between NADF members, a "utopian" view of the pilot will be presented
to the world outside the NADF in that no details will be discussed as
to which pilot member is doing what. 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 Stef, 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 was being run as a registration tree, so that
the WPP had to be the national registration authority for c=US by
virtue of holding the c=US MASTER. While none of the principals ever
claimed to be the US registration authority per se, we just ended up
doing that as a consequence of the registration model. It was pointed
out that these assumptions were necessary for early deployment.
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 demonstration of the Directory at the recent
Networkshop which attracted considerable interest, and as resulted
in 3 more AARNet members joining the pilot.
The demonstration 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 - Three commands are being developed at PSI. x5ftp is under
development. x5rfc is done, development-wise, but is awaiting on
x5ftp for release of both to assure no changes to x5rfc due to a
problem discovered in x5ftp. usconfig is done and released. It
should be in future ISODE releases (it's basically the core of the
wpp-addon stuff right now).
MERI<T - 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 developing a Macintosh DUA (maX.500, by Mark
Smith). This isn't related to FOX in terms of funding or anything.
The connection with FOX is that Merit, a FOX member, likes it and has
been helping to promote it.
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: According to Wengyk, the transition to the NADF naming
scheme is going unusually slowly due to opposition/apathy on the part
of pilot project members. There are 91 organizations in the pilot
now. Operationally, heavy use of the wp.psi.net machine reported;
this appears to be causing the 'dad' server to fail sporadically.
Also, as a result of heavy use of wp.psi.net, an auxiliary DSA
"c=US@cn=Horned Frog" was created to be the service DSA on wp.psi.net.
So the "Fruit Bat" DSA is now back to being a c=US (and other things)
slave only. During Wengyk's report, 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 RFC 1295. Each word of the Bill of
Rights has been lovingly crafted to say exactly what it says, nothing
more and nothing less. 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
against.
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
meeting.
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
charges.
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
narrowed.
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.
Steve Hardcastle-Kille will reread NADF-175, to help determine what
can be done, while Wengyk will continue to work on the
interoperability issues between the NADV and WPP pilots.
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 Hardcastle-Kille will post the resulting
documents.
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 Tim Howes volunteered to
write some quipu syntax handlers for the counting attributes. He did
not volunteer to change quipu to make use of these features, but would
be willing to at least look into that.
I think that was me, and I volunteered to write some quipu syntax
handlers for the counting attributes. I did not volunteer to change
quipu to make use of this stuff, but I'd be willing to at least look
into that.
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 Smith 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
directories.
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. Steve noted that the flexibility present in the
current draft of RFC1279 is due to similar flexibility in the DNS RFCs
themselves (which allow different orderings for TTL, Class and Type).
Steve and Wengyk took an action item to find out why such flexibility
exists in the DNS.
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.
During the wrapup of this discussion, some open questions were posed.
Can we make o=Internet the final resting place for the DNS tree in the
DIT? It was felt that the group had consensus on this issue, and that
the answer is "yes".
Can we load up all the top level domains (from DNS) without explicit
consent from domain owners? With reference to the discussion of zone
transfers below, the consensus was that the answer to this question is
"yes".
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
SHOULD BE NOTED AS LEADING TO POTENTIAL HARM.
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
RDN.
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 CAT 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
matching).
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). The (optional) streaming approach is
incompatible with X.400/X.500 security issues (because access to the
full PDU is required) -- this is fundamental.
Steve Hardcastle-Kille hasn't looked at related OSI work
on application environments and on 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.
ACTIONS
1) Huizer. Produce revised strategy document by the end of April
2) Weider. Revise OSI_DS 14, 16, 17, 19 in light of meeting and offline
discussions
3) Hardcastle-Kille. Revise OSI-DS 12, and subit to IESG as proposed
standard.
4) Hardcastle-Kille. Submit OSI-DS 24 to IESG as experimental.
5) Hardcastle-Kille. Revise OSI-DS 23, and submit to IESG as proposed
standard.
6) Hardcastle-Kille. Review NADF 175 in light of Rose's comments.
7) Yeong. Study issues of NADF / WPP interoperability.
8) All. Continue QOS experiment.
9) Schema Group. Sort out JPEG Schema.
10) Geir Pederson et al. Start Character set experiemnt.
11) Howes. Provive DIT Counting Syntax Handlers.
12) All (?). Start DIT Counting experiemnt.
13) Barker. Establish Schema Group.
14) Howes/Smith. Write OSI-DS note on Schema Publishing
15) Schema Group. Record decision on preferred name.
16) Pays. Write OSI-DS note on storing lmiti information in the DIT
17) Hardcastle-Kille. Revise RFC 1279 in consultation with Yeong.
18) All. Contine DNS in X.500 experiment.
19) Yeong/Howes/Hardcastle-Kille. Revise LDBP note.
20) Hardcastle-Kille. Examine ISO proposed alternatives to SOS.
Appendix: Agenda for the Meeting
--------------------------------
Agenda for seventh meeting of
IETF Directory Services Group
Version 3
S. E. Hardcastle-Kille
March 12, 1992
Date
Monday 16th March 1992
Time
09:30-19:00
Venue
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 ISO/CCITT
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
Appendix: OIW Documents
-----------------------
The output of the NIST Workshop for Implementors of OSI (OIW) is a pair
of aligned documents, one representing Stable Implementation Agreements
(SIA), the other containing Working Implementation Agreements (WIA)
that have not yet gone into the stable document. Material is in either
one or the other of these documents, but not both, and the documents
have the same index structure.
The SIA is reproduced in its entirety at the beginning of each calendar
year, with an incremented version number. Replacement page sets are
distributed subsequently three times during each year (after each
Workshop), reflecting errata to the stable material, as well as new
functionality declared stable. In this way an up-to-date document is
maintained.
Retrieving OIW Documents
------------------------
The documents are available from osi.ncsl.nist.gov via anonymous ftp
(129.6.48.100) or anonymous ftam: user = anon, realstore unix,
osi.ncsl.nist.gov filestore NULL \
#1/#1/#1/NS+47000580005a0000000001e137080020079efc00
All documents are in the directory:
./pub/oiw/agreements
The read_me file from the directory is reproduced below, followed by
a listing of the directory.
READ ME FILE FOR STABLE DOCUMENT FILES
The files listed as Xs-9112.w51 and Xw-9112.w51 (X goes
from 01 through 25) are all wordperfect 5.1 files. For
wordperfect 5.1 files to properly print out parts, you
will need Helvetica fonts ranging in size from 8pt through
30pt. You will also need these sizes in regular, bold and
italic since a mixture of all of these was used to
wordprocess the files.
The files listed as XW-9112.asc and XS-9112.asc (X goes from
01 through 25) are all ascii files.
All the Parts of the Stable Agreements document are on-line
and the file is called stable-out.All.Z for ASCII.
All the Parts of the Working Agreements document are on-line
and the file is called work-out.all.Z for ASCII.
It is called Stable_w51.All.Z for all wordperfect 5.1 Stable files.
It is called Work_w51.All.Z for all wordperfect 5.1 Working files.
total 21593
-rw-rw-r-- 1 gray 17100 Feb 11 16:08 01S-9112.asc
-rw-rw-r-- 1 gray 51675 Feb 13 12:21 01W-9112.asc
-rw-rw-r-- 1 gray 67726 Feb 14 08:57 01s-9112.w51
-rw-rw-r-- 1 gray 176037 Feb 14 08:25 01w-9112.w51
-rw-rw-r-- 1 gray 46005 Feb 11 16:08 02S-9112.asc
-rw-rw-r-- 1 gray 24774 Feb 13 12:21 02W-9112.asc
-rw-rw-r-- 1 gray 139720 Feb 14 08:55 02s-9112.w51
-rw-rw-r-- 1 gray 115378 Feb 14 08:25 02w-9112.w51
-rw-rw-r-- 1 gray 60063 Feb 11 16:08 03S-9112.asc
-rw-rw-r-- 1 gray 18935 Feb 13 12:21 03W-9112.asc
-rw-rw-r-- 1 gray 161818 Feb 14 08:55 03s-9112.w51
-rw-rw-r-- 1 gray 87944 Feb 14 08:25 03w-9112.w51
-rw-rw-r-- 1 gray 41799 Feb 11 16:08 04S-9112.asc
-rw-rw-r-- 1 gray 13457 Feb 13 12:21 04W-9112.asc
-rw-rw-r-- 1 gray 118101 Feb 14 08:55 04s-9112.w51
-rw-rw-r-- 1 gray 69449 Feb 14 08:25 04w-9112.w51
-rw-rw-r-- 1 gray 81088 Feb 11 16:08 05S-9112.asc
-rw-rw-r-- 1 gray 45874 Feb 13 12:22 05W-9112.asc
-rw-rw-r-- 1 gray 252241 Feb 14 08:55 05s-9112.w51
-rw-rw-r-- 1 gray 147423 Feb 14 08:26 05w-9112.w51
-rw-rw-r-- 1 gray 35646 Feb 11 16:08 06S-9112.asc
-rw-rw-r-- 1 gray 6029 Feb 13 12:22 06W-9112.asc
-rw-rw-r-- 1 gray 97122 Feb 14 08:56 06s-9112.w51
-rw-rw-r-- 1 gray 53154 Feb 14 08:25 06w-9112.w51
-rw-rw-r-- 1 gray 340675 Feb 11 16:08 07S-9112.asc
-rw-rw-r-- 1 gray 1933 Feb 13 12:22 07W-9112.asc
-rw-rw-r-- 1 gray 582326 Feb 14 08:56 07s-9112.w51
-rw-rw-r-- 1 gray 35312 Feb 14 08:25 07w-9112.w51
-rw-rw-r-- 1 gray 600656 Feb 11 16:09 08S-9112.asc
-rw-rw-r-- 1 gray 54891 Feb 13 12:22 08W-9112.asc
-rw-rw-r-- 1 gray 975055 Feb 14 08:57 08s-9112.w51
-rw-rw-r-- 1 gray 250608 Feb 14 08:26 08w-9112.w51
-rw-rw-r-- 1 gray 194478 Feb 11 16:09 09S-9112.asc
-rw-rw-r-- 1 gray 3280 Feb 13 12:22 09W-9112.asc
-rw-rw-r-- 1 gray 448585 Feb 14 08:56 09s-9112.w51
-rw-rw-r-- 1 gray 59946 Feb 14 08:25 09w-9112.w51
-rw-rw-r-- 1 gray 95424 Feb 11 16:09 10S-9112.asc
-rw-rw-r-- 1 gray 4579 Feb 13 12:22 10W-9112.asc
-rw-rw-r-- 1 gray 230168 Feb 14 08:54 10s-9112.w51
-rw-rw-r-- 1 gray 44294 Feb 14 08:25 10w-9112.w51
-rw-rw-r-- 1 gray 252517 Feb 11 16:09 11S-9112.asc
-rw-rw-r-- 1 gray 40532 Feb 13 12:22 11W-9112.asc
-rw-rw-r-- 1 gray 561651 Feb 14 08:57 11s-9112.w51
-rw-rw-r-- 1 gray 182159 Feb 14 08:26 11w-9112.w51
-rw-rw-r-- 1 gray 66510 Feb 11 16:09 12S-9112.asc
-rw-rw-r-- 1 gray 64311 Feb 13 12:22 12W-9112.asc
-rw-rw-r-- 1 gray 192599 Feb 14 08:58 12s-9112.w51
-rw-rw-r-- 1 gray 198426 Feb 14 08:25 12w-9112.w51
-rw-rw-r-- 1 gray 2145 Feb 11 16:10 13S-9112.asc
-rw-rw-r-- 1 gray 2324 Feb 13 12:23 13W-9112.asc
-rw-rw-r-- 1 gray 38029 Feb 14 08:54 13s-9112.w51
-rw-rw-r-- 1 gray 37338 Feb 14 08:25 13w-9112.w51
-rw-rw-r-- 1 gray 225744 Feb 11 16:10 14S-9112.asc
-rw-rw-r-- 1 gray 32025 Feb 13 12:23 14W-9112.asc
-rw-rw-r-- 1 gray 443144 Feb 14 08:56 14s-9112.w51
-rw-rw-r-- 1 gray 109145 Feb 14 08:26 14w-9112.w51
-rw-rw-r-- 1 gray 1975 Feb 11 16:10 15S-9112.asc
-rw-rw-r-- 1 gray 2305 Feb 13 12:23 15W-9112.asc
-rw-rw-r-- 1 gray 36157 Feb 14 08:57 15s-9112.w51
-rw-rw-r-- 1 gray 46831 Feb 14 08:24 15w-9112.w51
-rw-rw-r-- 1 gray 2614 Feb 11 16:11 16S-9112.asc
-rw-rw-r-- 1 gray 2543 Feb 13 12:23 16W-9112.asc
-rw-rw-r-- 1 gray 36998 Feb 14 08:58 16s-9112.w51
-rw-rw-r-- 1 gray 36662 Feb 14 08:26 16w-9112.w51
-rw-rw-r-- 1 gray 2614 Feb 11 16:11 17S-9112.asc
-rw-rw-r-- 1 gray 2415 Feb 13 12:23 17W-9112.asc
-rw-rw-r-- 1 gray 37058 Feb 14 08:58 17s-9112.w51
-rw-rw-r-- 1 gray 36563 Feb 14 08:25 17w-9112.w51
-rw-rw-r-- 1 gray 141062 Feb 11 16:11 18S-9112.asc
-rw-rw-r-- 1 gray 272358 Feb 13 12:23 18W-9112.asc
-rw-rw-r-- 1 gray 376270 Feb 14 08:54 18s-9112.w51
-rw-rw-r-- 1 gray 406922 Feb 14 08:27 18w-9112.w51
-rw-rw-r-- 1 gray 1875 Feb 11 16:11 19S-9112.asc
-rw-rw-r-- 1 gray 2055 Feb 13 12:23 19W-9112.asc
-rw-rw-r-- 1 gray 35990 Feb 14 08:54 19s-9112.w51
-rw-rw-r-- 1 gray 36295 Feb 14 08:26 19w-9112.w51
-rw-rw-r-- 1 gray 49887 Feb 11 16:12 20S-9112.asc
-rw-rw-r-- 1 gray 124978 Feb 13 12:23 20W-9112.asc
-rw-rw-r-- 1 gray 165644 Feb 14 08:54 20s-9112.w51
-rw-rw-r-- 1 gray 354002 Feb 14 08:25 20w-9112.w51
-rw-rw-r-- 1 gray 1810 Feb 11 16:12 21S-9112.asc
-rw-rw-r-- 1 gray 2122 Feb 13 12:24 21W-9112.asc
-rw-rw-r-- 1 gray 35559 Feb 14 08:55 21s-9112.w51
-rw-rw-r-- 1 gray 35578 Feb 14 08:25 21w-9112.w51
-rw-rw-r-- 1 gray 155231 Feb 11 16:12 22S-9112.asc
-rw-rw-r-- 1 gray 2477 Feb 13 12:24 22W-9112.asc
-rw-rw-r-- 1 gray 342779 Feb 14 08:55 22s-9112.w51
-rw-rw-r-- 1 gray 52038 Feb 14 08:25 22w-9112.w51
-rw-rw-r-- 1 gray 86698 Feb 11 16:12 23S-9112.asc
-rw-rw-r-- 1 gray 2468 Feb 13 12:24 23W-9112.asc
-rw-rw-r-- 1 gray 231719 Feb 14 08:55 23s-9112.w51
-rw-rw-r-- 1 gray 52060 Feb 14 08:26 23w-9112.w51
-rw-rw-r-- 1 gray 1980 Feb 11 16:12 24S-9112.asc
-rw-rw-r-- 1 gray 6233 Feb 13 12:24 24W-9112.asc
-rw-rw-r-- 1 gray 36651 Feb 14 08:54 24s-9112.w51
-rw-rw-r-- 1 gray 50121 Feb 14 08:26 24w-9112.w51
-rw-rw-r-- 1 gray 1949 Feb 11 16:12 25S-9112.asc
-rw-rw-r-- 1 gray 1811 Feb 13 12:24 25W-9112.asc
-rw-rw-r-- 1 gray 35970 Feb 14 08:56 25s-9112.w51
-rw-rw-r-- 1 gray 35861 Feb 14 08:26 25w-9112.w51
-rw-rw-r-- 1 gray 8388626 Feb 14 09:18 Stable_w51.All
-rw-rw-r-- 1 gray 710289 Feb 14 08:31 Work_w51.All.Z
-rw-rw-r-- 1 gray 956 Apr 8 09:06 read_me
-rw-rw-r-- 1 gray 621767 Feb 13 08:36 stable-out.All.Z
-rw-rw-r-- 1 gray 205851 Feb 13 12:27 work-out.all.Z