~ April 1992 INTERNET MONTHLY REPORTS ------------------------ The purpose of these reports is to communicate to the Internet Research Group the accomplishments, milestones reached, or problems discovered by the participating organizations. This report is for Internet information purposes only, and is not to be quoted in other publications without permission from the submitter. Each organization is expected to submit a 1/2 page report on the first business day of the month describing the previous month's activities. These reports should be submitted via network mail to: Ann Westine Cooper (Cooper@ISI.EDU) NSF Regional reports - Corinne Carroll (ccarroll@NNSC.NSF.NET) Directory Services reports - Tom Tignor (TPT2@ISI.EDU) Requests to be added or deleted from the Internet Monthly report list should be sent to "cooper@isi.edu". Back issues of the Internet Monthly Report can be copied via FTP: FTP> nis.nsf.net Login: anonymous guest ftp> cd publications/internet.monthly.report ls get IMRYY-MM.TXT For example, JUNE 1991 is in the file IMR91-06.TXT. Cooper [Page 1] Internet Monthly Report April 1992 TABLE OF CONTENTS INTERNET ACTIVITIES BOARD IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . page 4 INTERNET RESEARCH REPORTS . . . . . . . . . . . . . . . . page 5 AUTONOMOUS NETWORKS . . . . . . . . . . . . . . . . . page 5 END-TO-END SERVICES . . . . . . . . . . . . . . . . . page 5 PRIVACY AND SECURITY . . . . . . . . . . . . . . . . . page 5 RESOURCE DISCOVERY AND DIRECTORY SERVICE . . .. . . . page 7 INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 7 Internet Projects BARRNET . . . . . . . . . . . . . . . . . . . . . . . . . page 11 BOLT BERANEK AND NEWMAN, INC., . . . . . . . . . . . . . page 11 CIX (COMMERCIAL INTERNET EXCHANGE). . . . . . . . . . . . page 12 CSUNET (CALIFORNIA STATE UNIVERSITY NETWORK). . . . . . . page 13 ISI . . . . . . . . . . . . . . . . . . . . . . . . . . . page 15 JVNCNET . . . . . . . . . . . . . . . . . . . . . . . . . page 17 LOS NETTOS . . . . . . . . . . . . . . . . . . . . . . . page 19 MERIT/MICHNET . . . . . . . . . . . . . . . . . . . . . . page 19 NEARNET (NEW ENGLAND ACADEMIC AND RESEARCH NETWORK) . . . page 21 NNSC, UCAR/BOLT BERANEK and NEWMAN, INC., . . . . . . . . page 22 NORTHWESTNET. . . . . . . . . . . . . . . . . . . . . . . page 22 NSFNET/ANSNET BACKBONE ENGINEERING. . . . . . . . . . . . page 23 NSFNET/INFORMATION SERVICES . . . . . . . . . . . . . . . page 31 SAIC. . . . . . . . . . . . . . . . . . . . . . . . . . . page 32 SDSC (SAN DIEGO SUPERCOMPUTER CENTER) . . . . . . . . . . page 33 SRI . . . . . . . . . . . . . . . . . . . . . . . . . . . page 35 UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 36 UDEL. . . . . . . . . . . . . . . . . . . . . . . . . . . page 37 WISCNET . . . . . . . . . . . . . . . . . . . . . . . . . page 38 DIRECTORY SERVICES ACTIVITIES DIRECTORY SERVICES MESSAGE . . . . . . . . . . . . . . . page 39 PSI DARPA/NNT X.500 PROJECT . . . . . . . . . . . . . . . page 39 PSI WHITE PAGES PILOT . . . . . . . . . . . . . . . . . . page 40 REGISTRATION AUTHORITY COMMITTEE (ANSI USA RAC) . . . . . page 40 SG-D MHS-MD . . . . . . . . . . . . . . . . . . . . . . . page 42 USENET-ADDRESSES DATABASE . . . . . . . . . . . . . . . . page 47 CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 48 Cooper [Page 2] Internet Monthly Report April 1992 IAB MESSAGE STANDARDS ADVANCES The following list shows the protocol standards actions approved by the IAB since April 1, 1991. o Mapping between X.400(1988)/ISO 10021 and RFC-822 Proposed Standard 7 Apr 1992 RFC in Preparation o Downgrading X.400(1988) to X.400(1984) Proposed Standard 7 Apr 1992 RFC in Preparation o PPP -- Point-to-Point Protocol (new version) Proposed Standard: 10 April 1992 RFC in Preparation Although this new version of PPP has changes substantial enough to warrant return to Proposed State, it is essentially backwards-compatible with the Draft Standard (RFC-1171) that it replaces. The specification RFCs were also re-packaged, so RFC-1172 (PPP-INIT) was also obsoleted. NEW RFC's The following RFC's were published in April, in accordance with decisions reported previously. o NetFAX -- A File Format for the Exchange of Images Proposed Standard: 17 March 1992 RFC-1314 - "A File Format for the Exchange of Images in the Internet" o Frame Relay MIB Proposed Standard: 17 March 1992 RFC-1315 - "Management Information Base for Frame Relay DTEs" o Character Stream Device MIB Proposed Standard: 17 March 1992 RFC-1316 - "Definitions of Managed Objects for Character Stream Devices" Cooper [Page 3] Internet Monthly Report April 1992 o RS-232 MIB Proposed Standard: 17 March 1992 RFC-1317 - "Definitions of Managed Objects for RS-232-like Hardware Devices" o Parallel Printer MIB Proposed Standard: 17 March 1992 RFC-1318 - "Definitions of Managed Objects for Parallel- Printer-like Hardware Devices" o NTP-3 -- Network Time Protocol Version 3 Proposed Standard: 4 September 1991 RFC-1305 - "Network Time Protocol (Version 3) Specification, Implementation, and Analysis" Bob Braden (Braden@ISI.EDU) INTERNET RESEARCH REPORTS ------------------------- AUTONOMOUS NETWORKS ------------------- No internet-related progress to report. Deborah Estrin (Estrin@USC.EDU) END-TO-END SERVICES ------------------- No internet-related progress to report. Bob Braden (Braden@ISI.EDU) PRIVACY AND SECURITY -------------------- The Privacy and Security Research Group (PSRG) met at the University of Wisconsin (Madison) April 29-May 1. The focus of the meeting was continued work on a series of documents which will provide a framework for an Internet security architecture. Prior to the meeting a draft book chapter on network security architecture was distributed for comment and as background reading. A draft outline of the document was developed and writing assignments were made. The outline follows: Cooper [Page 4] Internet Monthly Report April 1992 1. Overview A discussion of the document sections, overall rationale, plans for use relative to standards track RFCs in the future, etc. Definitions of vulnerability, attacks, and threat. Motivations for better Internet security because of changing threat environment. The role of risk analysis. Philosophy for internet security standards: 1.1 Security Services Review of ISO 7498-2, plus service availability. More discussion of services and examples. 1.2 Security Mechanisms General principles of "good" security mechanisms, starting with Kent book chapter, including the ability to implement in a fashion which promotes ease of use. Both general and per- mechanism class principles will be addressed. ISO 7498-2 mechanisms as starting point, plus more details, additional mechanism classes, and examples. 1.3 Service/Layer Map Based on ISO 7498-2 Table 2, plus SILS work and service availability. Includes service layering rationale. 1.4 Service/Mechanism Map ISO 7498-2 Table 1, expanded based on section 1.3, plus rationale. 1.5 Application/Service/Mechanism Discussion For major classes of Internet applications, describe the standard protocols used to implement the application in TCP/IP and OSI suites. Discuss each security service in a subsection explaining why the service is appropriate. Recommend a specific mechanism, if available, perhaps on a per-protocol basis. Applications include: directory (X.500 & DNS), message handling (X.400 & SMTP), time (NTP III), network management (SNMP & CMIP), Interactive (Telnet, VT, X windows), file transfer (FTP & VTAM), exterior gateway protocols (EGP, BGP & IDRP), interior gateway protocols (OSPF, IS-IS), etc. Cooper [Page 5] Internet Monthly Report April 1992 1.6 Security Mechanism Catalog Discuss specific examples of basic security mechanisms (encipherment, digital signature, hashing, authentication exchanges, key management, security labels, ...). Examine standard security protocols (SILS, NLSP, TLSP, PEM, X.411, X.509, ...) for use with TCP/IP and OSI suites. Steve Kent RESOURCE DISCOVERY AND DIRECTORY SERVICE ---------------------------------------- No progress this month. Mike Schwartz@latour.cs.colorado.edu. INTERNET ENGINEERING REPORTS ---------------------------- 1. The next IETF meeting, co-hosted by MIT and NEARNet, will take place from July 13th through the 17th in Cambridge, Massachusettes. The Sunday night reception will be held at the Hyatt Regency Cambridge begining at 6 PM on July 12th. Complete registration and logistics information has already been mailed to the IETF mailing list. For copies of this information (or for any other question about the upcoming meeting), please mail your request to "ietf-rsvp@nri.reston.va.us". Based on input and suggetions received, there will be a slightly different meeting agenda in Cambridge, specifically to provide more meeting slots for Working Groups and BOFs. Additionally, technical presentations will be spread across the week in the mornings. 2. Looking ahead, the Fall IETF is scheduled for November 16-20, 1992 in Washington, DC. Our local host is U.S. Sprint. The Spring 1993 IETF will be held in Columbus, Ohio, March 28th - April 2nd. Our Local Hosts will be OARnet and The Ohio State University. 3. The IESG received two requests to approve the publication of the following Internet Drafts: a. Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode to Proposed Standard. Cooper [Page 6] Internet Monthly Report April 1992 b. "An Architecture for Inter-Domain Policy Routing" and "Inter-Domain Policy Routing Protocol Specification and Usage: Version 1" to Proposed Standard. The IESG also received a request from the Privacy Enhanced Mail Working Group to move RFC's 1113, 1114 and RFC 1115, currently Draft Standards, to Historical Standard Status. These documents no longer reflect current PEM protocols. Last call notifications for all three requests were sent to the IETF mailing list by the IESG Secretary. 4. The IESG made the following recommendations to the IAB during the month of April, 1992: a. PPP Link Quality Monitoring be published as a Proposed Standard. b. MIME (Multipurpose Internet Mail Extensions) and Representation of Non-ASCII Text in Internet Message Headers be published jointly as a Proposed Standard. 5. The following three Working Groups were created during the month of April: SNMP over a Multi-protocol Internet (mpsnmp) MIME-MHS Interworking (mimemhs) TCP Client Identity Protocol (ident) 6. The following two Working Groups were concluded during the month of April: OSI Internet Management (oim) Special Host Requirements (shr) 7. 33 Internet Draft Actions were taken between April 1 and 30, 1992: (Revised draft (o), New Draft (+) ) WG I-D Title ------ --------------------------------------------------- (idpr) o An Architecture for Inter-Domain Policy Routing (osids) o Naming Guidelines for Directory Pilots (822ext) o MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies Cooper [Page 7] Internet Monthly Report April 1992 (822ext) o A User Agent Configuration Mechanism For Multimedia Mail Format Information (pem) o The MD5 Message-Digest Algorithm (pem) o The MD2 Message-Digest Algorithm (pem) o The MD4 Message-Digest Algorithm (smtpext) o SMTP Extensions for Transport of Enhanced Text-Based Messages (pppext) o PPP Authentication Protocols (ripv2) o RIP Version 2 Carrying Additional Information (x25mib) o SNMP MIB extension for LAPB (x25mib) o SNMP MIB extension for MultiProtocol Interconnect over X.25 (x25mib) o SNMP MIB extension for the X.25 Packet Layer (bgp) o BGP OSPF Interaction (osids) o A String Representation of Distinguished Names (osids) + Counting the Directory Information Tree (ripv2) + RIP Version 2 MIB Extension (mhsds) + Representing Tables and Subtrees in the Directory (mhsds) + Representing the O/R Address hierarchy in the Directory Information Tree (mhsds) + Use of the Directory to support mapping between X.400 and RFC 822 Addresses (mhsds) + MHS use of the Directory to support distribution lists (mhsds) + Use of the Directory to support routing for RFC 822 and related protocols (mhsds) + A simple profile for MHS use of Directory Cooper [Page 8] Internet Monthly Report April 1992 (mpsnmp) + SNMP over OSI (none) + Supernetting: an Address Assignment and Aggregation Strategy (ident) + Ident MIB (none) + Physical Link Security Type of Service (mhsds) + MHS use of Directory to support MHS Routing (osids) + Lightweight Directory Access Protocol (ospf) + Proposed modifications to RFC 1247 (none) + A Revision to IP Address Classifications (idpr) + IDPR as a Proposed Standard 8. Eight RFC's based on IETF WG activity were produced during the month of April, 1992. RFC Status WG Title ------- -- -------- ---------------------------------------- RFC1314 PS (netfax) A File Format for the Exchange of Images in the Internet RFC1315 PS (iplpdn) Management Information Base for Frame Relay DTEs RFC1316 PS (charmib) Definitions of Managed Objects for Character Stream Devices RFC1317 PS (charmib) Definitions of Managed Objects for RS-232-like Hardware Devices RFC1318 PS (charmib) Definitions of Managed Objects for Parallel-printer-like Hardware Devices RFC1319 I (pem) The MD2 Message-Digest Algorithm RFC1320 I (pem) The MD4 Message-Digest Algorithm RFC1321 I (pem) The MD5 Message-Digest Algorithm Steve Coya (scoya@@NRI.RESTON.VA.US) Phill Gross (pgross@NRI.RESTON.VA.US) Cooper [Page 9] Internet Monthly Report April 1992 INTERNET PROJECTS ----------------- BARRNET ------- Four 56kbps connections including one high school and six low-speed BARRNet Remote Affiliate Members were added in April. An FDDI ring was installed and activated connecting all BARRNet core routers at Stanford to the ENSS, so that all traffic going over the T3 connection to the NSFNET is no longer restricted by an Ethernet path. Also OSPF is now operating on most of the cisco routers in BARRNet's core. Paul Baer BOLT BERANEK AND NEWMAN INC. ---------------------------- IDPR During the month of April, the request for IETF proposed standard status of IDPR was made public. Since that time we have been answering questions and responding to comments posed in response to the announcement and to critical review of the IDPR documents. We have also been coordinating with the sites that will be participating in pilot demonstrations of IDPR later this summer. ST Conferencing During April, a total of 8 video conferences and 1 SIMNET exercise was conducted. Three of the conferences involved three sites, and 5 involved 2 sites. ALSP and DSI groups were the main conferencing users. Although the scheduled conference usage was low, the overall network usage was not, as new installations, software, and demonstrations during April precipitated near-daily test conferences. We continued testing the ST priority packet fix on the UK Fatpipe during April and ran several successful US/UK test conferences. We expect to deploy this software at other locations where limited network bandwidth may be an issue. Most conferencing sites were converted from IBM PC-based framing adaptors to SPC adaptors during this month. The SPCs are smaller, less expensive, and more reliable than the PC converters, and should improve the overall success rate of video conferences. Because of scheduled demos and site contact schedule conflicts, Cooper [Page 10] Internet Monthly Report April 1992 LANL, WPC, and Frankfurt conferencing sites are not yet upgraded. To allow SPC and PC sites to conference during this interim period, they will connect through a patch codec at BBN. Also during this interim period, SPC sites will only participate in 2-way conferences. We expect to field floor control software, which will allow SPC sites to participate in multicast conferences, during May. Hurlburt Field in Florida was installed as a new video conferencing site in April. Conferencing gateways were also installed at MITRE in Virginia, and at ESD in Massachusetts, although the site VTC suites are not yet available. Ft. Leavenworth and one of BBN's two conference rooms have been converted to demonstration sites for secure conferencing. This demonstration project uses E3 encryption units and dual gateways (one secure and one not secure) at each site. Demonstrations are scheduled for May. Jil Westcott CIX (COMMERCIAL INTERNET EXCHANGE) ---------------------------------- The following report outlines CIX-WEST usage for the month of April, 1992. ---- CIX In Out Member Octets Packets Errors Octets Packets Errors -------- ---------------------------- ---------------------------- AlterNet 34978344081 142622862 1502 12071116975 88083082 0 CERFnet 14326796503 84974445 1426 17188189453 87112915 0 PSINet 13073521657 94602425 1 33243852908 149922427 0 Starting: Mar 31 1992 at 23:50 Ending: Apr 30 1992 at 13:35 SNMP Polling Intervals: 2798 SNMP Polling Frequency: 15 minutes In - traffic entering the CIX from the CIX member network Out - traffic exiting the CIX into the CIX member network ----- At the present time, approximately 570 networks within AlterNet, CERFNet, and PSINet are using the CIX-WEST. Cooper [Page 11] Internet Monthly Report April 1992 A complete list of networks accessible via the CIX is available via anonymous FTP from cix.org in the file cix.nets. The current revision of this list is: 9-APR-1992. Send mail to info@cix.org for information regarding the CIX. Mark Fedor (fedor@uu.psi.com) CSUNET (THE CALIFORNIA STATE UNIVERSITY NETWORK) ----------------------------------------------- One of the most notable CSUnet activities during the last two months has been focused on connectivity for the K-14 and university institutions. Quotation from the Pacific Bell Press Release dated May 6, 1992 follows: CALIFORNIA STATE UNIVERSITY AND PACIFIC BELL TO COOPERATE IN BUILDING EDUCATIONAL NETWORK The California State University system and Pacific Bell have agreed to cooperate in bringing the benefits of the Information Age to education in California. The plan focuses on exploring how advances in telecommunications can be used to help fulfill the educational mission of schools serving grades K-14, as well as the CSU's 20 institutions. One of the first cooperative projects may involve CSU's participation in the Knowledge Network Gateway, a service being planned by Pacific Bell to provide California's schools with online access to the National Science Foundation's Internet as well as to other worldwide databases. "California's future depends on our ability to educate our citizens to take their places in an information-based society," said CSU Chancellor Barry Munitz. "This requires that students have access to computing resources, libraries, databases and instructional technologies which may lie beyond the boundaries of individual schools, communities, or states. Through this cooperative effort, we hope to provide equity of access to the resources needed by California students to meet the demands of the future." The plan calls for developing a statewide voice, data and video network to connect all of California's educational institutions to Information Age learning resources. The effort will integrate Pacific Bell's public switched network with CSU's existing telecommunications infrastructure which provides the long distance connections, and capitalize on advances being made by Pacific Bell Cooper [Page 12] Internet Monthly Report April 1992 in broadband networking technology. Other goals of the cooperative effort include: -- Jointly pursuing a technological solution that facilitates student and faculty access to the National Research and Educational Network (NREN) via CSUnet. -- Jointly seeking support for public interest solutions and affordable access. -- Jointly seeking funds from government in general, and the National Science Foundation in particular, to facilitate provisioning of NREN connectivity to California schools. -- Actively seeking the participation of other interested parties, particularly those in the private sector, who also want to help ensure equitable access to the educational resources needed for Californians to be competitive. "This joint effort is very much like a part of Pacific Bell's Knowledge Network vision, in which all educational institutions in the state would be linked through the public network," said Pacific Bell Executive Vice President Bob Lee. "Simply stated, we're talking about an electronic highway of information, connecting every school from kindergarten through university. "Through cooperative efforts like this one with CSU, we believe that educational applications and the infrastructure required to support them can be developed in ways that benefit all of the state's students," Lee said. Pacific Bell is currently involved in a number of Knowledge Network projects with both the California State University and University of California systems. With CSU, the company is engaged in distance learning activities at Bakersfield, Chico, Dominguez Hills and San Luis Obispo. In addition, the company entered into a cooperative agreement with CSU San Marcos last year to develop an advanced telecommunications platform to enable the university to be a model campus for the Information Age. With UC, the company is involved in Integrated Services Digital Network (ISDN) applications development and the testing of high speed transmission using a new technology called Frame Relay. Both projects are underway at the UC Berkeley campus. Cooper [Page 13] Internet Monthly Report April 1992 The CSU is the largest system of senior higher education in the nation. Its 20 campuses and nine off-campus centers stretch from Arcata in the far north to San Diego in the south. Currently, there are 361,000 students attending CSU campuses. The CSU produces 70 percent of the state's public school teachers; 50 percent more business graduates and more computer scientists and engineers than all other California universities and colleges combined. CSUnet is the wide-area network of the California State University, interconnecting the 20 campuses and their five off-site centers with information resources around the world. Pacific Bell is a subsidiary of Pacific Telesis Group, a diversified worldwide telecommunications corporation based in San Francisco. Mike Marcinkevicz (mdm@CSU.net) ISI --- GIGABIT NETWORKING Infrastructure Joyce Reynolds attended the RARE WG3 meetings in London, 22-24 April, and the RIPE meetings in Amsterdam, 27-29 April, 1992. Jon Postel hosted a DARTNET meeting at ISI April 13th. Bob Braden attended a "Workshop on Quality of Service Issues in High Speed Networks" in Summit, New Jersey, at AT&T and chaired a halfday session on "Specific Scheduling and Traffic Management Algorithms". 11 RFCs were published this month. RFC 1307: Young, J., and A. Nicholson, "Dynamically Switched Link Control Protocol", Cray Research, Inc, March 1992. RFC 1312: Nelson, R., (Crynwr Software), and G. Arnold, (SUN Microsystems), "Message Send Protocol 2", April 1992. RFC 1313: Partridge, C., "Today's Programming for KRFC AM 1313 Internet Talk Radio", BBN, April, 1992. RFC 1314: Katz, A., D. Cohen, "A File Format for the Exchange of Images in the Internet", ISI, April 1992. Cooper [Page 14] Internet Monthly Report April 1992 RFC 1315: Brown, C., (Wellfleet), F. Baker, and C. Carvalho (ACC), "Management Information Base for Frame Relay DTEs", April 1992. RFC 1316: Stewart, B., "Definitions of Managed Objects for Character Stream Devices", Xyplex, Inc., April 1992. RFC 1317: Stewart, B., "Definitions of Managed Objects for RS-232-like Hardware Devices", Xyplex, Inc., April 1992. RFC 1318: Stewart, B., "Definitions of Managed Objects for Parallel-printer-like Hardware Devices", Xyplex, Inc., April 1992. RFC 1319: Kaliski, B., "The MD2 Message-Digest Algorithm", RSA Laboratories, April 1992. RFC 1320: Rivest, R., "The MDA Message-Digest Algorithm", MIT and RSA Data Security, April 1992. RFC 1321: Rivest, R., "The MD5 Message-Digest Algorithm", MIT and RSA Data Security, April 1992. Ann Westine Cooper (Cooper@ISI.EDU) MULTIMEDIA CONFERENCING DARTnet experimentors conducted a demonstration of traffic control algorithms on April 13th. ISI participated in demonstrations of both ST-II and UDP/IP multicast styles of teleconferencing. For the ST-II demo, the Multimedia Conference Control program (MMCC) was used to orchestrate packet audio and video sessions among groups of participants using the Host Control Protocol to communicate connection control information to the Voice Terminal (VT) and the Packet Voice Program (PVP). Once established, ST data flows were bombarded with large amounts of competing traffic in an effort to show that the Virtual Clock traffic control mechanism protects against the degradation of real-time data delivery. PVP was also operated in UDP/IP multicast mode for demonstrations of traffic control algorithms implemented by MIT and LBL. Eve Schooler presented a paper, "An Architecture for Multimedia Connection Management", at Multimedia '92, the IEEE ComSoc 4th International Workshop on Multimedia Communications, Monterey, CA. Steve Casner, Eve Schooler, (casner@ISI.EDU, schooler@ISI.EDU) Cooper [Page 15] Internet Monthly Report April 1992 JVNCNET ------- I. General information A. How to reach us: 1-800-35-TIGER (from anywhere in the United States) by e-mail NOC: noc@jvnc.net Service desk: service@jvnc.net by mail: U.S. mail address: Princeton University B6 von Neumann Hall Princeton, NJ 08544 (Director: Sergio Heker) B. Hours NOC: 24 hours/day, seven days a week Service desk: 9:00 to 5:00 pm, M - F (except holidays) C. Other info available on-line from NICOL Telnet to nicol.jvnc.net. Login ID is nicol and no password. D. RFCs on-line To obtain RFCs from the official JvNCnet repository (two methods): 1) ftp jvnc.net; username: anonymous; password: 2) RFC automailer Send email to sendrfc@jvnc.net. Subject line is RFCxxxx. xxxx represents the RFC number. RFCs with three digits only need three digits in the request. II. New Information Availability for March 1992 is 99.87%. Traffic rose 6% (total incoming and outgoing packets: 1,776,331,300) compared to February 1992's traffic of 1,677,960,900 total incoming and outgoing packets). Cooper [Page 16] Internet Monthly Report April 1992 A. New on-line members (fully operational March, April, May 1992) American Cyanamid, Princeton, NJ College of St. Elizabeth, Morristown, NJ Rhode Island College, Providence, RI Multilingual Technologies, Fairfield, NJ Taylor Technologies, Princeton, NJ Roselle Borough School District, Roselle, NJ South Brunswick School District, Monmouth Junction, NJ Stanger, Michaelson, Spivak, and Wallace, Red Bank, NJ Netquest Corp., Mt. Laurel, NJ West Windsor-Plainsboro School District, Plainsboro, NJ Unisoft, Marlboro, NJ Hoechst-Celanese, Summit, NJ Mier Communications, Princeton Junction, NJ B. JvNCnet Symposium Series For information about planned JvNCnet symposiums, please send email to "symposium@jvnc.net" or call 1-800-35-TIGER. C. JvNCnet K-12 Dial-up Connectivity Program For information about the JvNCnet K-12 activities, send email to K-12-request@jvnc.net or contact Rochelle Hammer at 1-800-35-TIGER, option 0 (zero). JvNCnet actively works with the teachers in the following areas: training on the Dialin'Tiger service, development of a student user manual, identification and sharing with teachers appropriate and interesting applications and resources for various grade-levels, and evaluating curriculum enhancements. D. MEGABYTES newsletter The next issue of Megabytes will be mailed out in about two weeks. To subscribe to the electronic distribution of Megabytes, send email to "megabytes-request@jvnc.net". E. Miscellaneous JvNCnet will have a booth at the next INTEROP in Washington, DC on May 20-22, 1992. New and exciting services and applications will be demonstrated. Rochelle Hammer (hammer@jvnc.net) Cooper [Page 17] Internet Monthly Report April 1992 LOS NETTOS ---------- AGS plus routers are being installed at all Los Nettos sites. Walt Prue (Prue@ISI.EDU) MERIT/MICHNET ------------- Merit has undergone some internal reorganization in the past few months. Partly because of staff changes at the University of Michigan, where Merit is housed, and partly out of Merit's strong commitment to improving service to our customers, Merit has reorganized into three main divisions. Each group primarily focuses on one of our major client bases: the NSFNET backbone project, MichNet, and the University of Michigan's UMnet project. Jeff Ogden is now the Merit Associate Director for MichNet. Previously Jeff was manager of recruitment and technical support for Merit. The NSFNET Information Services group and the MichNet Technical Support group have been combined into the Network Information Services group, managed by Ellen Hoffman, formerly assistant to Merit's President. John Vollbrecht is the new Manager of the MichNet Engineering group, which includes the software engineers previously managed by Mark Knopper. Mark, a long-time Merit employee, has taken over the management of Merit's Internet Engineering group, which focuses on national networking activities. Jim Williams, formerly from the University of Nevada at Las Vegas and NevadaNet, is the new National Networking Associate Director. Scott Gerstenberger, who was Associate Director for both MichNet and the University of Michigan's data networking activities, is now directing almost all of his efforts to U-M activities as Associate Director for UMnet. Scott now reports to U-M's new Director of Network Systems, Mike McGill. McGill comes to U-M from Ameritech, Inc. CIESIN, the Consortium for International Earth Science Information Network, has joined Merit as an affiliate. The CIESIN facility on the campus of Saginaw Valley State University will be linked to the network at 1.5 million bits per second (T1), its Ann Arbor facility will be linked at 56 thousand bits per second. (For a complete discussion of CIESIN and its projects, see the May-June, 1991 issue of the MichNet News.) Cooper [Page 18] Internet Monthly Report April 1992 The first Merit K-12 affiliate was connected to the network in late April. Page Middle School in Madison Heights (Lamphere School District) is the first k12 school in Michigan with a direct connection to MichNet. This summer, we will add Northville, Mumford, Model High, and Walled Lake -- as part of Merit Project Connect. This spring the MichNet dial-in service in Traverse City was upgraded to include triple speed modems, which answer at 1200, 2400, and 9600 bits per second. As a result of this upgrade, 300 bps service in Traverse City was discontinued. The Traverse City phone number remains the same. This upgrade was made possible by a joint effort of the Northwestern Michigan Council of Governments, Northwestern Michigan College, and Merit. The Great Lakes Environmental Research Laboratory in Ann Arbor is attaching to MichNet. GLERL, which is part of the National Oceanic and Atmospheric Administration of the U.S. Dept. of Commerce, will be connected at 56 kilobits per second using a pair of cisco routers. Merit programmers have written a packet driver for NCSA Telnet version 2.3 which allows the use of Point-to-Point Protocol (PPP) with NCSA Telnet for DOS machines. The package includes a telnet client and an ftp server. The package does not include a TN3270 client. The PPP packet driver allows NCSA Telnet to be used over asynchronous serial connections including the MichNet public dial- in lines. (For an introduction to PPP, see the September, 1991, issue of the MichNet News.) This packet driver and the MichNet- customized telnet client can be obtained via anonymous FTP fromthe host merit.edu. The name of the file is: /pub/ppp/ncsappp.zip. This compressed file contains the PPP packet driver, the NCSA Telnet software, some basic configuration files, and documentation for all of these. There is also a basic instruction file to help you install the driver for use with NCSA Telnet. To uncompress the entire file you will need to have the pkunzip software, version 1.1. Questions about the PPP packet driver can be directed to: info@merit.edu Pat McGregor Cooper [Page 19] Internet Monthly Report April 1992 NEARNET (NEW ENGLAND ACADEMIC AND RESEARCH NETWORK) --------------------------------------------------- NEARnet Membership As of April 31, NEARnet has grown to 133 members. NEARnet K-12 Workshop As part of the follow-up activities from the NEARnet K-12 Workshop in March, the NEARnet staff continues to disseminate information distributed at the workshop. The workshop was held in cooperation with the Massachusetts Telecomputing Coalition in an effort to develop innovative educational partnerships between NEARnet and the educators and administrators from the kindergarten through twelve grade educational community in New England. The NEARnet Staff also maintains a mailing list for discussing K-12 educationalnetworking in New England. If you would like to have your name added to the nearnet-k12 mailing list, please send your request to nearnet-us@nic.near.net. NEARnet Technical and User Seminars '92 NEARnet has announced the newly revised seminar program for 1992. Based on member feedback received at the last Technical and User Seminar, NEARnet is offering six mini-seminars in 1992. They will be held afternoons from 1:00 p.m.to 4:00 p.m. at Newman Auditorium at Bolt Beranek and Newman Inc. (BBN) in Cambridge, Massachusetts. The mini-seminars will cover specific topics of interest to technical liaisons, information liaisons, and administrators. Information on the seminar series is available via anonymous file transfer (FTP) from the nic.near.net computer in the directory seminars. Files include an announcement of the seminar series, a copy of the registration form, information on the location and directions to the seminars. If you have any questions regarding the seminars, please call the NEARnet Hotline at (617) 873-8730 or send electronic mail to the NEARnet User Services Staff at nearnet-us.nic.near.net. Cooper [Page 20] Internet Monthly Report April 1992 NEARnet This Month The April issue of the electronic bulletin "NEARnet This Month" has been distributed. Past issues of the bulletin are available via anonymous FTP at nic.near.net, in the directory newsletters/nearnet-this-month. Corinne Carroll NNSC, UCAR/BOLT BERANEK and NEWMAN, INC. ---------------------------------------- The NNSC has published and distributed the latest issue of the NSF Network Newsletter. A PostScript version of the revised newsletter map is available via anonymous FTP at nnsc.nsf.net with the pathname nsfnet/nsfmap.ps. The sitelist for the map is under the pathname nsfnet/sites. Due to an article featured in the April 27th issue of MACWEEK Magazine, entitled "What is happening to the Internet?", the NNSC Staff has received a tremendous amount of requests for information on the "Tour of the Internet" and general NSFNET/Internet information packages. Corinne Carroll NORTHWESTNET ------------ The NorthWestNet Network Engineering Advisory Board met recently to address matters of network engineering, infrastructure, operation and technical servicedelivery. During their April 17 meeting, the Board reviewed scheduled maintenance, redundant connectivity options including the availability of switched 56K and T1 services in Pacific Northwestern metropolitan areas, Frame Relay and SMDS service availability, collocation agreements with telecommunications providers, and escalation procedures for problem reporting and resolution of outages. Carol Brand, NorthWestNet's Educational Services Specialist, recently attended a presenter's workshop on the National Education Supercomputer (NES) at Lawrence Livermore National Laboratory. The week-long class focused on the useof the the Cray X-MP/18 in K-12 science education. The NES is a powerful tool that can dramatically enhance science curriculums with the aid of computer- generated simulation. NorthWestNet plans to provide NES training to its K-12 members sometime at the end of this year. Cooper [Page 21] Internet Monthly Report April 1992 Eric Hood just returned from North Dakota where he delivered speeches at the 25th Annual Small College Computing Symposium, at North Dakota State University, and at a meeting of the North Dakota Board of Higher Education at the University of North Dakota. His presentations focused on realizing the advantages of the NREN in the Northwest, specifically to enable educational programs and to promote economic development. NorthWestNet 15400 SE 30th Place, Suite 202 Phone: (206) 562-3000 Bellevue, WA 98007 Fax: (206) 562-4822 Dr. Eric S. Hood, Executive Director Dan L. Jordt, Director of Technical Services Schele Gislason, Administrative Assistant NorthWestNet serves the six state region of Alaska, Idaho, Montana, North Dakota, Oregon, and Washington. Dan Jordt NSFNET/ANSNET BACKBONE ENGINEERING ---------------------------------- T3 Network Status ================= The T3 network remains very reliable and during the month of April it carried over 50% of total NSFNET packets: The total inbound packet count for the T1 network was 8,094,303,100, down 23.5% from March. 467,760,160 of these packets entered from the T3 network. The total inbound packet count for the T3 network was 8,300,400,177, up 60% from March. 331,145,209 of these packets entered from the T1 network. The combined total inbound packet count for the T1 and T3 networks (less cross network traffic) was 15,595,797,908, up 4.6% from March. This month the cutovers of traffic from the T1 to the T3 backbones was completed for CICNet, but further cutovers were held until after the 5 week deployment schedule for RS/960 hardware upgrades is completed. As of the end of April the first week of RS/960 DS3 card deployment for the Denver and Seattle CNSS nodes, and the University of Washington, Boulder and Salt Lake City ENSS nodes, was completed with successful results. New kernel and routing software was deployed throughout the backbone to prepare for the remaining RS/960 upgrades. Cooper [Page 22] Internet Monthly Report April 1992 T1 Network Status ================= The T1 network has reached a reasonable level of stability since it is carrying less than a majority of total traffic. The load on the RCP nodes is still an issue, since the backbone is still carrying all routing announcements to and from each regional network. A new version of rcp_routed is still in testing and will be deployed on the T1 RCPs during first half of May. This version has the changes for the second phase of the LSP PDU compression implementation, to allow more efficient processing of these packets in the RCPs. It also raises the maximum number of network announcements that can be accepted at a regional from 2300 to 4500. T3 Backbone RS/960 Deployment Status - Week 1 ============================================= - RS/960 Hardware Deployment Early Saturday morning, April 25, the first step of the Phase-III RS960 DS3 upgrade to the T3 Backbone was completed. The following T3 backbone nodes are currently running with new T3 hardware and software in a stable configuration: Seattle POP: CNSS88, CNSS89, CNSS91 Denver POP: CNSS96, CNSS97, CNSS99 Regionals: ENSS141 (Boulder), ENSS142 (Salt Lake), ENSS143 (U. Washington) Friday night 5/1 and Saturday morning 5/2, the second step will occur, with the following nodes being upgraded: Los Angeles POP (barring rioting, etc.): CNSS16, CNSS17, CNSS19 San Francisco POP: CNSS8, CNSS9, CNSS11 Regionals: ENSS128 (Palo Alto), ENSS144 (NASA Ames/FIX-West), ENSS135 (San Diego) - Kernel Build and Routing Software Deployment Early this morning (April 30), all of the network nodes were upgraded with Build 2.78.22 and a new version of rcp_routed. Several nodes (the Step 1 nodes and also the Ann Arbor ENSS) have been running in this configuration since April 27. This software build includes drivers for the RS/960 cards, and several bug fixes. The fixes include reliability improvements to the FDDI software, notably a soft reset for a hung card; and some additional improvements to the T960 ethernet and T1 card support to fix a problem where the card could hang under a heavy load. The Cooper [Page 23] Internet Monthly Report April 1992 rcp_routed change includes a fix to a problem that was observed during RS/960 testing. The problem involved some aberrant behavior of rcp_routed when a misconfigured regional peer router would advertise a route via BGP to an ENSS whose next hop was the ENSS itself. The old rcp_routed could go into a loop sending multiple redirect packets out on to the subnet. The new rcp_routed will close the BGP session if it receives an announcement of such a route. The new rcp_routed software also has support for externally administered inter-AS metrics, an auto-restart capability, and bug fixes for BGP overruns with peer routers. This deployment caused a few problems. One is that this new feature of rcp_routed pointed out a misconfigured peer router at Rice University in Houston. This caused the BGP connection to open and close rapidly which caused further problems on the peer router. Eventually the peer was reconfigured to remove the bad route, which fixed the problem. Another problem was on the Argonne ENSS. This node crashed in such a way that it was not reachable and there was difficulty contacting the site to reboot the machine. Once the reboot was done the ENSS came back up running properly. We are looking into the cause of this crash, as this is the first time this has happened in all of our testing and deployment. The third problem was at the CoNCert ENSS, and this node crashed in such a way that the unix file system was completely lost, and this requires a complete rebuild of the system. This problem has happened in two cases previously, and seems to be related to an AIX problem rather than anything in the new software build. It is an insidious problem since it completely wipes out any trace of what may have caused it. We continue to look into this. In our view, none of these problems are severe enough to call off the deployment of the RS/960 hardware upgrade on the west coast Saturday morning. These problems aren't related to the new hardware or software support for the new cards, but seem to be problems in other parts of the new software build or routing daemon. The following section details our experiences of the first week's deployment. We believe we have an understanding of the problems that occurred and have increased the number of spare cards in the kits that the teams will take out to the sites. Summary of Week 1 (beginning 4/25) RS/960 Deployment ==================================================== Since the deployment, nodes CNSS88 and CNSS96 have been running with mixed technology (i.e. 3xRS960 T3 interfaces, 1xHawthorne T3 interface). Production traffic on the affected ENSS nodes was cutover to the T1 backbone at 2:00 AM EST on 4/25. The Denver POP nodes were returned to full service after approximately 10.5 hours Cooper [Page 24] Internet Monthly Report April 1992 and Seattle after about 13 hrs of work. The new software had been deployed on the affected nodes during the prior week. The physical upgrade consisted of mechanical changes to the RS6000 machines including (1) replacement of the RS6000 I/O planar, (2) replacement of the Hawthorne T3 adapters with RS960 adapters, (3) upgrading the DSU hardware and associated cabling, (4) a modification of the cooling capabilities of the RS6000, (5) updating and standardizing on new labels and (6) local software configuration changes accommodating the use of new hardware. The nodes were then tested and returned to production service. Although the resulting configuration is very stable and gratifying to the team working on the upgrade, the process was not quite as smooth as had been expected. There were 33 RS960 T3 interface adapters, T3 DSUs, and 9 I/O planars installed. Out of these, 5 RS960 adapters and 2 I/O planars had to be replaced to achieve stability. The failing new components were air-shipped back to the staging lab for a complete failure analysis. and a summary of the results are described below. All of the problems involving replaced components have been identified or explained. The post-manufacturing burn-in and staging process consists of a stress test involving card-to-card traffic testing, DSU testing, and power cycling prior to shipping. Lab burn-in and staging procedures have been adjusted based upon our experiences with the first deployment step. The installation procedures will be fine tuned to improve our efficiency and reduce the installation time required. It is therefore our intention to continue with the step 2 deployment plan in the San Francisco and Los Angeles backbone nodes (and adjacent ENSS nodes) on Friday evening 5/1. Installation Problems Encountered ================================= The replacement of the RS6000 I/O planers had to be performed twice on nodes CNSS88 and CNSS91 after the nodes did not come up properly the first time. The original set of planers were returned to the lab for analysis. It was determined that the underside of the planars were damaged during the physical installation process. The procedure for installing these planars in the RS6000 model 930 rack mounted system has been modified to prevent this type of damage from occuring. Adapter re-seating and reconfiguration was required on the asynchronous communications adapter on CNSS89. Cooper [Page 25] Internet Monthly Report April 1992 The dual planar change and troubleshooting work adversely affected the hard disk on CNSS88 and the disk image had to be reloaded from tape. An apparent dysfunctional DSU HSSI card connected to CNSS97 was replaced and was returned for lab failure analysis. The analysis revealed that a DSU microprocessor was not properly seated. T3 Technologies will re-inspect the DSUs for proper seating of all DSU components. The DSU at ENSS142 (Salt Lake City) needed internal work. The analysis revealed a bent pin on the connector between the HSSI card and the DSU backplane. T3 Technologies Inc. (DSU manufacturer) identified a mechanical deficiency in the connector that can cause certain pins to loosen and bend during insertion of the card. T3 Technologies will add a procedure to inspect these connectors prior to shipment for any deficiencies. An RS960 T3 card in CNSS89 did not have the correct electrical isolation spacers installed, and this caused a temporary short circuit. The card was returned to the lab and it was determined that a last-minute change was made to the card to swap an i596 serializer chip and that the spacer was erroneously left off. A visual inspection procedure for spacers and standoffs will be added to the manufacturing and staging inspection process. The RS960 T3 card in CNSS97 came up in a NONAP mode, however the card continued to respond to DSU queries. The card was replaced. During the failure analysis, the card passed all stress tests. This card was swapped prior to a planar change and the NONAP mode has been attributed to the planar problem. When reliable connectivity could not be achieved between CNSS97<- >ENSS141, another RS960 T3 card in CNSS97 was replaced. The lab failure analysis revealed that the 20Mhz oscillator crystal on the card was broken due to a mechanical shock. This shock could have occured during shipping or handling. CNSS91 rebooted after the upgrade and exhibited an unstable configuration. Both the I/O planar and the RS960 T3 card were changed before stable operation was achieved. The RS960 card was later found to have a cold solder joint between the RAM module and adapter. The solder joint would allow the card to work when cold, but would fail intermittently when running hot. A simple adapter thermal cycling procedure will be investigated to determine if this problem can be avoided in the future. Cooper [Page 26] Internet Monthly Report April 1992 CNSS88 was the last node to come up. The I/O planar and memory card had to be reseated, and an RS960 T3 card replacement was necessary. The RS960 card was found to have a solder splash that was overlapping two adjacent pins. A general corrective action for this problem involves adding a procedure involving high magnification visual microchannel interface inspection for shorts. Conclusions =========== Although the Step 1 installation was complicated by several component problems, the entire deployment team (IBM, Merit, ANS, MCI) has a high comfort level with the results of the failure analysis, the stability of the resulting installation, and overall deployment process. We are very encouraged that we have completed this first step and acheived a very stable configuration within the time, human resources, spares and support that was provisioned as part of the deployment plan. The software bring-up and test scripts worked exactly as planned. The teamwork between the 50+ individuals involved at Merit, IBM, MCI and ANS was excellent. The basic installation process is sound, although some minor changes will be implemented in the future installation steps. These will include the RS960 adapter installation, DSU trouble-shooting procedure and the I/O planar change process. Also the number of spares provisioned in a deployment kit will be increased as a pre-caution for future installations. There has been one software problem identified with the new technology on the test network since the end of system testing on 4/17. This involves a microcode bug where a portion of the RS960 on-card memory will not report a parity error to the system if that portion of the memory suffers a failure. All RS960 on-card memory is tested prior to shipment and a microcode fix to this problem will be delivered by IBM for testing within the next week. Only a single RS960 adapter has demonstrated an on-card memory parity error during all test network testing. Next Steps ========== Step 2 of the deployment is currently scheduled to commence at 23:00 local time on 5/1. Step 2 will involve the following nodes/locations: Cooper [Page 27] Internet Monthly Report April 1992 May 1/2 San Francisco, Los Angeles core nodes T3 ENSS Nodes: Palo Alto E128, San Diego E135, Other ENSS Nodes: E144, E159, E156, E170 also affected Second core node visit: Seattle T3 Backbone RS/960 Deployment Status - Week 2 ============================================= Step 2 of the phase-III network upgrade was successfully completed last Saturday 5/2. The following T3 backbone nodes are currently running with new T3 hardware and software in a stable configuration: Seattle POP: CNSS88, CNSS89, CNSS91 Denver POP: CNSS96, CNSS97, CNSS99 San Fran. POP: CNSS8, CNSS9, CNSS11 L.A. POP: CNSS16, CNSS17, CNSS19 Regionals: ENSS141 (Boulder), ENSS142 (Salt Lake), ENSS143 (U. Washington) ENSS128 (Palo Alto), ENSS144 (FIX-W), ENSS135 (San Diego) CNSS8, CNSS16, CNSS96 are now running with mixed technology (e.g. 3xRS960 T3 interfaces, 1xHawthorne T3 interface). Production traffic on the affected Bay Area ENSS nodes was cutover to the T1 backbone at 2:00 AM EST on 5/2. Production traffic on ENSS135 was cutover two hours earlier. The San Francisco and Los Angeles POP nodes were returned to full service by 10:50 AM EST on 5/2, well within the planned maintainence window. The maintainence in the Los Angeles POP was complicated by the curfew existing at that time. Normally a specially trained 2-3 person deployment team is scheduled to perform these upgrades at each POP location. Because of the circumstances in Los Angeles, a special IBM engineer (Carl Kraft) from Gaithersberg, Maryland was deployed to the Los Angeles POP to perform the upgrade by himself. Carl was able to upgrade the node single-handedly on schedule. Several new procedures were developed following the first deployment step in Seattle and Denver on 4/25. These procedures helped to reduce the installation window and number of installation problems experienced on 4/25. The only problem experienced was the supected failure of a single RS960 adapter during the installation at ENSS128 (Palo Alto). This problem was isolated to the adapter within several minutes and the adapter was swapped resulting in successful operation of the node. Cooper [Page 28] Internet Monthly Report April 1992 A subsequent failure analysis of the RS960 adapter has not resulted in any reproducible problems, and has been attributed to an improper seating of the adapter in ENSS128 during the initial installation. Next Steps ========== Based upon the successful completion of step 2 of the deployment, step3 is currently scheduled to commence at 23:00 local time on 5/8. Step 3 will involve the following nodes/locations: Chicago POP: CNSS24, CNSS25, CNSS27 Cleveland POP: CNSS40, CNSS41, CNSS43 New York City POP: CNSS32, CNSS33, CNSS35 Hartford POP: CNSS48, CNSS49, CNSS51 San Fran. POP: CNSS8 (Second visit to CNSS8->CNSS24 Interface) Regionals: ENSS130 (Argonne), ENSS131 (Ann Arbor), ENSS132 (Pittsburgh) ENSS133 (Ithaca), ENSS134 (Boston), ENSS137 D (Princeton) Other ENSS's Affected: E152, E162, E154, E158, E167, E168, E171, E172, E163, E155, E160, E161, E164, E169 The system software (build 2.78.22) required to support RS960 installations has been fully deployed to all T3 network nodes as of early this week. New rcp_routed software has also been installed on all T3 nodes, although this is not a pre-requisite for any phase-III deployment activities. The new rcp_routed software has enhancements including support for externally administered inter-AS metrics, an auto-restart capability, and a fix for the invalid acceptance by the ENSS of a route to itself from a peer. Following the step 3 deployment, selected T3 internal link metrics will be adjusted to support load balancing of traffic across the 5 different hybrid technology links that will exist. The selection of these link metrics has been chosen through a calculation of traffic distributions on each link based upon an AS<->AS traffic matrix. This step of the deployment involves 4 POPs, and will complete the coast to coast RS/960 path for a large proportion of the backbone traffic. During the step 3 deployment, the Ann Arbor ENSS will be isolated from the T3 backbone. Since the Merit/ANS NOC is located in Ann Arbor, and Merit's backup connectivity to the backbone will be through the T1 network, we are implementing a backup network management machine. The "rover" monitoring tool is running on an Cooper [Page 29] Internet Monthly Report April 1992 unused RS/6000 CNSS at the Denver POP, and its data collection capability will be used if there is any problem with Merit's connection to the T3 backbone. Also during this deployment the Princeton ENSS will be isolated from the backbone. This means that both the Ann Arbor T1/T3 interconnect gateway and its backup at Princeton will not be operational. Therefore on Friday night we will run the Houston interconnect as primary, and temporarily configure the San Diego interconnect gateway as secondary with load sharing being handled as with the Ann Arbor/Houston configuration. Mark Knopper (mak@merit.edu) Jordan Becker (becker@ans.net) NSFNET/INFORMATION SERVICES --------------------------- Luxembourg is the newest international site among the now 1,806 foreign networks configured for announcement on the NSFNET infrastructures. A total 5,291 networks are configured at the close of April 1992, with 3,547 nets announcing to the T3 backbone. April packet traffic on the NSFNET is discussed in the NSFNET/ANSNET Backbone Engineering report to the Internet Monthly Report. NSFNET statistics are available for anonymous ftp from the directory /nsfnet/statistics on the host nis.nsf.net. The proposed revision of "Management of Federal Information Resources," Circular No. A-130 of the Information Policy Branch of the Office of Management and Budget is available for anonymous ftp from nis.nsf.net as /omb/omb.a130.rev1 . This document may also be retrieved by sending an electronic mail message to nis- info@nis.nsf.net: ignore the subject field, and enter send omb.a130.rev1 as the first line of the message. Comments may be sent via electronic mail to omba130@nist.gov and will be included as part of the official record. The Subcommittee on Science of the House Committee on Science, Space and Technology, held a public hearing on the "Management of the NSF Network" on March 12, 1992 in the Rayburn House Office Building. Oral and written testimonies given during these proceedings are available for anonymous ftp from nis.nsf.net in the directory /internet/legislative.actions/hearing.12mar92 . Elise Gerich, Merit Internet Engineering, presented the "Report on the Routing and Addressing (ROAD) Meetings" at the meeting of RIPE in Amsterdam, The Netherlands. Mark Davis-Craig, Merit Information Services Specialist, gave an overview of the NSFNET project at Cooper [Page 30] Internet Monthly Report April 1992 "Information Technologies on the Frontiers of Learning" sponsored by the University of Montana, Missoula. Florida State University (Tallahassee) invited Laura Kelleher, Merit/NSFNET Information Services, and Dana Sitzler, Merit/MichNet Recruitment, to speak about the Internet and its resources with faculty, students and members of FIRN, the Florida Information Resource Network for K-12 educators. Kelleher and Sitzler also met with the America 2000 initiative to discuss networking issues and ongoing programs in other states. Registration for "Making Your NSFNET Connection Count," a Merit Networking Seminar hosted by NevadaNet at the UNLV Campus, remains open. Donna Cox, director of Numerical Lab Programs at the National Center for Supercomputer Applications will be the keynote speaker. Closing remarks will be by Laura Breeden, executive director of the Federation of American Research Networks (FARNET). To receive the agenda and registration details, send electronic mail to seminar@merit.edu or call 1-800-66-MERIT. Jo Ann Ward (jward@merit.edu) SAIC ---- In April the VGP module was fully integrated and tested. However, a two PG/VG model is currently assumed to allow some simplification of the protocol messages. Also, the implementation assumes homogenous intra-AD policy and does not implement the policy specific VGP messages. Originally setup was the next candidate for integration, however, we chose to move on to the routing information distribution module at this time instead to better streamline use of our resources. Because of funding reallocation for our current contract we have had to scale down some parts of the implementation effort. IDPR experimentation must also be scaled down at this point. There have been some discussions of a cooperative effort with other interested parties and these will be evaluated during May once the fully operational GATED implementation is available. The ISODE_SMUX interface for SNMP available with GATED is sufficient for implementation of the IDPR MIB. However, because of the reduction of funding, there are no current plans to implement the MIB. Ken Carlberg has completed an implementation of multicast extensions to CLNP with Bob Harris from Sparta. A demo is scheduled for May 13th. Cooper [Page 31] Internet Monthly Report April 1992 Planned Activities: This is the final stretch for the GATED implementation of IDPR. The remaining modules will be integrated and tested during the first three weeks of May. Lab experimentation with policies will begin in June and extend until the beginning of July. It is expected that some wider experimentation and demonstration will take place in July. Woody Woodburn will be traveling to SRI in Menlo Park, CA to help them use this new IDPR implementation in a policy based application. Robert "Woody" Woodburn SDSC (SAN DIEGO SUPERCOMPUTER CENTER) ------------------------------------- SDSC Network Activities Since our last report several things have happen in San Diego. CERFnet has moved out of our building for larger digs down the street at General Atomics. SDSC & CERFnet have made several local routing changes to support an expanded FDDI and to more fully use the T-3 NSFnet. The single AS 195 both had used was split such that CERFnet now has their own (AS 1740). This exercise was followed by several days of routing changes. We now have a configuration which seems stable and has the major routing functions being servered by boxes which are not also very busy packet switches. We are looking forward to the 2 May upgrade of our ENSS. SDSC was local host to the 23rd Internet Engineering Task Force meeting at the Hyatt Islandia 16-20 Mar. Donations where made by PacBell of a T-1 circuit for the meeting and by DEC, SUN, HP, NCD, Verilink, GA, and UCSD of networking equipment, workstations, X- Terms, etc. CERFnet provided the Internet IETF was the first to carry portions of the proceedings via packet audio. A lot of hard work was put in by Susie Arnold, Don Doering, Jay Dombrowski, Rich Gallup, Tom Hutton, Kevin Fall, John Moreland, Gerard Newman, Rick Pattela, and Mike Robertson to get everything installed and operational on time. The local hosts were Hans-Werner Braun and Paul Love. Cooper [Page 32] Internet Monthly Report April 1992 SDSC participated in the joint Merit/FARnet demonstration area at National Net92. We are in the process of upgrading our UltraNet to version 4.0. Miscellaneous Paul Love attended the NSF/FARnet "Tempering the Network" workshop held in Orlando, FL., and a FARnet board retreat held at University of Maryland. SDSC Applied Network Research Group SDSC is pleased to welcome Bilal Chinoy to the ANR staff of SDSC as of Feb. For several years, Chinoy has been involved in advanced networking issues, including analysis, planning, engineering and operations at Merit. He was instrumental in the implementation of the NSFNET backbone project. Chinoy will be of great benefit to the SDSC Applied Network Research group. Chinoy will be devoting his attention to a NSF sponsored network analysis and modeling project. He will also be working on the CASA gigabit testbed project, for which he is a SDSC co-PI. CASA gigabit project Chinoy is continuing the efforts in progress on the HIPPI network simulator. These are in cooperation with researchers at LANL. We also expect to soon begin network performance related work on our HIPPI crossbar switch connected to the SDSC CRAY Y-MP. Network analysis project Research efforts are continuing in the development of systematic methodologies for network analysis and performance testing. Our investigations involve very large data sets, often in the size range of 500 megabytes to 1 gigabyte. For the most part the analysis programs utilize an RS6000 workstation contributed by IBM for projects related to network analysis. We have completed a collaborative investigation with a group of network analysts in Japan, and are currently in the middle of another collaborative effort with researchers at FIX-West at NASA- Ames. Both studies are one shot examinations of relatively short intervals of network traffic. The measurement methodology was equivalent: we collected packet header traces at the remote site, and subsequently performed local post-processing on the collected data. Cooper [Page 33] Internet Monthly Report April 1992 We are also currently investigating NSFNET statistics collected operationally by Merit, and trying to extract meaningful insights from the data. Analysis efforts are currently focused on the following areas: - latencies and their relationship to resource consumption - performance degradation under resource starvation - levels of granularity of both analysis and sampling - application distribution - geographic traffic distribution. During the March IETF meeting held in san Diego, the Applied Network Research Group gave a presentation at a plenary session. The group also participated in an IETF BOF dedicated to wide area network traffic characterization. One of our long-term goals is to arrive at a set of requirements for evaluating and instrumenting high speed, wide area networks. We hope these and other activities at SDSC encourage collaborative efforts within the community in the area of high speed network traffic characterization. by Paul Love SRI ---- SRI's Network Information System Center (NISC) updated the RFC Index in response to each RFC issued in March and April. There were eight RFCs issued in March 1992 and ten RFCs issued in April 1992. The RFC Index contains citations of all RFCs issued to date in reverse numeric order. It's also a quick reference to determine if any RFC has been obsoleted and gives a pointer to the replacement RFC. The RFC Index also supplies the equivalent FYI number, if the RFC was also issued as an FYI document. Paper copies of all RFCs are available from SRI, either individually or on a subscription basis (for more information contact nisc@nisc.sri.com or call 1-415-859-6387). Online copies are available via FTP from ftp.nisc.sri.com as rfc/rfc####.txt or rfc/rfc####.ps (#### is the RFC number without leading zeroes). Cooper [Page 34] Internet Monthly Report April 1992 Additionally, RFCs may be requested through electronic mail from SRI's automated mail server by sending a message to mail- server@nisc.sri.com. In the body of the message, indicate the RFC to be sent, e.g. "send rfcNNNN" where NNNN is the number of the RFC. For PostScript RFCs, specify the extension, e.g. "send rfcNNNN.ps". Multiple requests can be sent in a single message by specifying each request on a separate line. The RFC Index can be requested by typing "send rfc-index". April Marine, co-chair of the Network Information Services Infrastructure User Services Working Group of the IETF, attended the March 1992 meeting of the IETF held in San Diego, California. One of the major topics discussed was locating and indexing information on the Internet via tools such as Archie, WAIS, and Prospero. Two new documents, Internet:Getting Started and Internet:Mailing Lists, are now available from the NISC. Contact the NISC directly for more information. Sue Kirkpatrick UCL ---- Two reports describing recent work are available: 1. Multimedia Conferencing: from prototype to national pilot At University College we have developed a multimedia conferencing system as part of the CAR project funded by the European Commission RACE Program. This conferencing system is aimed at assisting distributed collaborative design in the automotive industry. It runs over basic rate ISDN lines, with video and audio provided by integrated video switching and ISDN video codecs. This paper describes some of our experiences with wide area multimedia conferencing, both from the workstation based approach and from the point of view of interconnecting studios and large conferences using digital networks. We are currently involved in the planning of the SuperJanet broadband network which will enable routine use of multimedia services between research and academic institutions in the United Kingdom. We describe some of the services that it will be possible to provide, both for workstation and studio based multimedia services, and the necessary local infrastructure that will be required. Cooper [Page 35] Internet Monthly Report April 1992 (To be presented at INET 92 in Kobe) postscript in: car-inet92.ps 2. Lessons and Challenges of Distributed Computing This document is edited from a number of contributions to a lively debate on the lessons and challenges of distributed computing. The debate was initiated by Prof A Tanenbaum on the bulletin board comp.os.research. The text is almost entirely culled from the bulletin board contributions, except for occasional introductory material indicated by the use of bold font. postscript, or compressed (binary) postscript in: dos-sum.ps or dos-sum.ps.Z ftp from cs.ucl.ac.uk (128.16.5.31), both in directory car/ John Crowcroft (j.crowcroft@CS.UCL.AC.UK) UNIVERSITY OF DELAWARE ---------------------- 1. The NTP Version 3 specification document has appeared as rfc1305. It is in PostScript form in three files rfc1305{a|b|c}.ps which will probably dim the lasers of the less ambitious printers. Those lacking that ambition may see the ASCII mangling in rfc1305.txt, but not the figures, tables and equations necessary to fully understand the stuff. 2. We have given up, at least temporarily, finding the varmit causing the interference to our WWVB timecode receiver and sent the spare receiver to MIT for use there. Meanwhile, our NTP-in-a-box gadget expired and was returned for repair. However, we now have a working GPS receiver, but are in the midst of an antenna resiting project. Time lurches on. Dave Mills (Mills@UDEL.EDU) Cooper [Page 36] Internet Monthly Report April 1992 WISCNET ------- Line reset problems in the Milwaukee area were traced to software interactions between saturated router interfaces on the UW- Milwaukee router. Some relief was effected by reallocation of bandwidth on the underlying T1 network providing more bandwidth on the Milwaukee - Madison link. The problem was resolved by installation of new software on the UW-Milwaukee router. The software is being installed on all WiscNet routers. WiscNet recently sponsored the first of what it expects to be annual conferences on topics of interest to members. WiscNet Conference 1992, organized by the network's User Services Committee and held at the University of Wisconsin - Stevens Point April 28 and 29, was developed around the theme "Highway to Resources: Providing Services Easily and Effectively." Timed to dovetail with the annual conference of the Wisconsin Association of Academic Librarians, the WiscNet event drew more than 190 attendees together for 11 sessions covering such topics as desktop TCP/IP, ethics and policy in computing, electronic libraries in action, access to Internet resources, multicultural opportunities in the classroom, and so forth. Speaking at a general session, keynoter Paul Evan Peters, Director of the Coalition for Networked Information, highlighted rapidly unfolding developments in networking that are creating an entirely new environment for the management and use of information, amounting to a co-evolution of technological, intellectual, and organizational models. Conference attendees comprised both computing and library professionals. Responses to the conference sessions were enthusiastically positive. Plans are already underway for a second annual conference, to be held next year. Jess Anderson (anderson@macc.wisc.edu) Michael Dorl (dorl@vms.macc.wisc.edu) Cooper [Page 37] Internet Monthly Report April 1992 DIRECTORY SERVICES ------------------ This section of the Internet Monthly is devoted to efforts working to develop directory services that are for, or effect, the Internet. We would like to encourage any organization with news about directory service activities to use this forum for publishing brief monthly news items. The current reporters list includes: o IETF OSIDS Working Group [no] o IETF DISI Working Group [no] o Field Operational X.500 Project [no] - ISI [no] - Merit [no] - PSI [no] - SRI [no] o National Institute of Standards and Technology [no] o North American Directory Forum [no] o OSI Implementor's Workshop [no] o PARADISE Project [no] o PSI DARPA/NNT X.500 Project [included] o PSI WHITE PAGES PILOT [included] o Registration Authority Committee (ANSI USA RAC) [included] o U.S. Department of State, Study Group D, MHS Management Domain subcommittee (SG-D MHS-MD) [included] o USENET-Addresses Database [included] Additionally, this month's DSAR features a special item: a report on the X.500-accessible "usenet-addresses" database being developed at UIUC. Tom Tignor (tpt2@isi.edu) DS Report Coordinator PSI DARPA/NNT X.500 Project --------------------------- Much of the work performed this month was related to following up on the Internet Engineering Task Force meeting last month. In particular: - A preliminary draft of a MIB that current instruments X.400 MTAs and X.500 DSAs was reviewed. Comments have been submitted to the author. - Based on comments received on the LDBP at the IETF meeting, the scope of the protocol was expanded to include simple Directory management, and a new specification, Cooper [Page 38] Internet Monthly Report April 1992 renamed the Lightweight Directory Access Protocol (LDAP) has been resubmitted. - A new draft of RFC1279 containing changes suggested at the IETF meeting was reviewed. A minor modification was also made to the 'fred' software due to a bug that was uncovered during the IETF discussion on the DNS in X.500. Beta testing was performed on an interim release of the ISODE QUIPU software. Further testing will be performed over the next few months. Wengyik Yeong (yeongw@psi.com) PSI WHITE PAGES PILOT PROJECT ----------------------------- The following organizations joined the pilot this month: Martin Marietta Indiana University Harvey Mudd College University of Akron Wengyik Yeong (yeongw@psi.com) REGISTRATION AUTHORITY COMMITTEE (ANSI USA RAC) ----------------------------------------------- The USA-RAC (ANSI USA Registration Authority Committee) is working on plans to restructure the way it has been using a single arc under ISO { iso (1) member-body (2) us (840) } for registration of State Names, ANSI Standards, and Private Organizational Names with US National Standing. The primary motivation is provided by the recent changes in ISO 9834-1 (also now known as CCITT X.660) which requires that Organizational Names with National Standing be henceforth registered under a new joint arc ( joint-iso-ccitt (2) country (16) us (840) }. It has recently become apparent that the original scheme for registering several different types of names, which are used for different attribute values (as in X.500 stateOrProvince and Organization) will only cause trouble in the future. The plan that is developing, but which is not yet adopted by anyone, is projected below. This is an informal report and is not Cooper [Page 39] Internet Monthly Report April 1992 blessed by USA-RAC in any way. First let me describe the original scheme: 1. The FIPS-5 registration of all US States and State Equivalents which has been done by a US Government Commission was copied (both alpha and numeric assignments) into the lowest 100 numeric name slots. This is a poor idea in any case, since it is always bad to copy in this way, and hope to stay in sync over time. 2. ANSI Standards were allocated the numeric name spaces between 10,001 and 20,000. 3. Organizations were allocated all the numeric name spaces above 113,527 to 16,000,000. Any name registered in these ranges must have a numeric value assigned, and may also have a single Alphanumumeric value associated with the Numeric value in the register. Second, here is the new plan, with transitions as indicated: It is clear that policy control over { 2 16 840 } must be shared between ANSI and the US Dept of State. 4. The new arc will only register subauthorities, such as FIPS-5, and will not copy anything from FIP-5. These are (for the moment): { 2 16 840 fips-5(1) }, { 2 16 840 organizations(2) }, and { 2 16 840 mhsmd(3) } 5. The FIPS-5 commission will be delegated to maintain the ( 2 16 840 1 } register. This supports the NADF plan to use FIPS-5 as the source of values for the stateOrProvince RDN AVAs under c=US. The current "registration" of states in { 1 2 840 } will simply be abandoned, since no one has registered anything under them as yet. 6. ANSI is expected to operate the ( 2 16 840 2 } register of organizations with national standing. Existing registrations of organizations (approximately 54 at this date) in { 1 2 840 } will be copied over to the new { 2 16 840 2 } arc with the same values at no charge to the registrant. Cooper [Page 40] Internet Monthly Report April 1992 This causes some complications, since this will give current organizational registrants a second OID prefix to administer. Registrants get their choice of which arc they wish to use. It will be recommended that they not add new registrations to the { 1 2 840 n } arcs they now have, and use the new { 2 16 840 n } arc instead, for new object definition registrations. X.500 use of their registered Alphanumeric Names will not be affected in any way. 7. A new arc { 2 16 840 3 } will be established for MHSMD name registrations. 8. ANSI Standards will be left where they are under { 1 2 840 }. 9. The numeric values under { 2 16 840 organizations(2) } are planned to be used for NSAPs with AFI of 38 or 39, and IDI of 840; for OID registration of information objects in organizational (sub)authority registers, and for AETitle registrations in organizational (sub)authority registers. AETitles, per new draft ISO standards will require a pair of Alphanumeric and Numeric values such that either can be used as a DN in X.500 to dereference the AETitle DN in an X.500 DIT. I expect that one will be an alias for the other in most instantiations, but it is conceivable that they might be instantiated with replications of the same entry. Respectfully submitted without USA-RAC blessing by...Stef Einar Stefferud (stef@ics.uci.edu) SG-D MHS-MD ----------- After considerable turmoil with a change of Chair and a great deal of deep thought, MHSMD is moving toward consensus on a number of key issues. This report does not report official positions, but contains my interpretation of where things seem to be headed. Registration of MHSMD Names: ++++++++++++++++++++++++++++ I has been concluded (pretty much) that there is just no way to overlay the ANSI Organizational Name Registry with the MHSMD Name Registry, so they are about to become divorced and exist as separate uncoordinated name space registries. This means that a currently registered ANSI Organizational Name will not be usable as an ADMD or PRMD name in an X.400 ORAddress in /C=US/ without also Cooper [Page 41] Internet Monthly Report April 1992 registering it in the new MHSMD Name Registry. (Sorry about that!) There are many many reasons for this, but the primary one is that the two name spaces simply have very different requirements which make it impossible to devise a single set of policies for a joint use register. For one, the character sets and string lengths are different. X.400 limits MHSMD names to 16 characters of printable string, and this creates a serious real estate problem and increases the likelyhood of collisions. I will not try to delineate the entire list of such issues. I hope it will suffice to say that there will be two separate and uncoordinated registers. This means that no attention will be paid to who has registered what names in the other register, although we expect the owners of registered names to pay attention for possible encroachment. It should help to note that by and large, people just do not pick names that will be confused with other names when they are selecting distinctive names. Also, it is agreed in principle that MHSMD Registry Names will not be accompanied by any Numerical Name Value (a Numberform Value), since there is no need for such things in X.400. This eliminates a serious conflict (Standards Defect) wherein Numberform Values and Printable strings that consist of only digits are not distinguishable in the X.400 protocol. With no Numberform Values assigned in /C=US/, this problem goes away for /C=US/ Oraddresses. Next, it is proposed that the MHSMD Name Register should be lodged as an arc under the new {joint-iso-ccitt(2) country(16) us (840) } arc which we understand must be jointly controlled by ANSI (the ISO MemberBody for c=US), and the US Dept of State (the CCITT MemberBody for /C=US/). This new arc is administered under the rules stated in CCITT X.660 which is a duplicate of the text in the revised ISO 9834-1. MHSMD is currently working very closely with USA-RAC to achieve total sync. Much of this is done via dual memberships, and the rest is done with joint meetings. There is more to the MHSMD Name Space Story (namely (sub)authorities), but we need some discussion of ADMD/PRMD Behavior Rules first. Cooper [Page 42] Internet Monthly Report April 1992 Behavioral Rules for ADMD and PRMD operators: ++++++++++++++++++++++++++++++++++++++++++++ This work is less well formed at present, but I can say some things for certain. The ITU (International Telecommunications Union) Treaty requires that every country (including /C=US/) must arrange for any foreign X.400 ADMD operator to be able to connect to and thus accomplish delivery of messages to any user of any ADMD Service Provider's X.400 services, and vice versa. (This is the best I am able to state this in brief.) So, it is imperative for the /C=US/ ADMD Operators to voluntarily organize themselves to accomplish this, hopefully without Congressional, FCC, or other US Government action to make it happen. So, here is what seems to be jelling: The proposed plan is patterned after the British Standards Institute (BSI) requirements for all /C=GB/ ADMD operators to join in forming a single GB backbone, and giving every PRMD customer the unilateral choice of using the ADMD name of the Backbone (i.e., ), or using the name of their ADMD service provider (i.e., BT GOLD). The really big difference is that MHSMD envisions backbone participation to be voluntary on the part of every ADMD Service Provider, so there will be some ADMD service providers which are not participants. All ADMD service providers will be required however to be able to connect with all others in /C=US/ and to handle mail to and from any foreign ADMD service providers. Under the ITU treaty, ADMD service providers cannot remain unconnected for purposes of supporting X.400 mail exchanges with foreign ADMD service providers. The ITU says nothing about domestic interconnection requirements. A second very important difference between /C=US/ and /C=GB/ is that it is agreed that the name used to identify the /C=US/ X.400 backbone will not be . MHSMD recognizes and agrees that is a terrible name, and that it carries with it some risk that some foreign ADMD operators my unilaterally refuse to honor or route on such a name (though the standards do not offer them this option). We just don't want to mess with the issues, and they can all be circumvented by choosing a real name with visible characters, and which is indistinguishable from any other character-full name. Cooper [Page 43] Internet Monthly Report April 1992 (I cannot help but note with some humor that X.400 disallows any ADMD or PRMD name to contain any leading or trailing blanks, and then at the same time, allows a to be an ADMD Name which in a single character contains both violations.) The temporary /C=US/ backbone ADMD name used for now is USMTS. This is understood to be a placeholder while we search for an acceptable name to use. Proposals are welcome;-). Beyond this, the rules are not stable, but work is going on to examine the many possible scenarios of interconnection to be sure that there are no technical problems with compliance. It should be assumed that the involved ADMD service providers are all paying attention to the settlements issues, et al. A key concept is that the only information that must be shared among the ADMD participants in the /C=US/ backbone is reachability information regarding connected PRMDs. This is much like an MX record that only tells what ADMD can deliver to a given PRMD. We have not identified any other information that needs to be shared. Among the principles of agreement here is the idea that any PRMD must be allowed to decide what PRMD name it will use (within the limits of Intellectual Property Law which provides unicity), and which and how many ADMDs the PRMD will connect to. This leads to some requirements for "portable names" that can be used with any ADMD (e.g., National Uniqueness and National Standing so they can be used under /C=US/ADMD=USMTS/ in ORAddresses). The MHSMD Name Register is being defined to provide for registration of these names. MHSMD (Sub)Authorities and the Constructive Syntax: ++++++++++++++++++++++++++++++++++++++++++++++++++ You may have seen it around before, but here is a thumbnail sketch. By restricting the use of the +sign in certain ways, such as in an MHSMD registered name, we can use the +sign as a constructor in a name constructed by a subauthority, in much the same way that .dot delimits constructed DNS subdomain names. So, if an ADMD (or anyone else) permanently registers an MHSMD name in the MHSMD register, then that name may be used as the prefix for construction, by appending to it a +sign, followed by a "subauthority-determined-part". This should not seem odd to internet veterans. It is required that the (sub)authority registrant pay for a permanent (perpetual) name registration that will not expire Cooper [Page 44] Internet Monthly Report April 1992 because it must remain responsible for acting as a (sub)authority registrar for all the names that it constructs for PRMDs that register under it. Thus, you might someday see things like "PRMD=ATT+ACME SIGNS", etc. Or, "PRMD=MCI+1234". Or someone may register XYZ and go into business registering names like "PRMD=XYZ+MUMBLE". All these names, by the construction rules, are nationally unique and have national standing. Some people (many in DOE, the AIA, and EMA) intensely dislike this constructive syntax idea, because (they say) "such names are ugly and we don't want to see them in ORAddresses". There are also claims that allowing anyone to use such names will hurt the prognosis for X.400 deployment. My position on this is that if this kind of thing can seriously impact X.400 deployment, there must be something very wrong somewhere else! Actually what is now propelling the constructive syntax band wagon is that it serves to solve a very knotty problem with grandfathering all the names already in use in /C=US/ by our currently operating ADMDs. The tentative MHSMD agreements call for every ADMD operator to in fact be a (sub)authority (which must have a permanent MHSMD registration for its ADMD name). Then, each ADMD can register PRMD names in one of two ways: 1. In constructive syntax mode, or 2. In simple mode as a PRMD name that is qualified by the superior ADMD name. In this case, the registered PRMD name is only guaranteed to be unique when used in association with the registering ADMD. Mode 2 takes care of grandfathering whatever names are already in use. Mode 1 allows any ADMD to continue acting as an X.400 PRMD Name (sub)authority, with a capability of generating and registering PRMD names that are Nationally Unique and have National Standing, which will allow the registrant to use the name with any other ADMD, including USMTS. You should note that PRMD=MCI+1234 will be able to sign up with ADMD=USMTS using PRMD=MCI+1234. Cooper [Page 45] Internet Monthly Report April 1992 Conclusion: +++++++++++ I hope this all makes sense to everyone. It is being done to break a serious impasse that has stymied the work of MHSMD for the last 2 years. Respectfully submitted without MHSMD review by...Stef Einar Stefferud (stef@ics.uci.edu) USENET-ADDRESSES DATABASE ------------------------- The "usenet-addresses" database is about 200,000 e-mail addresses lifted from usenet news postings and indexed with WAIS (a Z39.50 implementation via Thinking Machines). It's running at wais.cic.net and at pit-manager.mit.edu. The data is also accessable via a wais to gopher gateway running at the U of Minnesota. The non-X.500 "phone book" protocol which seems to have gotten the widest implementation is the CSO name server, developed at UIUC. CSO phone books can be located with the help of gopher and searched through that interface. There is also a telnet-based X.500 search available via the Minnesota gopher. A challenge as I see it is to provide support for X.500 queries, either directly or via gateways, in the new crop of multi-protocol Internet browsing and searching clients (Gopher, World Wide Web, WAIS). This is complicated somewhat by the relative ease of software development in the TCP/IP and OSI environments. The appearance of "simple" X.500 interfaces, or translating gateways that spoke something dumb like finger on one side and retrieved directory entries out the other would ease in the integration process. Meanwhile, real users blunder on using whatever means are at their disposal -- business cards, yellow sticky notes, pocket organizers, etc. -- to locate and remember the mail addresses of colleagues. With ca. 7 million people on the net and more appearing all the time I guess it's not surprising that the process is harder than you'd hope it might be. Edward Vielmetti, Vice President for research, MSEN Inc. (emv@msen.com) MSEN Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 741 1120 Cooper [Page 46] Internet Monthly Report April 1992 CALENDAR -------- Readers are requested to send in dates of events that are appropriate for this calendar section. 1992 CALENDAR May 4-6 ANSI X3T5 May 4-8 DECUS '92, Atlanta, GA May 4-8 IEEE INFOCOM'92, See IEEE Pub., Florence, Italy May 11 T1E1, Physical Layer Interfaces (ISDN, T1, Broadband, etc.) Williamsburg, VA, Bell Atlantic May 12-14 Joint Network Conference 3, Innsbruck, Austria (this is the RARE Networkshop - renamed) May 13-15 Third IFIP International Workshop on Protocols for High Speed Networks, Stockholm, Sweden Contact: Per Gunningberg, per@sics.se Bjorn Pehrson, bjorn@sics.se, Stephen Pink, steve@sics.se May 18-25 INTEROP92, Washington, D.C. Dan Lynch (dlynch@interop.com) May 19-29 ISO/IEC JTC 1/SC 21, Ottawa, Ontario, Canada May 27-29 IFIP WG 6.5 Int'l Conference on Upper Layer Protocols, Architectures and Applications Vancouver, Canada plattner Gerald Neufeld Jun 8 T1M1, Management and Maintenance (ISDN, Broadband, Frame Relay, etc.) Minneapolis, MN, ADC TElecom Jun 8-12 OIW, NIST, Gaithersburg, MD Jun 10-11 RARE WG1, tentative-Location unknown Jun 11-12 RARE COSINE MHS MGR, tentative-Location unknown Jun 14-17 ICC-SUPERCOMM'92, Chicago, IL. See IEEE Publ.. Jun 15-19 INET92, Kobe, Japan Jun Murai (jun@wide.ad.jp), KEIO University Elizabeth Barnhart (barnhart@educom.edu) "North America Contact" Jun 23-25 ANSI X3S3.3, Raleigh, NC Jun 22-25 PSTV-XII, Orlando, Florida Umit Uyar, ATT Bell Labs, Jerry Linn, NIST Jun 29-Jul 1 Fourth Workshop on Computer-Aided Verification (CAV 92); see Sigact News, Vol, 22 No. 4 Montreal Canada G. Bockmann: bochmann@iro.umontreal.ca Cooper [Page 47] Internet Monthly Report April 1992 Jul 6-10 IEEE802 Plenary, Bloomington, MN Jul 13-17 ANSI X3T5 Jul 13-17 IETF, Cambridge, Mass. Jul 13-24 ISO/IEC JTC1/SC6, San Diego, CA Aug 2 T1S1, Call Control and Signaling (ISDN, Frame Relay, Broadband ATM) Aug 16 T1S1, Call Control and Signaling (ISDN, Frame Relay, Broadband ATM) Aug 17-20 SIGCOMM, Baltimore, MD Deepinder Sidhu, UMBC Aug 18-21 ACM SIGCOMM '92, Baltimore, Maryland Aug 24-27 CONCUR '92 -- Third Int'l Conference on Concurrency Theory (Paper deadline March 1, 1992) Rance Cleaveland (rance@csc.ncsu.edu) Scott Smolka (sas@sunysb.edu) Stony Brook Sep 7-11 12th IFIP World Computer Congress Madrid, Spain; Contact: IFIP92@dit.upm.es Sep 8-10 ANSI X3S3.3, Minneapolis, MN Sep 14-18 ANSI X3T5 Sep 21-25 OIW, NIST, Gaithersburg, MD Sep 28-30 5th IFIP International Workshop on Protocol Test Systems (IWPTS), Montreal, Canada iwpts@iro.umontreal.ca Oct 12-16 FORTE'92, Lannion, France Roland Groz (groz@lannion.cnet.fr) Michel Diaz (diaz@droopy.laas.fr) Oct 26-30 INTEROP92, San Francisco Dan Lynch (dlynch@interop.com) Oct 28-29 NETWORKS '92, Trivandrum, India S.V. Raghavan (raghavan@shiva.ernet.in) Nov 8-11 Twentieth ACM/SIGUCCS Conference Stouffer Tower City Plaza Hotel, Cleveland, Ohio Al Herbert (HERBERT@UAKRON.EDU) Nov 9-13 ANSI X3T5 Nov 10-12 ANSI X3S3.3, Mountain View, CA Nov 16-20 IETF, Washington, D.C. Dec 6-9 GLOBECOM '92, Orlando, Florida (See IEEE Publ.) Dec 7-11 DECUS '92, Las Vegas, NV Dec 14-18 OIW, NIST, Gaithersburg, MD Cooper [Page 48] Internet Monthly Report April 1992 1993 CALENDAR Mar 8-12 INTEROP93, Wasington, D.C. Dan Lynch (dlynch@interop.com) Mar 8-12 OIW, NIST, Gaithersburg, MD Mar 28-Apr2 IETF, Columbus, Ohio Apr 18-23 IFIP WG 6.6 Third International Symposium on Integrated Network Management, Sheraton Palace Hotel, San Francisco, CA (kzm@hls.com) May 23-26 ICC'92, Geneva, Switzerland May-Jun PSTV-XIII, University of Liege. Contact: Andre Danthine, May 23-26 ICC '93, Geneva, See IEEE Publications. Jun 7-11 OIW, NIST, Gaithersburg, MD Aug 18-21 INET93, San Francisco Bay Area Aug 23-27 INTEROP93, San Francisco Dan Lynch (dlynch@interop.com) Aug SIGCOMM, San Francisco Sep ?? 6th SDL Forum, Darmstadt Ove Faergemand (ove@tfl.dk) Sep 13-17 OIW, NIST, Gaithersburg, MD Sep 20-31 ISO/IEC JTC1/SC6, Seoul, Korea. Oct INTEROP93, Paris, France Oct 12-14 Conference on Network Information Processing, Sofia, Bulgaria; Contact: IFIP-TC6 Nov 9-13 IEEE802 Plenary, LaJolla, CA Dec 6-10 OIW, NIST, Gaithersburg, MD 1994 CALENDAR Apr 18-22 INTEROP94, Washington, D.C. Dan Lynch (dlynch@interop.com) Aug 29-Sep 2 IFIP World Congress Hamburg, Germany; Contact: IFIP Sep 12-16 INTEROP94, San Francisco Dan Lynch (dlynch@interop.com) 1995 CALENDAR Sep 18-22 INTEROP95, San Francisco, CA Dan Lynch (dlynch@interop.com) ------------------------------- Note: T1E1: Physical Layer Interfaces (ISDN, T1, Broadband, etc.,) T1M1: Management and Maintenance (ISDN, Broadband, Frame Relay, etc.) Cooper [Page 49] Internet Monthly Report April 1992 Cooper [Page 50]