gopher@extro.ucc.su.oz.au (John McQueen) (04/11/90)
I guess these questions are directed to all those DSA managers out there. How serious are you about running quipu? Is it just something that you got for free compiled - it worked so you put a bit of data in and connected up - or are you a bit more serious about maintaining a proper directory. I.e. keeping all the information up to date and complete. I know George Michaelson at the University of Queensland (Australia) seems to have the entire payroll of the university loaded up. Here at Sydney University we are a bit unsure as to how far to go with it. Whether to suggest to the admin people they use it for maintaining their phone book, or just let things go along and let our data go slowly out of date. My personal thoughts are that if we are going to do this then me may as well do it properly, and each organization make some sort of commitment in money/manpower to maintaining an uptodate complete directory. What are other peoples thoughts on this? John McQueen -- ________________________________________________________________________ John Scott McQueen | gopher@extro.ucc.su.oz.au University Computing Service, H08 | Phone: +61 2 6923495 University of Sydney, NSW 2006, Australia | FAX: +61 2 6606557
sean@DSL.PITT.EDU (Sean McLinden) (04/11/90)
> How serious are you about running quipu? > > Is it just something that you got for free compiled - it worked > so you put a bit of data in and connected up - or are > you a bit more serious about maintaining a proper directory. I.e. > keeping all the information up to date and complete. I am, perhaps, not the best person to be answer this since our reasons for running the pilot software had more to do with exploring applications of X.500 services, but... We (University of Pittsburgh), have roughly 2000 entries in our DSA. This represents less than 10% of the total number of accounts supported on our various systems. The difficulties with doing as you suggest are: 1. The lack of any real applications software which would provide an incentive for mainitaining an uptodate database. For example, if WP could be used to maintain the University's campus telephone directory. The PP and MH mail systems might provide just the incentive just as the Andrew White Pages is used by the Andrew Message Delivery System. 2. The lack of integration into Unix accounts management software. We have users with many accounts over many systems, some of which have different names, many of which contain inaccuracies. Since there is no real central accounts management for many of the research systems, detecting aliases, duplicates and things can be quite difficult. Given the number of variations on Unix password files, it is non-trivial to even parse these into meaningful DSA entries. 3. Occasional quirks of the code. The organization of the pilot is such that the master DSAs actually edit (copy) data into the local EDBs. This isn't much of a problem as long as the system continues to run but a quirky memory error on the DECStation 3100 causes our DSA to crash once every 18 hours or so. When it goes to reload, it cannot restart the DSA because of errors in the EDB files. We workaround this by keeping copies of our startup EDB files, and restoring those prior to restarting QUIPU, but this is suboptimal. To be fair, it has been a mammoth effort for the ISODE and QUIPU developers to have gotten the code even to this state; a remarkable accomplishment. But the software is still too experimental for many institutions to consider running as a reali world appliction. > My personal thoughts are that if we are going to do this then me may > as well do it properly, and each organization make some sort of > commitment in money/manpower to maintaining an uptodate complete > directory. Agreed. But the problem is justifying the money and manpower. I don't know how things work in your institution, but I know that in mine, some of the most useful packages (GNU emacs and gcc, X, ISODE, TeX), were installed, developed, and maintained by people who did it, not because they were paid to do it, but because they were interested. It was popularity of use that convinced administration to spend money on support. Even then, it was a long time in coming and the funds were never what we would like them to be. In the real world, it is *very* difficult to find money to support experimental software. Personally, I think that those types of activities are why Universities exist, but the distinction between Academia and Industry is becoming smaller and smaller with each year. We don't have the luxuries that we did, even 5 years ago. Sean McLinden Decision Systems Laboratory University of Pittsburgh
vcerf@NRI.RESTON.VA.US (04/11/90)
Mr. McQueen, Speaking for the IAB, may I encourage everyone who is in a position to create an X.500 database to press ahead seriously with plans to populate and maintain it. We have an unquestioned need for email white pages capability. Whether one uses QUIPU or another X.500 implementation is less relevant that getting X.500 facilities into place in the Internet. Centralized databases, except perhaps those maintained by public email carriers, have a tendency to get out of date despite the best efforts of the maintainers. By distributing the system and bringing it closer to each user's email host, we hope to improve the quality and longevity of these databases. Vint Cerf
schoff@PSI.COM ("Martin Lee Schoffstall") (04/11/90)
John, nysernet/psi have a pilot whitepages service that has the "payrolls" of over 40 organizations in it, including universities, commercial organizations, and government agencies. There are approaching 200,000 entries throughout the various DSA's which are all quipu based. If you want to exercise it telnet/rlogin into wp.psi.com and login as "fred". There is both an ascii oriented and a X11 base user agent to run there. Marty ----------- I guess these questions are directed to all those DSA managers out there. How serious are you about running quipu? Is it just something that you got for free compiled - it worked so you put a bit of data in and connected up - or are you a bit more serious about maintaining a proper directory. I.e. keeping all the information up to date and complete. I know George Michaelson at the University of Queensland (Australia) seems to have the entire payroll of the university loaded up. Here at Sydney University we are a bit unsure as to how far to go with it. Whether to suggest to the admin people they use it for maintaining their phone book, or just let things go along and let our data go slowly out of date. My personal thoughts are that if we are going to do this then me may as well do it properly, and each organization make some sort of commitment in money/manpower to maintaining an uptodate complete directory. What are other peoples thoughts on this? John McQueen -- ________________________________________________________________________ John Scott McQueen | gopher@extro.ucc.su.oz.au University Computing Service, H08 | Phone: +61 2 6923495 University of Sydney, NSW 2006, Australia | FAX: +61 2 6606557
alan@CURTA.CC.COLUMBIA.EDU (Alan Crosswell) (04/11/90)
> How serious are you about running quipu?
At Columbia University we've announced whitepages as an integral part
of our campus-wide "let's get everybody using electronic mail"
initiative. We have committed manpower and hardware to run the
directory. We are of course behind schedule with this initiative, so
the directory data is currently a bit stale (August '89) but no worse
than the printed campus phonebook. The actual flow of data from our
personnel system has been in production operation for quite some time
with updates weekly, but the updates have been collecting in an ingres
database waiting to be converted into EDB updates.
There have also been some performance problems due to our EDB
structure which I intend to experiment with (just like I said I was
going to do in my talk two Nysertech meetings ago:-).
So I guess that means we are pretty serious about it.
/akincl@IAG.HP.COM (Norman Kincl) (04/11/90)
Hewlett-Packard right now fits in the experimental stage of utilizing quipu. The group I work for uses the directory to maintain our mailing lists, so that portion (ou=Information Architecture Group) is complete and acurate. However, maintaining quipu is not part of my real job. At this point I am doing it because it is something that is important, even though only indirectly related to my work. Other level-2 DSAs have different objectives for what they have. My requirement before I connect them in to the DIT is that the data they have be correct, but not necessarily complete. One of the areas we are looking at is the proper access limitations to place on the data. Unfortunatly, quipu currently does not allow the full flexibility that we need. This will probably delay any attempts to fully utilize quipu throughout HP. -Norm
BEC@ALBNYVM1.BITNET (Ben Chi) (04/11/90)
On Wed, 11 Apr 90 13:58:39 +0100 John McQueen said (regarding the X.500 pilot): >. . . >My personal thoughts are that if we are going to do this then me may >as well do it properly, and each organization make some sort of >commitment in money/manpower to maintaining an uptodate complete >directory. . . I couldn't agree more strongly. The whole point of a >distributed< directory is so that the contributors of the various pieces could keep those pieces up to date. If this is not done, the whole project will ultimately fail, just as have a number of other attempts at "wide-area" directories, most of which were not nearly as well-con- ceived. We generate an entirely new EDB directly from the University's Personnel Database every month. I'd be interested what the practice other DSA managers in this connection.
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (04/12/90)
On 11 Apr 90 02:58:37 GMT you said:
>How serious are you about running quipu?
Here at Virginia Tech, we are quite serious about running quipu.
We are in the process of loading our entire personnel file into it,
and are putting into place mechanisms for timely update of the data
(Probably will be once-a-week updates for now, we are aiming for
real-time online updates in the future.
Eventually, we plan to have some 6,000 employee entries and some
23,000 student entries in our quipu database, and to use this as the
central "people" database for all functions.
One of our major problems is that we have a fairly large number of
locally defined attributes that we had to add to make it fly politically
(Using quipu as "just a phone book" didn't sell), and most of these
attributes have fairly long ACL lists defining which offices and
users can read/compare/etc the entry. The end result is that we end up
with 70-line EDB entries, 45 lines of which are ACL lists. It would be
*quite* helpful if it were possible to "default" an ACL list for a given
attribute, which would cut the size of our EDB entries down by literally 60%.
Steve Kille has informed me that he's considering the problem, but I
have no idea if/when we will see C code to implement a solution.
Valdis Kletnieks
Computer Systems Engineer
Virginia Techsollins@LCS.MIT.EDU (Karen R. Sollins) (04/12/90)
We have suggested to MIT that Quipu be used in place of the simple finger and forwarding service now provided. The response was that this could not be done until particular security problems were addressed and the solutions demonstrated to be trustworthy. MIT views its phone book and lists of students and employees as private, and access to them as an invasion of privacy. The MIT phone book is only available to the MIT community. One can call and get a specific phone number but not a list of them. The same sort of policy must be available in an electronic service. Access control lists generally restrict access to individual data items. What we need to be able to do is restrict certain operations on sets of data items. In vague terms we need to be able to limit the search operations or perhaps the results of a search to no more than a small number of objects, such as perhaps 2 or 3 or maybe 5. On the other hand, if we could demonstrate the viability of a security mechanism to their satisfaction, acquiring the "phone book" would pose no technical problem. This does not address the question of keeping the information up to date, but it could certainly be at least as up to date as the telecommunications office that provides phone assistance. Karen Sollins
ggm@brolga.cc.uq.oz (George Michaelson) (04/13/90)
gopher@extro.ucc.su.oz.au (John McQueen) writes: >I guess these questions are directed to all those DSA managers out there. >How serious are you about running quipu? Very. Having shifted from a department-pays-for-use system of networked and central computing resource usage to centrally funded "the network is infrastructure" models we badly need to get on top of a general information management problem. QUIPU fits the midterm bill well as an (albiet researchy but...) sufficiently robust version of something that we can point to and say to the infidels of management "look what we got to try and fix our problems" and other good noises. We'll stick with it until something better comes along, and I dont see anything looming on the horizon yet! >I know George Michaelson at the University of Queensland (Australia) >seems to have the entire payroll of the university loaded up. This is a bootstrapping exercise. getting enough data online quickly to justify further funding is a pain! Adding nicer info into this framework is taking time, primarily phonelists and /etc/passwd type info. I hoped to get some campus-context specific oid stuff together but I am very nervous of departing from globally meaningfull information models, and would LOVE to see what other people consider "useful" information types. One that springs to mind for us is: mapReference :gridlocation a la A-Z guide or numbered building map Since we want to see this used for more general "whois <x> and how do I find her" searches eg from S.U. refectory & library installed terminals. >Here at Sydney University we are a bit unsure as to how far to go with >it. Whether to suggest to the admin people they use it for maintaining >their phone book, or just let things go along and let our data go slowly >out of date. I am VERY nervous of taking so long that the data becomes stale. I'd figure anything that lags more than 3 months on the real world is getting dangerously old especially with the new PABX coming in (lotsa phone number changes) It is VERY tempting to "sell" QUIPU to mgt as the answer to their prayers, but when facing somebody(somecommittee?) that just spent $x000 on ORACLE or some other DB for MIS applications It can get a bit embarrassing. I personally DO want to try and get QUIPU wedded into the general staff appointements process (so that you are online from day #1 of your working (students comes later I suspect) life at UQ, if you use email or not) but I think I'm going to be moving a bit slowly towards this. I'd like to demonstrate an ability to handle plausibly complex information before I commit and I mean "manage" at the human level, I don't doubt QUIPU is up to it. Security of personal data looms large as a user-specified worry. Its one thing to choose to have your mugshot stored online, but getting it done by default scares the hell out of me. Ditto home address/phone info (yes its in the phonebook but you can't do fast context-sensitive searches through there unless VERY committed to chasing my (paranoid) tail) >My personal thoughts are that if we are going to do this then me may >as well do it properly, and each organization make some sort of >commitment in money/manpower to maintaining an uptodate complete >directory. Definitely. The exact level of funding is hard to pin down though... initial h/w costs locally we fudged by getting a good "porting" discount (thanks guys) but labour will FAR outweigh this if you add up: 1+ Database Manager 1 data entry team secretarial staff committee to manage above and integrate into general admin re-print stationary as longterm costs. You have to sell an increase in functionality rather than definite savings I think... well you can suggest email based comms is cheaper than paper, but the directory is only 1 facet of that argument. Its trying to sell MHS/networks WITHOUT a directory that doesnt make sense the all look to the net as a phone-like system and expect a directory to co-exist with the comms packages from day 1 (and I dont blame them! we must be crazy to accept a global net with no directory!) ...Not to mention help/docco/porting and fending off people who want you to run <xyz> product instead... (sigh) I did a report for the Qld state government computer centre on directory and naming issues in their network. I did a pretty cack-handed job of it, but one solid thing came out of it for me: You are walking on a LOT of sensitive feet when you try and structure a namespace and manage it longterm. Selling a specific package or system is not nearly as important as selling the IDEA of a managed namespace for ALL communications (you can interpret managed in any way you see fit including deliberate anarchy) and you are looking at a small to medium sized department which has to exist longterm for any body of more than trivial size. I personally favour taking QUIPU as a starting point and generating a good enough demonstrator to hand it over to somebody else for integration into the local system. I suspect I wind up selling my own org within the university as the body to manage it since nobody else is likely to take it seriously. The phone-net and even campus video people are already being softened for takeover by the campus computing body so this probably makes sense longterm. If we wind up using some mix of Kerberos-like and QUIPU for Information access and access control I'll be pretty happy. If we wind up with one single mechanism for both I'll be deliriously happy. Wanted: Cheap/free PC/MAC --->integrated<--- X.400 and X.500 tool. We already have back-ends for these. we need the user interface. Should preferably mask underlying server architecture (unix vs VMS) -George G.Michaelson Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 377 4079 Postal: George Michaelson, Prentice Computer Centre The University of Queensland, St Lucia, QLD Australia 4067.