PROPOSED Virtual Domains

CSE Home

Computing Policies

About Us

Search

Contact Info

Special Services  Name Service  Web Service  Mailing Lists  Mail Service  File Service  Database Service

Virtual Domains -or- How Much Can I Get For Free? D R A F T Ver 1 – EL: 22-apr Ver 2 – JS: 22-apr The increase in collaboration and interdisciplinary research on the part of the CSE community is a good thing. And the department clearly wants to support encourage it as much as is reasonable. In terms of technical support, the question for the CS Lab becomes , what is and what is not reasonable, in terms of the services and/or support that the department can put behind an interdisciplinary project? And at what point should the project simply hire their own technical staff? defining what "reasonable" means in terms of the added labor (design, implementation and continuing maintenance) required to provide the department-hosted infrastructure of such interdisciplinary projects. Requirements beyond "reasonable" indicate that the project should simply hire their own technical staff. One obvious thing that most interdisciplinary projects want is their own web space, so they can present their face to the world. This is actually pretty easy, and integrates nicely with the existing infrastructure. Some projects might also want mailing lists (within the project namespace), which takes a bit more effort to provide, but still doable. But at some point, a line will be crossed, and you will be On Your Own, and may even want to hire your own technical staff to help support the things you need. This document is an attempt to draw that line, by describing the 'personalized' or 'branded' IT services that can be provided to an interdisciplinary research project that is affiliated with the CSE Department, and under what terms and conditions. For illustrative purposes, we will use a fictional research project named Collab, which To illustrate what "reasonable" technical support means, we will examine common services that a fictional research project named Collab might request. For purposes of this discussion Collab involves researchers who are CSE members (at least one regular CSE faculty member), as well as researchers who are not CSE faculty, student or staff. Those "collaborative researchers" might be members of the UW community, or members of some non-UW organization, such as another university. Which services the Department can provide to an interdisciplinary research project and the degree of effort to implement them are primarily a function of how closely affiliated your name space will be with the Department. the "branded name space" of the project will be affiliated with the Department. It may also depend on whether all the members of the project have 'real' CSE accounts (not just guest accounts.) Most Three degrees of affiliation are delineated by the following examples: The research project lives within the Department namespace: collab.cs.washington.edu (i). Or, as a nod to your fellow collaborators, you might want it to be appear not so exclusively affiliated with the CSE Department, but still a part of the University: collab.washington.edu (ii). Finally, you might even want the project to appear to be completely independent of the university: collab.org (iii). Name space issues are not just idle hair-splitting. Names tend to be deeply embedded in how such basic things as addressability, authentication and routing work. The further your project is from the department's naming domain, the more likely that a separate, parallel, "not quite the same as anything else" set of services will be needed to support it. Services you might want for your project include: Name Service Web Service Mailing Lists File Service Data Base Service Mail Service Authentication Name Service Domain Name Service is the most basic service of all. For a sub-domain of the Department – collab.cs.washington.edu – this is a no-brainer. As long as it is unique, we can do it. For a domain that is independent of the Department, but still part of the university – collab.washington.edu – you will have to obtain a subdomain within the washington.edu domain, and the CS Lab can assist with that. tell you who to contact at C&C. If you want any sort of authentication within that name space, an authentication certificate within the washington.edu name space will be necessary, and the CS Lab can assist in obtaining that as well. explain the procedure for obtaining one. For a domain name that is independent of the University – collab.org – you will need to obtain a subdomain of whatever upper-level domain you want to be part of. You will also need to have two separate servers providing DNS service for your new domain. CS Lab staff can assist with this describe the process. Also with authentication certificates, as needed. Web Service The most typical thing you might want is your own web presence, so that people can easily find you. The easy case is if the project name you want will exist within the Department; your web address will be http://collab.cs.washington.edu (note the 'cs' in the middle of that address). You simply create web content in your CSE project space, and it will served by the standard CSE web service. Of course, to provide or edit web content, a person would need a CSE account, and appropriate access to your project file space. If you want your web address to be independent from the CSE department, but still part of the university – collab.washington.edu – this is also possible, but it may require that you provide a server machine to host this web server; the CS Lab will operate it under that domain (using Apache under Linux). Whether or not you need a dedicated host to home this service depends on what other services you might want for your project. If it just web service, then the standard CSE web server can be used. [Is cgi something that would push them to a separate server?] If you want your web address to be independent of the University – collab.org – this is also something we can do, although something that we are loathe do: the interaction with other services become more complicated, and consequently less feasible. manageable. In other words, it depends, and we'll have to look at each on a case-by-case basis. If you want people to reach you at both collab.whatever and www.collab.whatever, this is possible, but may require additional resources (e.g., two authentication certificates). Mailing List Service Most CSE research projects have mailing lists within the department namesapce, and the 'internal' situation is trivial. (You can even include non-departmental people as subscribers, so it can be quasi-interdisciplanary, but the name of the list will of course be under cs.washington.edu.) If you want more independent branding, and would like your mailing lists to be outside the department – either researchers@collab.washington.edu or researchers@collab.org – this is probably not a problem for us to provide. However, you will need to provide a machine to host the mailing list service (we will manage that host), and the administrator of the list must have a regular CSE computer account (not a guest account). In other words, you cannot delegate an administrative role to somebody outside the department - an indication that it is not affiliated strongly enough with CSE to qualify for departmental technical support. [Does this need to be fleshed out more, for the three types of domain names, or does this cover it? At minimum, we ought to figure out how the dub.washington.edu situation differs from the urbansim.org situation.] File Service Assuming your project file space does not need a name that is outside the cs.washington.edu namespace, then all you need to do is provide the disk drives to hold the files, and possibly a tape drive for very large file space. The department will provide the server, cabinets, and the rest of the infrastructure to provide file service through NFS or Windows file services. Access to project files is restricted to project members with a CSE account (can be a guest account, as long as the home directory for the guest does not exceed the guidelines for guest accounts.) If you need project file space outside cs.washington.edu, it may be possible, but you will need to provide a dedicated file server in addition to the disks and backup devices. [Or can we fake it with fancy naming schemes, and lay it on top of existing machines?] These will be considered on a case-by-case basis. [This idea seems basically ok to me, but I might be overlooking something important that renders this expensive for us to do. E.g., if we couldn't figure out how to leverage our existing backup processes, then maybe this is over the line.] Data Base Service [Ahem...] Mail Service Supporting use of mail addresses outside the cs.washington.edu domain (e.g., foo@colab.washington.edu or, worse, foo@colab.org) is a significant problem. It generally requires configuring and maintaining a separate mail server, alias lists, etc., and falls on the far side of "reasonable". This is probably where you cross the line to the point where the department cannot provide the services. There might be some wiggle room here, if all of your project members have regular CSE computer accounts (i.e., not 'guest' accounts). These will be considered on a case-by-case basis. [Need more fleshing out, or does this basically cover it?] Authentication Service [Geez... what do we say here? (If anything.) Talk about auth certificates? Say that we won't operate a separate kerberos db for anything other than cs.washington.edu?] Provision of authentication service for other than cs.washington.edu falls outside the realm of reasonable. The basic premise being that authentication is merely the preliminary to authorization, which in turn implies that an individual is going to do something. As mentioned in the section on Mailing Lists, we must limit authorized inviduals to those holding regular CSE accounts. Last Updated: 4/28/05

	Computer Science & Engineering University of Washington Box 352350 Seattle, WA  98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to CS Lab Director]