CURRENT_MEETING_REPORT_ Reported by Dana Sitzler/Merit NISI Minutes Agenda o Review Activities - Draft document available - NSF nic solicitation o Review Draft - Security issues - Information obligations - Other issues o Implementing Doc Suggestions - Standard address (nic@domain) - Info validity suggestions - Nic-forum - Nic profiles - Discussion list o What's Next - Publish and disband - Continue? * X.500 * Archives * User interface recommendations Discussion: 1. Review Activities A document from this Working Group has been submitted as an Internet Draft. The draft document was used by NSF as one of the `inputs' in preparing the NSFNET NIC solicitation. 2. Review Draft The Working Group reviewed the draft document. We focused on the areas of where internet community members expressed concern either via email (as a result of the draft being available as a i-d) or in person during the Working Group. The following list outlines the group consensus which will be incorporated into the document. 1 2.1 Security Issues There were some concerns expressed by the security area about the proper role for NICs in this area. The Working Group came up with a list of functions which it felt a NIC should deal with. This list will be shared with the Security Area Director and some agreement reached before these changes will be made in the document. To deal with security issues, a NIC: o Should be aware of security-related information/Educate users about security issues. o Should be aware of security advisories. o May serve as the first point of contact for an end-user and should know how to refer/escalate, etc. o Should provide `new' users with information about security such as referring to the Site Security HB. o Should establish procedures for dealing with security `emergencies' through coordination with NOCs. o Can provide pointers to `security' software such as PC virus disinfectant sw. o Should be aware of and refer users (if appropriate) to security organizations such as CERT. 2.2 Personal/Organizational Information The Working Group discussed the responsibilities and obligations of a NIC in providing personal or organizational information to the general public. We had a rather long and interesting discussion of this topic. We talked about the need to differentiate between different types of information, privacy issues, the expense involved with information collection and verification, and the trade-offs of having the info vs. having `correct' info. In terms of dealing with personal or organizational information, we decided to provide a mechanism to inform the information provider about what info is needed, what it will be used for, and if it will be made widely available. Here's what we came up with: o When collecting personal/organizational information, NICs should provide a form which includes a `disclosure statement'. o The `disclosure statement' should include: 2 - What information is needed? - What it will be used for? - The consequences of supplying the information? - How widely available (and which info; some pieces may be made more widely available than other pieces? * Procedure for updating/correcting/disputing. * Frequency of update. * How to return the form (receipt of form w/requested information would be considered an acknowledgement that the info supplier agrees to the terms stated in the `disclosure statement'. o NICs should have a defined mechanism in place to update information collected @ some time frame. o The date of last update/verification should be included with the information made available to others in the network community. o NICs should understand and respect `levels of security' for information -- if info should not be widely available to the public, steps should be taken to make sure that the info is not accessible by anyone. 2.3 Other Issues: o NICs have different audiences -- emphasize in document the idea of working with other NICs (in terms of referring to another NIC if appropriate) and strengthen the idea of a `primary' audience for a NIC which may have been funded by a specific group for a specific purpose o Increase examples in section outlining current NIC services. For example, examples of archives, a specific online service, etc. o Some discussion of recommending in document a common address for NIC ftp servers -- lots of discussion here; no real consensus -- folks with strong opinions about this may want to lobby to continue this discussion until some agreement can be made. o Need to add section numbers. o Shorten history section - does not add to document. 3 Implementing Draft Suggestions 3.1 Standard Email Address The group had no problem with this recommendation. It was stressed that 3 NIC people involved with this Working Group have to start the process of implementing this -- and informing users about it. 3.2 Info Validity Check Info Much of this discussion was covered in the previous section dealing with personal/organizational information. The basic suggestion to have all information include a contact (which may be the NIC) and some indication of the last verification 3.3 nic-forum The group discussed the two components of the nic forum; the nic profiles and the discussion list. The nic profile information sheet was discussed and it was recommended that this sheet be made more `user friendly!'. At present the profile sheet reflects the naming conventions necessary for X.500 but not the ones common to all of us human creatures. The profile sheet will be changed. There was quite a bit of discussion about the discussion list aspect of the nic forum. Who is the audience? Is it an open list? Should it be moderated? Etc. A consensus was not reached on these issues. This meeting was the first time the actual implementation of this suggestion was discussed. The group agreed to continue discussion on the NISI mailing list. 4 What's Next? The group discussed the possibilities for the next step for NISI. The following ideas were generated: o Explore privacy issues. o Develop an international profile database o Develop an appropriate use document which addresses issues like privacy, how to use services, starting `unsolicited stuff', etc. o Define mechanisms for the exchange of information between groups such as nics and nocs. o Access mechanisms; X.500, Z.39.50. o Define requirements for user interface. o Archive o New user nethelp system - start nethelp pilot. o Expand ideas presented in existing document including how nics and nocs interact; maintaining referral information; defining core 4 information at nic. The general consensus was that the last item on this list was probably an appropriate next step. 5 ACTIONS o Update document. o Review RARE Working Group profile. o Discuss and agree to nic profile info and form (Sept). o Discuss with USWG Chair -- NISI next step (given list above). Attendees James Conklin conklin@bitnic.educom.edu John Curran jcurran@bbn.com Peter Deutsch peterd@cc.mcgillica Jill Foster jill.foster@newcastle.ac.uk Maria Gallagher maria@nsipo.arc.nasa.gov Arlene Getchell getchell@nersc.gov Joe Godsil jgodsil@ncsa.uiuc.edu Jack Hahn hahn@sura.net Martyne Hallgren martyne@theory.tn.cornell.edu Ittai Hershman ittai@nis.ans.net Ellen Hoffman esh@merit.edu J. Paul Holbrook holbrook@cic.net Darren Kinley kinley@crim.ca Christopher Kolb kolb@psi.com Dale Land land@lanl.gov Ruth Lang rlang@nisc.sri.com Brian Lev lev@dftnic.gsfc.nasa.gov Peter Liebscher plieb@sura.net Daniel Long long@nic.near.net April Marine april@nisc.sri.com Karen McKelvey karen@cerf.net Clifford Neuman bcn@isi.edu Marsha Perrott mlp@andrew.cmu.edu Joyce K. Reynolds jkrey@isi.edu Timothy Salo tjs@msc.edu Tom Sandoski tom@concert.net Dana Sitzler dds@merit.edu Patricia Smith psmith@merit.edu Ronald Tencati tencati@nssdca.gsfc.nasa.gov Theodore Tso tytso@mit.edu Rudiger Volk rv@informatik.uni-dortmund.de Chris Weider clw@merit.edu Wengyik Yeong yeongw@psi.com 5