1. provide a 24x7 accessible networking contact, preferably one fluidly tied into an inter-NOC communication tool such as http://www.nlanr.net/Ipnmoo
2. support a local web cache, preferably tied into the nlanr hierarchy, http://www.nlanr.net/Cache/
   (HPC and I-2 institutions, see http://www.nlanr.net/VBNS/hpc_cache.html --
   and more importantly, get your internal web browsers configured to use the local cache (most often the harder part).
3. support DNS properly
   • no lame secondary delegations
   • keep your own zone to make sure it's tidy
4. better DNS karma: support DNS LOCRR records (host->latlongs) for network visualization tools/tasks
5. keep Internic registry information up to date.
6. support responsible mbone tunnels (i.e., not egregiously divergent from underlying unicast topology)
7. advise the vbns-techs@nlanr.net list of outages, scheduled and unscheduled. This list includes a contact at every NSF vBNS award site, who forwards the information as appropriate to their users.
8. filter traffic leaving your network for packets with source addresses not from your local address space
   (will solve the SYN flooding problem as well as many others: Internet draft on Network Ingress Filtering by Paul Ferguson, Sept 1996), ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-02.txt

   ---

9. support statistics collection of flow characteristics (e.g., the vBNS's OC3MON support, http://www.nlanr.net/NA/Oc3mon/)
10. stay responsive to ANS tracked and Routing Arbiter tracked problems with your ASes (http://nic.merit.edu/mail.archives/html/routing-problems/)
11. respond to problem reports, isolating the problem to determine if the reported trouble is in your facilities or in other providers' service, make public via web page or vbns-notify@nlanr.net
12. have representative on cert advisory list: upgrade all on-net (inside or outside firewalls) systems whenever cert announces a security related vendor patch.
13. spam-stamping support and attend daily to an abuse@domain alias; agree in principle to educate users about culturally acceptable use and must agree to cancel accounts for users who refuse to be educated. http://www.vix.com/spam/.
14. support other NOC-critical email addresses as described in Internet draft Mailbox names for common services, roles and functions,
    (e.g, hostmaster@; postmaster@; webmaster@; noc@; mbone@; security@; trouble@) David Crocker, January 1997 ftp://ds.internic.net/internet-drafts/draft-crocker-stdaddr-02.txt.

helpful reading

• Responsible Network Management Guidelines, Internet draft, S. Donelan http://dranet.dra.com/draft-donelan-rnmg-latest.txt
• Network Ingress Filtering, Internet draft, Paul Ferguson, Sept 1996 ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-02.txt
• Mailbox names for common services, roles and functions,
  Internet draft, David Crocker, January 1997 ftp://ds.internic.net/internet-drafts/draft-crocker-stdaddr-02.txt
• Recommendations for Internet Routing The Routing Arbiter project, 1996. http://compute.merit.edu/help.html

other relevant mailing lists

• vbns-tech: Technical Contacts Discussion List - A discussion list for the technical contacts at each of the NSF vBNS award sites plus MCI. It could include technical contacts from other connected networks and would likely include vtcc representatives and NSF. Technical issues from this list that need resolution should be brought forward to the vbns-tcc list.
• vbns-tcc: vBNS Technical Coordination Committee (vtcc) - As it is today without change. It is likely the composition of this list will change but the function will remain the same.
• vbns-users: User discussion list for applications development and general use of the vBNS. It will include summaries of vBNS notifications tailored to the users point of view. List members sign up for this list but it should include site technical contacts, vtcc members