draft minutes OSIDS-Houston 4/11/93
Glenn Mansfield <glenn@aic.co.jp> Fri, 05 November 1993 00:38 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07287; 4 Nov 93 19:38 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07283; 4 Nov 93 19:38 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa25515; 4 Nov 93 19:38 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.05985-0@haig.cs.ucl.ac.uk>; Fri, 5 Nov 1993 00:29:04 +0000
Received: from aic-wide.aic.co.jp by bells.cs.ucl.ac.uk with Internet SMTP id <g.09779-0@bells.cs.ucl.ac.uk>; Fri, 5 Nov 1993 00:28:22 +0000
Received: by aic-wide.aic.co.jp (4.1/2.7W) id AA05385; Fri, 5 Nov 93 09:09:12 JST
Date: Fri, 05 Nov 1993 09:09:12 -0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Glenn Mansfield <glenn@aic.co.jp>
Return-Path: <glenn@aic.co.jp>
Message-Id: <9311050009.AA05385@aic-wide.aic.co.jp>
To: osi-ds@cs.ucl.ac.uk
Subject: draft minutes OSIDS-Houston 4/11/93
Hi folks!
Following are the minutes of the OSIDS meeting of 4/11/93 held at Houston.
Please add modify delete as necessary.
Cheers
glenn
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Minutes of OSI-DS IETF-MEETING at Houston
4th November 1993.
=================
Agreement on Agenda.
Minutes of Amsterdam: Approved.
Action Items from Amsterdam
o Schema maintenance and Distribution:
Sri: Will be discussed tomorrow
o OSI-DS-36 & OSI-DS-37 to be Progressed to RFCs
Glenn: I-D has been submitted
o OIDs for RFC1279 will be announced:
Glenn: Revised proposal will tabled today
Roll CAll:
List of attendees: to be attached.
Roland: DSA preformance Study.
================================
* DSA performance Statistics are being circulated by Leggenhager regularly. But this
study is based study of the logs.
Reachability:
============
* level-0 DSAs
o Percentage of success vs Number of Attempts.
More Seldom a DSA is accessed the greater the probability of reaching it.
* level-0 DSAs
o Level-1 DSAs: some DSAs can never be reached.
This is where the real data is.
* Some 50% is working very badly while the other 50% are working very well.
EDB-updates of root cn=Giant [Sep 1993]
* Takes some time for all DSAs to get updated ( > 2 days )
Some people carry out updates every 10 minutes. Some do it on a daily basis. So if one
update fails/ connection is missed , it takes 48 hours for the update to go thru.
EDB updates of c=CH from cn =chinchilla, [Aug 1993].
* All updates are done by by 10 hours. Much better scene.
* Update speed and time betwwen information changes.
When some things happen a lot of things follow.
o NL has ~ 100 updates / month [max]
A slave DSA did one update in 2 months during which 90 changes occurred.
Erik:
What are the reasons ?
o Wrong implementation ?
o Negligence ?
o Bad Configuration ?
Roland:
Peoples Ignorance
In some case the nature of the information is important. Thus one has to be careful
Steve:
Are there any messages for
o Implementors?
o Service Providers
Roland;
Reachability cant be helped
A reasonable time should be set for slave updates.
- atleast for country DSAs
Sri:
A particular DSAs unreachablilty does not imply the unreachablilty of the related DIT-
for c=US there is a master and two slaves.
Would like to share the tools used in this study.
Hedgberg:
Will post the tools to the list.
CLDAP, Steve
============
Connectionless protocol for retrieving names [ something more similar to DNS]
from the directory.
It is an important element for deploying the directory - should be moved
speedily to proposed standard.
General agreement - by show hands.
Erik:
A similar proposal has been discussed by Christian. Similar in functionality.
But has not put on paper.
Steve:
We will proceed as if there is no other document. If Christian's document
appears and a if it becomes necessary - we will review the present CLDAP
document in that light.
Both CLDAP and Christian's proposal are LDAP-compatible.
Comments:
What if one needs authentication?
Steve:
LDAP will be used.
A period of 2-3 weeks will be allowed for electronic discussion. After that, if
there are no comments/changes and if there is no review requirement in the light
of the document which Christian may issue - then the document will be moved to a
proposed Standard.
The above resolution was approved by a show of hands.
Networks in the Directory, Glenn
================================
* OSI-DS 37/38 present status
o I-D has been in circulation since 7/9/93
-draft-ietf-osids-chart-network-dir-00.txt
:explains the necessity of network maps
and its possible uses
-draft-ietf-osids-ipinfo-x500-dir-00.txt
:contains the schemas for representing IP-networks
in the Directory
o so far, no negative response/comments on mailing list or via
personal mail (and few positive ;-)
o experiments/implementations are being carried out at several sites
o waiting on WG action
* deployment strategy for Directory in the Internet
o document highlights :
- issues
- bootstrapping
- DIT structure
- relationship to existing Directory
- deployment stages
o Status of deployment
- Network Information
- WHOIS
- DNS
Sri: Is the deployment document in circulation?
Glenn: It had been circulated in Amsterdam. Only minor changes to that.
Steve: Needs to made into a OSI-DS document.
* Network Information:
o applications based on this
-network maps for Configuration management.
-Connection trees
: useful in intelligent polling/fault mgmt
All from the directory.
-Softpages
: clients make use of X.500 in several stages
; get list of file-servers [Static-list/archie]
; get path to file servers [Static/traceroute]
; get attributes for computing cost of paths
[Static/ping]
; search for file that is being sought
[archie-server]
[presently, if the info is unavailable from X.500, alternate
sources/methods are used]
* JPNIC whois DB is in Progress
o WHOIS-DB --> X.500 mapping done
- translation is difficult -
Names do not match ...
Characters [ Kanji ] do not match
Multi-lingual attributes
- translation is in progress can be seen under
@c=JP@o=Japan Network Information Center@l=Registered
Organizations
o "register" schema is necessary
* DNS in the directory
o problems with present schema
- Improvements/Changes
+ DomainSOA object contains the SOA related detail
+ Object for each resource record type
+ Object DNSMailBox for the mailbox info is a
subclass of top [ unlike in RFC1279]
- plan Circulate Draft by November end.
Commence deployment by December end.
* Application Support
o NTP
- Configuration of the NTP tree
- Query the directory to find out possible peers
o WWFS
- Configuration of the file system
- Good choice from the users point of view
o Other maps .
Steve: Has a document been written on this?
Glenn: We are in the process of preparing the document.
* Operational issues
o real life applications are starting
o reliability of DSAs has to be improved
o in case of problems due to other domains ...
- Complain privately to the responsible person for the domain.
- Complain publicly to the responsible person for the domain.
- Complain to the parent domain authorities.
- Ask the parent authorities to excommunicate the domain.
[Quote from RFC1033]
Steve: It is important that a operations guide be drawn-up
Glenn: We have been working on it- presently it is an image of the DNS
dministrators Guide. Will be posting the first draft on the list for
discussion.
Steve: The two I-Ds
draft-ietf-osids-chart-network-dir-00.txt and
draft-ietf-osids-ipinfo-x500-dir-00.txt
wil be moved to Experimental RFCs
Resolution accepted with a show of hands.
[Erik needs to be cummunicated over e-mail]
House open for Discussion on Future Directions of IIIA.
=========================================================
- draft minutes OSIDS-Houston 4/11/93 Glenn Mansfield