DUKE ITAC - July 17, 2003 Minutes


July 17, 2003

Members present: Ed Anapol, Mike Baptiste, Pakis Bessias, John Board, Wayne Miller (for Dick Danner), David Kass (for Brian Eder), David Ferriero, Nevin Fouts, Tracy Futhey, Billy Herndon, David Jamieson-Drake, David Jarmul, Scott Lindroth, Melissa Mills, Caroline Nesbit, George Oberlander, Lynne O'Brien, Rafael Rodriguez, Molly Tamarkin

Guests present: Ginny Cake, Michael Gettes, Ben Riseling, Phil Lemmons, Cheryl Crupi, Jen Vizas, Bob Currier, Chris Cramer, John Diaz

I. Review of minutes and announcements:

Announcements: Meeting Maker meeting took place. There will be a futures forum on calendaring in the near future, including calendaring tools like Meeting Maker, Lotus Notes, Corporate Time. This will be a forum to talk about what is right for the enterprise, etc. It should take place in 3-4 weeks.

II. Faculty teaching resources Web site

Jen Vizas, Cheryl Crupi

  • Background: Fall 2002 - ITAC Subcommittee for AT discussed the possibility of creating a unified web based course resourses form. This would be interactive so faculty could fill in the blanks to get what they were looking for.
  • Spring 2003- the concept of a request form evolving into a recommendation to creating a teaching resources web site. It would tie back into the Administrative systems at Duke.
  • Vision: To create a gateway to information and resources needed to support course instruction - from course planning and development to delivery. Provost Peter Lange became the sponsor and the project started in June 2003.
  • Objectives: Make it easy for faculty and support staff to identify and access teaching resources:
    • Expose new faculty to available resources.
    • Provide quick access to academic guidelines and procedures, calendars, instructional technology, copyright info, etc.
    • Take the first in a series of incremental steps toward interactive and school specific information. It would be implemented in 2 phases.
  • An extended project team was created to provide feedback through the process, included wide representation, 5 faculty members, and administrative staff as well.
  • Core implementation team created to do the work. It meets every week, and will have the site up by the fall semester.
  • Phase one scope - functional prototype. Generic content, contact information, static html website, look and feel consistent with duke.edu, contact all information on existing site and information identified by the project teams, search and index capability, feedback infrastructure. This will take the place of the existing teaching resources web page.
  • Phase two scope - TBD, will be dynamic, tie into enterprise application, have a form faculty could fill out to get the recourses they need.
  • Progress to date: identified stakeholder groups, and engaged representative project teams. Conducted faculty interviews - 12 faculty members, acquired design guideline from duke.edu, started web development.
  • Next steps: finalize and implement communication plan, feedback process, site index, engage faculty and staff in testing and content review, go live, gather feedback and measure success, begin planning for phase two.
  • Go live on 8/18/03
  • Promotion - Outreach to faculty/staff, publications, project team
  • Get feedback, use success metrics
  • Prototype of website: htpp://www.oit.duke.edu/ats/teachweb/trw2

John Board: How does the content stay active, who owns it, who updates it? Right now there is not an owner. It will be all aspects of teaching, not just technology, so hoping to fold it into the portal.

David Jamieson-Drake: If it connects to enterprise apps, it seems like a portal itself.

John Board: How hard it is to change the content? Is it static right now? Yes, right now it is static, but over time it will change to a template that would be fairly seamless to make changes to.

Molly Tamarkin: Like the Duke look and feel, hope that faculty will feel like they know where they are and get familiar with the Web sites.

III. Domain name, Web policy and procedure update

Mike Pickett, Bob Currier and working group

Document - Web & Domain Name Policy and Process version 1.3 distributed

A working policy was developed and put into place about 8 weeks ago to deal with approving/denying domain names and taking back names in some cases when necessary. Please give feedback on the document, its intent is to set expectations, clearly publicize, etc.


Michael Gettes: What about service oriented names, like mail.duke.edu? Bullet 3 needs work to address this.

Melissa Mills: What about 3rd level domains, they are good to have but may not meet the needs of everyone. Need to add some examples to the document.

Mike Baptiste: Needs to be clear you don't need www. A lot of depts. feel they need 3rd level domains, centers are being developed, etc. Who does domain name governance or URL governance?

John Board: Need to make sure Peter Lange is on the board that would do the enforcing.

Mike Baptiste: If this came out of a directive from Peter Lange, it would be good for him to send out the publication with the details of this.

Mike Pickett: Agreed, senior officers in general need to send this out.

Melissa Mills: What about special cases? Centers funded by donations?

David Jarmul: Also need to look at it from a communication and marketing aspect. The shorter the URLs, the better. There could be a legitimate need and reason.

Nevin Fouts: Did we look at duke.edu legacy and precedent issues out there?

Mike Pickett: All existing 3rd level domains will be grand fathered in.

Caroline Nesbit: Watch for people trying to beat the system. People who want vanity names, how to determine who they report to.

Michael Gettes: Operational lookups? Reverse DNS lookups? Anything Duke IP should say duke.edu

Mike Pickett: That is a good issue, and the way to handle that is a bigger, separate issue.

IV. Password security - smart cards and other options

John Diaz, Chris Cramer

-Card technology -

  • Proximity card technology being used in the hospital, more and more getting proximity and tech chips inside cards. Can be used on computers for authentication.
  • There are different ways to present smart cards and use for authentication
  • Issues:
    • any machine that needs to access the card has to have a card reader
    • not sure if it is affordable.
  • Discussion:

    John Board: What about challenge/Response cards?
    Mike Baptiste: Used at Nortel and people hated them, they change every 30 seconds, etc.
    Chris Cramer: Haven't looked at the cards as passwords, etc. Been looking at them as "smart cards"

  • Issue:

    How to get biometrics onto the card. Help privacy issue, can have card, but also need different pieces to get to the resources.

  • Discussion:

    Michael Gettes: What is the intent of the card? To authenticate to computers or to be a Duke ID card? University of Texas Health Science uses cards very successfully.
    Rafael Rodriguez: They have a trial of proximity cards now in the Health System. Clinicians need to get the data as quickly as possible. Anything that is new online will use Webauth and NetID for authentication If departments have specific needs, they can bring them to the card office.

V. Privacy policy update

Chris Cramer

May 8th, Robert Wolpert and Chris Cramer drafted the privacy policy Draft 1.5 of the Duke Data Security and Privacy Policy was handed out for feedback.

John Board: Can a local policy override this policy? Yes Need to reference the confidentiality agreement in this privacy policy. The confidentiality agreement may have department rules that would supercede the privacy policy.

Michael Gettes: Need to mention files on backup tapes and archives John Board: Where do we go now with it.

Tracy Futhey: Need to take it to the next level up and tell the senior officers, make sure they are comfortable with it.

Melissa Mills: Need time to finalize the departmental policies.

John Board: If a lot of departments will supercede the policy, need to define exceptions, have senior officers sign off on the policies.

VI. Faculty data systems update

Mike Pickett


A review team composed of staff from OIT, A& S, DHTS, ADG, ASG members met on June 25, 2003 to review the functionality and the technology underpinnings of the

  • A & S Faculty Data System (FDS)
  • OIT/Provost's office faculty management system (FMS)
  • DHTS ADG faculty important and reporting systems (FPS, FReD, REx, etc)
  • ASG SAP HR/Payroll & Business Warehouse systems

Next steps: Seven recommendations (see below) were made by the review team. The recommendations will need to be considered by appropriate Medical School/Health System leaders, the Trask Technology team, the Office of the Provost, and the Deans. Barring any objections, work will proceed on developing more detailed plans, resource estimates, and timelines related to each recommendation. These plans will be brought back to leadership for review Recommendations:

  1. REx made available to all Deans and Business Managers
  2. Create single faculty database on an enterprise server - consolidation of data (needs to be a consistent, single database)
  3. Substantial overlaps occurred. Whenever local systems have better data than the ED and SAP, use it to feed and populate those databases.
  4. A& S proceed with rollout of FDS
  5. ADG - update FPS and get together with A& S to see if there is some ability for convergence
  6. Faculty.duke.edu domain name - currently ADG "owns" it and FReD runs on it
  7. Current authorization with webauth needs to be looked at for "look and feel" Revise as appropriate then lock down.

VII. Other business


Meeting adjourned at 5:30 pm