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.
=========================================================