Present: (for varying time periods) Arlene Allen, Larry Carver, Glenn
Davis, Ken Dean, Doug Drury, Mike Franklin, Bill Koseluk, Tom Lawton, Shea
Lovan, Elise Meyer, Bruce Miller, Alan Moses, Larry Murdock, Dan Ringwald,
Kevin Schmidt, Vince Sefcik, Jamie Sonsini, Bob Sugar, Paul Valenzuela,
Paul Weakliem
NGB: Core switches are installed. Now beginning migration of specific
research groups identified as early adopters. Next step is coordination
with router administrators in this group.
address@ucsb.edu: A very limited test is being conducted on the address@ucsb.edu
service. To participate in this test you need to do the following:
- Point a web browser to http://www.oit.ucsb.edu/email.
- We are using a self-signed certificate for security purposes, so
your browser will probably ask if you want to accept the certificate.
Please do so. It will switch to a commercial certificate shortly.
- Log into the service.
- To limit subscriptions during testing, all new accounts are disabled
by default. Once you've logged in, you'll see a line at the very
bottom of the screen that looks like this: "Ref: 418md886-7c52-19d3-8bac-00l0c2202d0f".
Email that line to Kevin (kps@ucsb.edu) and he'll enable your account. You can then return to the above URL and finish setting up an @ucsb.edu address.
The system sets up a match between a "public" address (the one you put
on your business card) and a "local" address (where you actually read your
email). The system pre-populates the public address with firstname.lastname
as originally specified, but does not enforce this configuration. Discussion
of whether to enforce this proposed standard ensued. No one advocated enforcing
it, but some thought that the Academic Senate committee that ratified the
original proposal (Recommendations
for Email at UCSB – Early History, Goal #5) back in 1994-5 should be
notified of this change. Some restrictions apply. For example, you can't
call yourself "Chancellor" or choose fighting words or scatological references.
Someone suggested forming a group to integrate restricted word lists as
not everyone is able to keep up with changing language patterns. Similarly,
the system pre-populates the local address with the ucsbbus1 email address
from the UCSB Directory but allows users to change this field. It was noted
that the virus scanning feature imposes a practical limit of 10M on the
size of messages. Those messages found to have a virus are not delivered,
but the sender and the postmaster are notified. In conclusion, Kevin noted
that policy parameters are flexible and reactions to the user interface
are welcome.
The remainder of the meeting was consumed by a discussion of the intrabuilding
wiring project, the currently defined wiring standards and the process
for deciding what gets done with the funds available. Tension was expressed
by departmental technical staff (DTS) who find themselves caught between
central technical staff (CTS) and academic program planners (APPs). On
one hand, the CTS advocate holding to defined wiring standards, putting
projects in priority order and addressing higher priority projects while
lower priority projects wait until funds become available, perhaps in a
following year. On the other hand, the APPs need to capture every scrap
of space available to house faculty and staff needed to support growing
enrollments and research opportunities. Consequently, the APPs ask their
DTS to provide computing service in spaces that did not make the cut on
wiring projects planned with the funds available to the CTS for the year.
Wanting to respond, the DTS are looking for ways to satisfy the APPs without
creating redundant wiring units in their own organizations or competing
for funding that might otherwise go to the CTS and, thus, retard the progress
toward a fully supported campus wiring plant managed by the CTS.
One proposal was a revision of the campus wiring standards to permit
the installation of cabling without the standard infrastructure ( cabletrays,
conduit, or raceways) or locating equipment within departmental space rather
than a communications closet and running patch cables from the equipment
to the workstations. The up side is that doing so would reduce the cost
of certain projects and permit more projects to be done in a given year.
The down side is that installations that lack the standard infrastructure
will inevitably be difficult to support if they outlive their short planned
life time. For example, everyone agrees that it doesn't make sense to install
the full standard conduit and cable tray infrastructure in a building that
is to be torn down in two years. Experience indicates, however, that it
is very difficult to be certain that the planned demolition of a building
will ever take place. Consequently, the unit that supports the wiring in
such a building will suffer when maintenance is required as the wiring
and electronics age or as further reassignments and reconfigurations are
required. The underlying issue in much of the discussion involved whether
the CTS or the DTS should be responsible for the risk of finding themselves
in this unfortunate position.
An alternate proposal was that non-standard implementations would be
done only on an exceptional basis. One approach would have the APPs make
a written appeal for an exception to policy that would allow the implementation
of non-standard wiring. In this appeal they would absorb the responsibility
for temporary projects that outlive their planned life time. Another approach
would be to have the CTS propose, implement and support non-standard implementations
where they make sense (e.g., buildings scheduled for demolition). This
would avoid having the DTS support redundant wiring groups and would move
the campus in the direction of a single wiring plant supported by a single
CTS unit. A concern with the second approach is that when future maintenance
and reconfiguration is required on non-standard installations, CTS could
be required to absorb the frustrations, inefficiencies and demanding work
schedules that non-standard installations have historically generated.
While the group seemed to reach consensus that a second tier standard for
temporary buildings might be justified, we were not able to come to agreement
on the process by which projects would be selected for second tier installations.
An additional issue is that the standards currently allow a range of
materials to be used for infrastructure: raceway could be either plastic
or aluminum and cable distribution could be either J-hooks, or D-rings
or ladder cabletrays. A question arose about whether the estimates used
for the prioritization process should include these tradeoffs or should
this be part of the detailed design for projects once they are funded.
If they are done before the prioritization process, the projects could
be cheaper in which case more could be declared "funded", however this
would require additional time and money to perform these more detailed
estimates. If they are done during the detailed design process for only
the funded projects, project savings could still occur, but it would be
learned later in the process.
The group also recognized, over the course of the discussion, that none
of the proposed solutions would solve the larger problem of dealing with
greater demand than can be addressed with available resources. They might
allow a greater number of projects to be done, but that would just move
the boundary between those projects that got funded and those that didn't
further down the list. At that point, the issue of how to do the remaining
required but unfunded projects would still remain. That is, do the APPs
find funding for the CTS to do all of their "must do" projects to campus
standards or do the APPs adjust their program requirements to fit within
the resources available? If the APPs can do neither, they will likely come
back to the DTS and request non-standard implementations on the basis of
lack of funding. How everyone involved will respond to this situation remains
to be seen.
Back to ITPG Meeting Schedule
