Internet2 Middleware Initiative
Technical advisory meeting
13 & 14 April 1999
Identification of the issues
What's the concrete need for a middleware initiative? We seem to muddle along, doing interoperability with sending Word documents around. Why, also, do we need a national initiative? We need to make it work at home first, get our campus in order. The sense, though, is that we can do better than that. We can build an applications environment that's built on an infrastructure much more rich than sharing Word documents. And, we do need to get our campuses in order, but there are opportunities to help each other out with building that infrastructure. And, some campuses are ready to address inter-realm issues, and we can work those leading sites to be models for other institutions of higher education.
Are there things that we were already going to do on campus that with a little more work we could generalize and share?
Whatever we decide to do, we need to frame it in the benefits for the various communities: CIOs, presidents, developers, users, network administrators.
Performance is very important to the PACI community. Investments in Legion and Globus are what they think of when they think of middleware, helping researchers get access to computation resources. (Legion is still considered an experimental area.) In terms of numbers of users, the PACI world isn't huge scale. For example, there are tens of users at a time using NPACI resources.
NCSA Alliance and Globus priorities include directory services used to determine if you have the right compilers and libraries---providing a coherent way to make sense of the resources made available; security (SSL under GSSAPI); scheduling of resources (with its co-allocation challenges); and account management across different sites. Account management involves the steps of defining and creating accounts at different sites (managing /etc/password files and chargeback systems). Accounting for resources appeared to be a higher priority for the PACI teams than the campuses.
In terms of managing accounts and authentication, policy is the hardest challenge. In fact, many felt that mapping and merging policies is where we need to start.
A goal is to be able to ask for resources at a site and easily get access without having the resources needing to know where you are or you know where the resources are.
Getting the Campus in Order
Issues that need to be addressed on campus include a unique name space for campus resources. At Michigan, for example, they can use that to match Kerberos names to X.509 certifications, looking at having the X.509 certificates serve as session keys (with the Kerberos server signing the certificate). One action could be to define best practices for naming resources.
Trust and Risk Management
Security: We need to figure out how to manage multiple CAs as there won't be a single root CA for all of higher education's needs. That can be a work effort for us. We could also work on evolving GSSAPI, perhaps defining an ABI standard. GSS for Java is gathering steam on the IETF list. Some people are looking at IETF's GAA (Globus is going to hire someone to work on this). We also want to support mapping of Kerberos and PKI worlds (with support going in both directions).
Network management: Interoperable trouble tickets is an area needed to support our end-to-end environment and cross-site problem resolution.
Naming: we don't need uniform UIDs for higher education, but mapping should be possible.
Emerging services, like QoS, will very soon put demands on us to address inter-realm issues. Bandwidth brokers, for example, haven't been fully taken up within the IETF.
Directory services: could we create an environment for transparent naming access to resources beyond the campus (e.g., to PACI resources). There are issues around directory synchronization we could work on together.
What inter-realm issues does authorization have? There certainly is the opportunity to work together on group management for authorization purposes, based on LDAP. This could include working on administration tools.
File systems: user (desktop-based) distributed file systems are diminishing in importance.
Is anyone working on secure multicast? ISI is working on that with DARPA funding.
Some sites are coming from a significant legacy environment and want to merge services with the research environment. They are looking at CORBA, for example, as a part of the solution. Other examples of administrative applications architectures include the three tier model of browser/server servlets/JDBC access to databases.
How do we define a "core" set of services. Is that the suite that we all agree to implement? What's the right way to provide the building blocks that lead to a set of core services? How can we illustrate the interdependencies among services?
Design Principles: We could document design principles that guide us to successful services. For example, It must be easy to install or people won't use it. Kerberos, for example, is hard for users to install. Other principles noted include pay attention to the IETF, provide interoperability, ensure a wide spectrum of supported applications.
Best practices: We could seek out patterns among the schools. A certain number of schools have done something in a similar ways. Perhaps we've uncovered a good way to do it. There's work that could be taken to uncover, define, and document those patterns. In some cases we have too many choices, so identifying best practices will help sort out what solutions are appropriate for the particular problems. Concerns about IPSEC, for example, were raised. These concerns included the host-to-host focus and not the applications-to-applications focus. And, there's no API for IPSEC.
Another example mentioned was a cookbook for putting classrooms on the net.
Standards identification: We could establish consistent schema, APIs, and access protocols for higher education.
Moving to new technology. We could work together on challenges like K4->K5 migration, moving from yellow pages to LDAP, staying with AFS or moving to DFS. There are high hopes for Win2000 and MaxOSX because they'll get the concept of login/logout for the operating system. There are also issues for those who want to make Kerberos and Win2000 work together (without requiring an NT server). We would like Microsoft to publish the PAC format, but some MS folks say that will never happen.
What distinguishes higher education? There were different opinions on this.
The multi-national corporation is similar to higher education was one point. Thus, the market can help us. The differences noted included that corporations have more control (versus more decentralization in higher education). Corporations are profit-driven, while higher education has a different focus. Government regulation is very different. Over time, the differences between corporate and higher education needs may be quantitative and not qualitative--scaling issues may make us different. It was also noted that we should focus more on similarities with corporate IT rather than just the differences.
A change we have noted is that innovation is moving out of the university.
We seem to have fewer resources than before. This is one reason for why we should work together. To help sell the idea of cooperative involvement in the middleware initiative, we must create a document or series of documents that point out the benefit to different constituencies: CIO benefits, president benefits, developer benefits, network administrator benefits.
What are the inducements for the architects and the next pioneers? Some want to be pioneers, there are registrars that wish to be at the forefront.
We should identify them and work with them. There are members of this group who are missing key pieces of the infrastructure. For example, CMU is interested in picking up Stanford's directory environment. We can help with that process, looking at where we can make it easier for others to install.
Management of the development process: we need a life cycle process for managing software development, particularly for the open source area. We need to coordinate resources, need to cooperate in evaluating and integrating patches, and we need to make sure there is an owner for the software. This process could apply to both current challenges and for longer term investigations (like Jini) where the tasks could include information dissemination, development and sharing of key tools and influencing vendors.
Development areas discussed, but not committed to without conversations back home, included (the details need to be filled in):
-- Andy Adamson and Radius extensions for authentication mapping -- MIT and a Java-based key signer
-- CMU adopting the Stanford directory environment -- TBD surveying common policies and procedures -- Developing naming best practices
-- Requirements paper for authorization