| C A R T E L / 9 7
   | - - - - - - - - -
   |
   | University of Michigan, Ann Arbor
   | June 24-25th, 1997
 


Meeting notes from June 25th -- afternoon

(from Scott Brylow, Stanford - edited by Gavin Eadie, UMich)

 

Directories and LDAP conformance issues - Charles Antonelli of UM

Compliance testing with LDAPv2 with big vendors he can't name. But big vendors. Small test suite of obvious functional tests. Will use their clients to connect to UM server with UM database server with fake data for privacy reasons. If you read LDAPv2 RFC, it's weird to write tests to it. Most of work was not technical, it was negotiating about interpretation of RFC. No solid plans for LDAPv3. All work sponsored by Network Applications Consortium. Banded together to bring some commonality to the distributed naming world.

Scott covers scripting and database stuff, ecommerce, caching, tools, webauth)

WWW Utilization

WWW Infrastructure

Legacy system migration

Authentication

UM sells the ability to depts and makes sure they don't break stuff. By

hand checking, nothing clever.

Not responsible for

Auth methods -- KLP and NS cookie-based. Biggest technical hurdle.

UM going to Apache

CMU using Apache for some stuff but not for some AFS stuff. They have a server that does some caching

UM split personal and departmental in Jan 95.

Local proxy on client that does all encryption then done as a plugin.

www-personal/~dugsong/kapache/

 

Staffing and Project Management:

Last year this was on the agenda cuz of concerns about staff retention --

CMU got raided in networking last year, down to 2, now the group is very junior.

Understaffing at CMU meant that they couldn't innovate, they could only maintain. Then things got boring cuz they were only maintaining -- people got tired of that and left for the intellectual challenges.

Stanford loses people to startups cuz of their location. Pay we can't meet. Stock options we can't meet. Intellectual challenges at startups are exciting.

MIT shortened the hiring time. Stanford did this last year. This is important.

MIT has competency groups, and business process groups, all headed by directors. 2 of their competency directors left in the last few weeks.

UM suffered in many of the same ways in the last 12-16 months. Loss of a bunch of senior people. Loss of technology knowledge, and ways to work the system knowledge. Mostly left for intellectual challenge.

At end of HR spectrum, difficulty coming in and learning the business. You can find a better salary. Benefit package isn't as attractive to younger folks.

Peter says UM inherited a bunch of process from MIT. Process reengineering stuff, to the exclusion of individuals and their talents. Metrics are not useful enough. Reward structure based on a checklist of things that aren't the most relevant. Lost in the process is the ability to reward people for hard work, good performance, loyalty, reliability. Values gap between himself and his mgmt. Suits don't understand R&D.

Cornell lost some folks last year. Rehiring is slow, no major city near Cornell as a asource of people

Talked about management stuff for a while, I talked so I didn't take great notes.

 

What do people think of Java??

Stanford - Craig likes it. Stanford is developing a bunch of gateway services in Java. Pleasure to write general purpose translators (ie whois to ldap). Lots of server stuff, haven't really looked into client desktop stuff, mostly cuz Oracle will do a lot of that and they won't deliver any Java stuff any time soon.

MIT position of arch. Group is to avoid Java. Not usually considered for the server side. Wanted to use it on the desktop. Need ifdefs to have it work everywhere. Not ready for prime time. Too slow. Not enough advantages.

Scott said he had success with his old development team.

CMU is starting to use it, just did a quick thing in it in a day or so instead of Tk.

MIT did an SMPP translator in Java.

UM undergrad Nate is using it for db that tracks site's inventory and enter DHCP and DNS info at all sites. Doing a Java based Web interface. Using klp plugin. Can query from Java not using JDBC to an Oracle DB (don't want to have to install JDBC on clients, so it is 2 tier instead of 3 tier. All SQL is in stored procedures)

 

Sharing Experiences / Joint Work issues?

NT client from Transarc is too expensive (remember to look at exsting agreement and see if it can be construed to mean that they need to give us the NT client source code now).

This group has no mechanism for funding work but the Common Solutions Group does (CSG) and we are all members of CSG. Not sure that we are allowed to give code away to other members. You can give them to Transarc, who (we think) are obliged to redistribute it. Paul from MIT is lead on this since they have to talk to Transarc anyway.

Kclient API - Paul working on first issue

Taking Windows version of Kclient and make API look more similar to existing Mac version. CMU said they would be willing to talk to Stanford.

Cornell guy has permission to keep a toe in and make sure that we don't end up with yet another version of this. Mike (Cornell) will track this but not write code. Does Cornell have existing doc showing API for Mac and for Windows? Only for Windows, 5-10 calls. Only functionality it has is 'gimme ticket' while the Mac version has 70-80 calls. Let's you do nifty telnet, etc.

Universal backup system from CMU. If there are people who have ideas or want to help, let Jeff know. They don't have any doc yet to describe it, so if you are interested you should talk to Jeff. When he has a document, he will get it added to the Cartel pages or sent to the Cartel list. Make sure that Jeff is on the Cartel mailing list.

Merging Umich plugin stuff with CMU plugin stuff. They will talk

NTGinas - Dave Detlafs of UM raised this. For people writing GINAs in NT environments, good to know what others are doing. Mailing list is a good idea, or even Cartel list if it's low-traffic (which is probably good)

Java wrapper for K DLL noted by Stanford as something that is ongoing and being tracked.

Any place where throw weight can be brought against a particular vendor?

We agree that we should communicate before we try anything on our own. MIT had users asking for strange software while using the Exchange. Got source for an MS DLL but haven't had time to work on it yet. MS gave MIT a significant portion of the Exchange code to give them the DLL.

Sharing project databases of the various schools. Is there a formal way to share project databases.

Subwoofer - Apple thing relating to CyberDog - I missed exactly what. Want to create reference code.

CMU - concept of some sort of central auth service. Many things need to do the "Is this person a member of such and such a group?" Concept of "roles" - not only member of a group, but in what capacity are they a member of the group -- student vs. staff, etc. Jeff doesn't know what he's asking for here, but he'd like to see at least a design for something. First, nail down what the requirements are.

CMU monitoring system with an X console. So, if you have an ops staff, they can be more useful. Adding monitoring functions.

Work collaboration

Mac Klist will be reactivated and subscription info will be sent to Cartel list.

 

WRAP UP.

Let Tom talk about next year at MIT.

 

Comments:

Steve UM - oatmeal cookies

Peter UM - assign work at a different time, not when everyone is tired.

Dug - less time at mgmt

Walter - individuals to lead specific topics, less burden on one organizer

CMU - pass

CMU - bigger room

Marshall MIT - separate into tracks

Paul - try to get people to write up info about sites.

Erikas - more networking related

Frank - pass

Jenny - pass

Jonathan MIT - fewer negatives

Bill UM - should have been here more

Mike Cornell pass

Joe UM pass

Mark Poepping - get people to write up info

Dave Detlaf UM - liked meeting people

Jeff CMU - more time unstructured.

Craig - connectivity was great. Logistics was great. Active moderator was good. Munged site report (by topic rather than by school).

Scott - smaller more focused groups, make sure that people have read the project info before they get here.