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