home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / isoc / pub / isoc_news / 2-1 / issue2-1-complete.txt < prev   
Text File  |  1994-03-26  |  148KB  |  3,160 lines

  1.  
  2. ================================================
  3. n-2-1-002.01
  4.  
  5. President's Message
  6.  
  7. Dear Internauts:
  8.  
  9. As I write this, there is still a winter chill in the air, but the
  10. promise of Spring is evident in the daffodils poking their hesitant
  11. shoots skyward. Your Internet Society is preparing for the bloom
  12. of Spring, too.
  13.  
  14. Trustee elections are in preparation and I want to thank Trustee
  15. Geoff Huston and his committee (Member Rob Blokzijl, Trustee Ira
  16. Fuchs, Trustee Tomaz Kalin, Pioneer Member Craig Partridge and
  17. Member Hide Tokuda) for their fine work preparing a slate of a
  18. dozen candidates. In addition, two successful petition candidates
  19. round out the slate to a total of 14 for 6 slots on the Board of
  20. Trustees. Information about the candidates is available on-line and
  21. will be sent with the balloting material later this Spring.
  22.  
  23. IAB and IESG nominations are in progress and I want to thank
  24. Pioneer Member Jeff Case and his committee (Jack Brown, Pioneer
  25. Member Peter Ford, Pioneer Member Erik Huizer, Trustee Geoff
  26. Huston, Pioneer Member Stephen Kent, Pioneer Member Barry Leiner,
  27. Member Paul Mockapetris, Pioneer Member Craig Partridge, Pioneer
  28. Member Jon Postel, Jim Romaguera, and Pioneer Member Claudio
  29. Topolcic). They are working against an end of March IETF meeting
  30. deadline and their efforts are greatly appreciated.
  31.  
  32. Internet Society information is now available on-line from a host
  33. at CNRI: ietf.cnri.reston.va.us. Please see the box elsewhere in
  34. this issue for a summary of what is available.
  35.  
  36. INET '93 is coming up in August. General Chairman Eric Benhamou
  37. advises that there are still opportunities for corporate
  38. sponsorship (eric_benhamou@3mail.3com.com). Along these same lines,
  39. those of you whose companies or institutions are not yet
  40. organizational members of the Internet Society should give serious
  41. consideration this year. This year, for the first time, the
  42. Internet Society is sharing costs with the National Science
  43. Foundation, Department of Energy, Advanced Research Projects Agency
  44. and National Aeronautics and Space Administration in the support
  45. of the IETF Secretariat. Organizational sponsorship is essential
  46. to meet this commitment. Contact vcerf@cnri.reston.va.us for
  47. details.
  48.  
  49. A new committee to explore potential Internet Society involvement
  50. in the use of the Internet in primary and secondary education is
  51. being organized. If you have interests in this area and ideas and
  52. energy to contribute, please contact Bruce Nelson
  53. (Bruce_Nelson@novell.com) or Kathy Rutkowski
  54. (kmr@cnri.reston.va.us).
  55.  
  56. Finally, I want to remind all of you that the Internet Society is
  57. alert to opportunities to participate in, sponsor or otherwise
  58. encourage conferences and symposia relating to the Internet around
  59. the world. Proposals should be sent to Vice President Larry
  60. Landweber (lhl@cs.wisc.edu). The recent Computers, Freedom and
  61. Privacy Conference, IRTF Privacy and Security Research Group
  62. Workshop on Network and Distributed System Security, and Maryland
  63. Workshop on Very High Speed Networks are examples, as are the
  64. upcoming Joint European Networking Conference and National Net '93
  65. Conference.
  66.  
  67. I look forward greatly to seeing many of you in San Francisco at
  68. INET'93.
  69.  
  70. Warmest regards,
  71.  
  72. Vinton G. Cerf
  73.  
  74. ====================================================
  75. n-2-1-003.01
  76.  
  77. The Internet Peace Corps
  78.  
  79. by A.M.Rutkowski
  80. <amr@isoc.org>
  81.  
  82. Some thirty years ago, U.S. President John F. Kennedy rallied a generation
  83. to a new form of international public service at the grass roots.  The
  84. Peace Corps was created to motivate young and old to provide their own
  85. skills, creativity and energies to make a difference in working with
  86. other peoples around the world.  In an ultimate form of human leveraging,
  87. the Peace Corps measurably improved the condition of countless villages 
  88. and millions of people throughout the Third World.  In the process, it
  89. also changed the lives of those who volunteered, and established a proud
  90. new standard of assistance for a nation and the world.
  91.  
  92. One of the more remarkable attributes of the Internet is the ability for 
  93. this enormous network of networks to bring fundamental change and 
  94. empowerment to people throughout the world.  One of the more heartening
  95. attributes of the Internet community is the number of individuals and
  96. institutions that have effected a kind of collective virtual Internet 
  97. Peace Corps.  Many pages of the Internet Society News have been devoted 
  98. to their remarkable efforts and achievements.  Some have literally devoted 
  99. their lives to bringing Internet connectivity to technologically developing
  100. countries of the world.  In addition, the Internet Society has begun 
  101. working with international health and disaster relief agencies. 
  102.  
  103. This activity began as existing NGOs (Non-Governmental Organizations) of
  104. many kinds began to use the technology to improve the connectivity of
  105. very low budget operations around the world.  The Institute for Global
  106. Communications was created out of this need.  Activists in many diverse 
  107. organizations with international missions - from the UNDP to the U.S. NSF 
  108. to France's Orstom organization - then began to fund Internet connectivity 
  109. and information infrastructure initiatives as express objectives; bypassing 
  110. the tired and trite activities of the more traditional organizations that 
  111. produced more paper than infrastructure.
  112.  
  113. The process unleashed considerable technical and operational creativity
  114. to match prevailing local conditions.  The networks had to be cheap,
  115. easily maintained, robust, and often optimized around enormously 
  116. expensive and poorly performing public telecom capabilities.  Far flung
  117. networks based on Unix UUCP or on DOS PCs like FidoNet were born and given
  118. gateways to the Internet.  As the expertise grew and scarce funds were
  119. marshaled, circuits were shared, and full Internet connectivity was obtained.
  120.  
  121. Governments around the world are now focusing on their national or
  122. regional information infrastructures, and turning the swords of the Cold
  123. War into plowshares.  They are also facing many serious economic constraints.  
  124. The current efforts of the new Clinton-Gore Administration are particularly 
  125. notable examples.
  126.  
  127. In these efforts, the enormous value of a more formal Internet Peace Corps 
  128. initiative that would bring Internet connectivity and information resources
  129. to Third World locations is worth considering.  Even more than the original 
  130. Corps program, it leverages existing resources, people and technologies.
  131. It also captures the imagination and establishes a spirit of global change and 
  132. cooperation in ways never before possible.
  133.  
  134. ====================================================
  135. n-2-1.011.10
  136.  
  137. A Latin American and Caribbean Update
  138. by Daniel Pimienta*,
  139. <pimienta!daniel@redid.org.do>
  140.  
  141.  
  142. REGIONAL
  143.  
  144. The process of regional integration has been slowly progressing in the
  145. last year; much faster improvements have been made in terms of
  146. sub-regions.  If the very uneven level of institutionalization of the
  147. various national initiatives, and the weaknesses in the coordination
  148. between the different actors of the scientific information circuits
  149. (producers, consumers, carriers) makes the path long and difficult
  150. toward a real regional network integration, the level of mutual
  151. knowledge and cooperation between the people involved in networking
  152. made a spectacular jump in 1992.
  153.  
  154. The Second Regional Networking Meeting was held last November 1992 in
  155. Guadalajara (Mexico).  It was characterized by an almost exhaustive
  156. representation of national network initiatives and a more reduced
  157. international presence (OAS, UNDP, NSF, and SELA as observers), as
  158. compared to the first meeting in Rio de Janeiro.  The agreed final
  159. text shows a lot of progress toward the regional perspective, and
  160. definition of the key strategical objectives for the region.  The next
  161. meeting, scheduled to be held in Venezuela, in October 1993, should
  162. show the maturation of sub-regional and regional efforts.
  163.  
  164. The Latin American Networking School of Merida (Venezuela) confirmed
  165. the promises demonstrated during the previous Rio de Janeiro Workshop.
  166. The regional ability to provide a comprehensive and high quality
  167. technical training program has been proven.  One possible area
  168. of improvement could be in completing the curriculum with an
  169. introductory perspective which could sensitize the future network
  170. specialists on users, services and the social impact of networks.
  171.  
  172. The REDALC regional project feasibility study (EEC funding, Union
  173. Latina, Unesco and Acal partners) was completed by September 1992.
  174. Follow-on actions are being designed and will be soon negotiated with
  175. regional counterparts.  The REDALC team is also putting together, in
  176. collaboration with various partners, a plan for the creation of the
  177. Haitian network before the end of 1993.
  178.  
  179. NATIONAL
  180.  
  181. Practically the only country left out of reach from the Internet is
  182. Haiti.  The countries with older experience are starting to get
  183. organized for network applications, while the younger ones are trying
  184. to consolidate their user bases.
  185.  
  186. The Peruvian net continues to demonstrate its model value in bringing
  187. the focus toward user support and services, and leading regional
  188. actions.  In March 1993, the Networking School will offer regional
  189. services in Lima.  The event celebrates the first birthday of the
  190. Peruvian network and is organized together with various sub-regional or
  191. national activities.
  192.  
  193. Two important improvements in terms of international connectivity have
  194. been made in Costa Rica and Ecuador, where direct Internet connections
  195. have been set-up.  Both use 64kbps point to point satellite (PAS-1)
  196. connections to the Sprint PanamSat teleport in Homestead, FL and
  197. optical fiber from Sprint to NSF, Washington DC.  Both are offered to
  198. be shared by the different national initiatives, respectively by
  199. Universidad de Costa Rica and Banco del Pacifico (in the last case, it
  200. is a subset of a business bandwidth).
  201.  
  202. Venezuela is keeping a high user growth rate, and improving its
  203. network architecture with multi protocol support.
  204.  
  205. The Cuba network (CENIAI) growth in users and services remains
  206. impressive: more than 2000 users are now connected.  CENIAI has
  207. interesting assets to show in the upcoming INET93: the synergistic
  208. relation between telecom authorities and research networks, the
  209. special quality of user support, and the focus in applications.  The
  210. Internet Society has to work to make possible the representation of
  211. CENIAI in San Francisco.
  212.  
  213.  
  214. * Redalc Projects Manager
  215.  
  216. ================================================
  217. n-2-1-011.25
  218. Description of the Research Network Initiative in Costa Rica
  219. by Guy F. de Teramond*
  220. <gdeter@inforisc.cr>
  221.  
  222.  
  223. Two years after establishing the first Bitnet node in the Central
  224. American region, the University of Costa Rica interconnected last
  225. January 26, twelve nodes to the Internet.  Major activity at present
  226. is aimed at establishing CRNet, a digital high speed national internet
  227. backbone, linking major institutions in the country.  We provide a
  228. description of the research networking activities in Costa Rica,
  229. initiated three years ago.  Completion of this program will enable the
  230. regional scientific community to access remote advanced computing and
  231. information systems, as well as offering information on important
  232. regional aspects such as biodiversity and tropical medicine.
  233.  
  234. I. Establishment of a Bitnet Node in Costa Rica
  235.  
  236. A Bitnet node is operational at the University of Costa Rica (UCR)
  237. Centro de Informatica.  The node was connected on November 8th, 1990.
  238. A plan for the installation of a Bitnet node at UCR and the electronic
  239. connection of Central American Scientists was originally presented as
  240. a formal project to the Space Conference of the Americas in March 1990
  241. (1).
  242.  
  243. With the installation of a 3708 protocol converter and a PBX at ICE
  244. (Instituto Costarricense de Electricidad), and a second 3708 protocol
  245. converter at one of the RACSA (Radiografica Costarricense S.A) X.25
  246. nodes, the system has convenient access from any PC, through the
  247. normal telephone lines, or through a data transmission line from a
  248. RACSA node, in the country or in the Central American region.  The node
  249. at the University of Costa Rica is connected to the node FAUVAX at
  250. Florida Atlantic University (FAU) with a dedicated 19.2 Kbps digital
  251. link of the satellite PAS-1 from Panamsat.  The receiving station of
  252. PAS-1 is located at Homestead, Florida.
  253.  
  254. The number of registered users of the Bitnet node (UCRVM2) at the
  255. University of Costa Rica has been growing steadily since November
  256. 1990, when the node was interconnected.  There is at present some 1500
  257. users, most of them faculty, and students from the University of Costa
  258. Rica.  Some 400 users are outside host members from some 30
  259. institutions and specific research projects.  A Bitnet NJE (Network
  260. Job Entry) link has been established with Panama over a 9.6 anological
  261. link.  The new node UTPVM1 is operational since October 1992.
  262.  
  263. There also exists a UNDP funded project at the Fundacion Nahual -
  264. Proyecto Huracan - which gives useful electronic mail services within
  265. Central America, also using RACSA X.25 packet switching network, with
  266. a dialup connection of the main node Huracan with a UUCP gateway in
  267. the US.
  268.  
  269. II. Interconnection to the Internet
  270.  
  271. The IBM Corporation has given the network project at the University of
  272. Costa Rica a grant which includes a RISC 6000/530 multiprotocol machine,
  273. that is interconnected to the 4381 computers at UCR.  The RISC serves
  274. as hardware platform for the root name server (top domain level of the
  275. Costa Rican Internet).
  276.  
  277. Bitnet traffic will be combined with native IP traffic by
  278. encapsulating Bitnet RSCS packets into IP datagrams using the VMNET
  279. transport software developed at Princeton University in the 4381 VM
  280. machine, locally migrating to BITNET II.  A 64 Kbps satellite link has
  281. been established to carry the IP traffic to the US.  On March 1, the
  282. 19.2 NJE Bitnet link to FAUVAX will be disconnected permanently.
  283.  
  284. The UCR has already interconnected a dozen nodes to the Internet.
  285. Other nodes at various faculties and laboratories will be soon
  286. interconnected as a router- based fiber local backbone will span
  287. across the university campus.  The Instituto Tecnologico de Cartago has
  288. recently acquired 12 high performance DEC STATION 5000 establishing
  289. also a local internet.
  290.  
  291. III. Establishment of a National TCP/IP Backbone
  292.  
  293. In parallel with the Interconnection with the US Internet, the
  294. National Research Network of Costa Rica (CRNet) has been established.
  295. This pioneer project, sponsored by the Ministry of Science and
  296. Technology, for the establishment of an internet backbone within Costa
  297. Rica is based on a proposal to the Agency for International Development
  298. (2).
  299.  
  300. CRNet is a digital network that will provide high speed local
  301. interconnectivity between scientists at universities, research
  302. laboratories, industries with a technological component and other
  303. national institutions.  CRNet also provides high level
  304. interconnectivity with the US Internet using RACSA and Panamsat
  305. teleport facilities located respectively in San Jose and Homestead
  306. (Florida), and a 64 Kbps digital link from the satellite PAS-1.  The
  307. circuit includes a fiber link from Sprint corporation between
  308. Homestead and the NSFNet gateway in Washington D.C. sponsored by the
  309. National Science Foundation (NSF).
  310.  
  311. The backbone will initially interconnect the University of Costa Rica
  312. (UCR), the Instituto Tecnologico de Costa Rica (ITCR), the Centro
  313. Agronomico Tropical de Investigacion y Ensenanza (CATIE), the Omar
  314. Dengo Foundation (FOD), the Escuela Agronomica Regional del Tropico
  315. Humedo (EARTH), the Universidad Estatal a Distancia (UNED), the
  316. Sistema Nacional de Informacion Cientifica y Tecnologica (SINICIT),
  317. The Universidad Nacional (UNA), the Instituto Nacional de
  318. Biodiversidad (INBIO), the Instituto Centroamericano de Administracion
  319. de Empresas (INCAE), the Fundacion NAHUAL (Proyecto Huracan), the
  320. Earth Council, and the Instituto Interamericano de Ciencias Agricolas
  321. (IICA).
  322.  
  323. The Instituto Costarricense de Electricidad (ICE) has recently
  324. installed 140 Mbps optical links between major cities in Costa Rica.  A
  325. 2 Mbps (multiplexed out of ICE 140 Mbps intra city links) is
  326. administered by Radiografica Costarricense S.A.  This is referred as
  327. the RACSALINK NETWORK, the logical circuit and physical link for the
  328. TCP/IP Internet Costa Rican Backbone.  The 2 Mbps RACSA links (speed
  329. E1) are multiplexed in 30 56/64 Kbps channels.  Central RACSALINK
  330. network nodes are located at ICE/RACSA facilities at San Jose, San
  331. Pedro, Cartago, Alajuela, Heredia, and Limon.
  332.  
  333. RACSALINK Network is a distributed architecture state of the art
  334. multi-trunk multi-node fiber optics network.  The system is based on
  335. CODEX 6281 network processors, located at central ICE/RACSA nodes.
  336.  
  337. At the network level, CRNet backbone is based on high performance
  338. CISCO routers (AGS/4 and MGS/4) located at RACSA/ICE nodes to route IP
  339. traffic and to serve as Point-of-Presence (POP) to interconnect
  340. individual institutions.  A project sponsored by the Organization of
  341. American States (OAS) will permit the interconnection of the
  342. Universidad Nacional de Ingenieria in Nicaragua to the CRNet Internet
  343. gateway.  It is expected that this connection will be the starting
  344. point of a Central American internet backbone.  Initially, IP traffic
  345. to Central America will be carried over 9.6 analogical links.
  346.  
  347. IV. Conclusions
  348.  
  349. An important networking activity prompted by the recent
  350. interconnection to major worldwide research networks has taken place
  351. in the country.  This activity is now centered in the establishment of
  352. local internet nodes interconnected by a local TCP/IP fiber backbone.
  353.  
  354. Without access to the world scientific potential, scientists in the
  355. country will remain isolated, frustrated and unproductive.  This
  356. project represents an opportunity to learn and implement scientific
  357. communication tools as well as giving a major impact to the whole
  358. education system and country economy.
  359.  
  360. Acknowledgements
  361.  
  362. Funding for the interconnection of Costa Rica to major research
  363. networks comes from a BID-CONICIT grant, the University of Costa Rica,
  364. the IBM Corporation, the Agency for International Development (AID),
  365. and the Organization of American States (OAS).  In addition to the
  366. decisive support from the University of Costa Rica in personnel,
  367. equipment and financial resources, important support has been received
  368. form the Ministry of Science and Technology, the University of
  369. Wisconsin-Madison, the National Science Foundation (NSF), Racsa,
  370. Sprint, Panamsat and cisco Corporation.  Additional support has been
  371. received from NASA Goddard Space Flight Center and Florida State
  372. University.
  373.  
  374. References
  375.  
  376. (1) M. Cerdas, G.F. de Teramond and C. Gutierrez, An International
  377.     Electronic Connection for Central American Scientists, Presented
  378.     at the Space Conference of the Americas, San Jose, March 12-16,
  379.     1990.  Conference Proceedings, Vol. 2 p. 680 (San Jose, 1991).
  380.  
  381. (2) G.F. de Teramond, C. Gutierrez, E. Mata, R. Oreamuno, L. H.
  382.     Landweber, R.D. Bremel, Establishment of an Internet Backbone
  383.     Within Costa Rica, Proposal to the Agency for International
  384.     Development, San Jose, 1991.
  385.  
  386. *Director, R&D Unit in Information Technologies and Networks,
  387. Universidad de Costa Rica, San Jose, Costa Rica
  388.  
  389. ================================================
  390. n-2-1-012.05
  391.                      
  392. Ebone provides Megabit IP backbone
  393.  
  394. At the Ebone consortium meeting on February 3rd in Luxembourg, the
  395. partners finalized the budget, decided on an upgrade of the backbone,
  396. set up the organization to operate Ebone in 1993, and confirmed
  397. Ebone's long term strategy.
  398.  
  399. 21 partners have confirmed their commitment to the budget which covers
  400. a backbone connecting six backbone sites, nine additional access lines
  401. and three links to the US.  Ebone is thus used directly for their
  402. international IP traffic by partners in virtually all Western European
  403. countries and indirectly by several other countries linked to the
  404. Ebone partners.  In addition, Ebone will be used for pilot CLNS
  405. traffic.
  406.  
  407. At the meeting, a plan to upgrade part of the backbone was decided.
  408. This means 1.5 Mbps from Stockholm to Washington and to Amsterdam, 1.5
  409. Mbps from Amsterdam to Geneva, 1 Mbps from Geneva to the US and 2 Mbps
  410. from Geneva to Paris, and 1.5 Mbps from Paris to Washington.  The US
  411. links are provided in cooperation with NSFnet and other US IP
  412. providers.  In addition, 256 kbps links from London to Paris and to
  413. Stockholm are being considered for upgrade and the inclusion of a
  414. London to Washington link is being investigated.  A new backbone site
  415. in Bonn has been decided and one in Vienna is being investigated.
  416. With this much needed upgrade Ebone can more confidently transport
  417. traffic from the rapidly growing number of IP hosts in the partners'
  418. networks.
  419.  
  420. Kees Neggers was re-elected as Ebone chairman and an executive
  421. committee consisting of Dennis Jennings, Phil Jones, Christian Michau,
  422. Dave Morton, Kees Neggers, Peter Rastl and Peter Villemoes was
  423. appointed. Funded staff which will assist the executive committee and
  424. operate the network includes Frode Greisen as (part time) general
  425. manager, Bernhard Stockman as (part time) chairman of the Ebone action
  426. team which is planning Ebone development, and Peter Lothberg as Ebone
  427. operations center manager assisted by full time staff at KTH in
  428. Stockholm and part time staff at each of the six Ebone backbone sites.
  429. RARE is providing the secretariat support for the consortium.
  430.  
  431. The meeting also confirmed Ebone's long term strategy to concentrate
  432. in the future on providing a neutral interconnect for all networks,
  433. while it is assumed that provision of backbone services will be
  434. offered by one or more (competing) providers in the longer run.  Until
  435. such offers are forthcoming, Ebone will take care of its partners'
  436. needs in this area too.
  437.  
  438. ================================================
  439. n-2-1-012.07
  440.  
  441. EuropaNET
  442.  
  443. PTT Telecom & COSINE announce the launch of EuropaNET, a pan-European
  444. multi-protocol backbone data network service
  445.  
  446. The Eureka development project COSINE, funded by the countries of both
  447. the European Community and EFTA, has as its central objective the
  448. provision of a pan-European telecommunications infrastructure for
  449. academic, industrial and governmental researchers.
  450.  
  451. Following completion of a public invitation to tender by RARE (Reseaux
  452. Associes pour la Recherche Europeenne) on behalf of COSINE, a
  453. multi-million ECU contract has been awarded to PTT Telecom of the
  454. Netherlands to provide a backbone data network and associated services
  455. supporting a range of communications protocols currently used in the
  456. research community.  The three year contract includes performance and
  457. availability guarantees; these in themselves represent a major step
  458. forward in the procurement of international telecommunications
  459. services within Europe.
  460.  
  461. The network, to be known as EuropaNET, can be accessed directly at
  462. national points of presence within all the COSINE member countries and
  463. already currently offers a range of access speeds up to 2 Mbit/sec.
  464. Independent performance analysis which has just been completed
  465. indicates that the network can efficiently provide for transmission of
  466. both TCP/IP and X.25 packets, the standard communications protocols
  467. currently used in the European research community.  It is expected that
  468. all European national research networks will connect to EuropaNET,
  469. which will also have intercontinental connections to similar networks
  470. worldwide.  EuropaNET has replaced IXI, the backbone network which had
  471. provided X.25 services to the research community across Europe for the
  472. past two years.
  473.  
  474. Chairman of the COSINE Policy Group and Advisor to the Director of the
  475. Telematics Division of the European Commission's DG XIII, Horst Huenke
  476. said, "EuropaNET offers the European research community the
  477. opportunity to pool their resources into a single backbone network,
  478. thus obtaining significant economies of scale.  The multi-protocol
  479. capabilities of the network should render irrelevant the arguments
  480. about rival technologies which have tended to distract the European
  481. research community from making progress in this field."
  482.  
  483. In addition to the multi-protocol backbone service offering both X.25
  484. and TCP/IP interfaces, EuropaNET also provides the ability to
  485. interwork between different access protocols and a development path to
  486. a range of future interface standards.  It is based on an extensive
  487. investment by PTT Telecom in lines and infrastructure, with switching
  488. technology being provided by RC Electronics.
  489.  
  490. In order to encourage national research networks to take advantage of
  491. the high performance 2 Mbit/sec. access, the Commission of the
  492. European Community is making available enabling funding to assist
  493. networks with their subscriptions.  Two networks have already connected
  494. at this speed and a further four, including three interfacing via
  495. TCP/IP, are expected to connect at this speed in the next few months.
  496.  
  497. Access to EuropaNET is being extended to Eastern Europe by a separate
  498. contract between the European Commission and PTT Telecom as part of
  499. the Commission's support programme for Eastern Europe.  As a result,
  500. researchers in Poland, Hungary, the Czech and Slovak republics,
  501. Bulgaria and Romania will be able to communicate with researchers
  502. world-wide using EuropaNET.  It is expected that the Eastern European
  503. countries will be connected to EuropaNET during the course of this
  504. year.
  505.  
  506. Unisource Business Networks has taken over the operation of the
  507. network from PTT Telecom and will continue its management from their
  508. International Network Management Center in The Hague.  Unisource also
  509. sees it as a major asset and opportunity to position and use this
  510. network for other advanced European Network requirements and projects
  511. in other areas where the EC has a vested interest.  How and when the
  512. services will be integrated into the Unisource Business Networks
  513. service portfolio will be decided during this year.
  514.  
  515. ================================================
  516. n-2-1-012.42
  517.  
  518. Evolution of the GARR network
  519. by Stefano Trumpy*
  520. <TRUMPY@vm.cnuce.cnr.it>
  521.  
  522. GARR  is  the  acronym  for Harmonisation  Group  for Research  Networks
  523. created in 1988 operating  under  the Ministry of the University  and of
  524. Scientific and Technological Research (MURST) in Italy. GARR is also the
  525. name of the Italian Research Network which is currently conducted by the
  526. founder organisations:  three public  research nation-wide  Institutions
  527. i.e.  CNR  (National Council for Research),  ENEA  (National Council for
  528. Research on Nuclear  and Alternative Energies Sources),  INFN  (National
  529. High Energy Physics Institute) and by three consortia offering computing
  530. resources   to   Italian   universities,   i.e.   CINECA,   CILEA,   and
  531. Tecnopolis-CSATA.
  532.  
  533. The aim  of GARR is to establish and operate  a backbone interconnecting
  534. the  Italian  research   and   academic  networks  and  to   co-ordinate
  535. connections to international networks.
  536.  
  537. All computers on GARR  will  use  Internet-style domain  addresses.  The
  538. top-level domain is  .IT  (Italy) and the user Internet addresses are in
  539. the form user@domain.it.
  540.  
  541. GARR  will  continue  to  maintain  connections  to  the  major research
  542. networks,  including EASInet,  Internet,  BITNET/EARN,  EUnet,  Fidonet,
  543. HEPnet,  Europa  Net,  EBONE  and  other  networking  initiatives.   The
  544. participation  of Italy to  the COSINE project was  co-ordinated by GARR
  545. and  particular attention is  given to  the follow on activities of  the
  546. project i.e. the operational Unit and the Europa-net infrastructure.
  547.  
  548. The  backbone of  the network  provides four TDM  channels over  2  Mbps
  549. lines, carrying IP, DECnet, SNA and X.25 traffic.
  550.  
  551.  The backbone was initially built up by the original seven primary sites
  552. located  in  Milano  (CILEA),   Bologna  (CINECA  and  CNAF-INFN),  Pisa
  553. (CNUCE-CNR),  Roma  (ENEA and NIC- INFN) and Bari (CSATA).  Subsequently
  554. MURST funded a project to connect the over fifty universities in Italy ;
  555. the major ones to  be connected as extensions of the backbone  (2 Mbps),
  556. while the others to be attached  with 64kbps lines to the primary sites.
  557. Also GARR is adopting  a  new public  service providing bridging betweek
  558. ethernet LANs at 2Mbps (CLAN). The present configuration of the backbone
  559. is shown in the following picture.
  560.  
  561. The planned extension under grant of MURST is the following.
  562.  
  563. The GARR network  has been constituted  to serve primarily the following
  564. users of all institution reporting to MURST:
  565.  
  566. -Universities
  567. -Consortia offering computer services to universities (CILEA, CINECA, etc.)
  568. -Astronomic and Astrophysics Observatories e Vesuviani
  569. -National Research Council (CNR)
  570. -National High Energy Physics Institute (INFN)
  571. -Italian Space Agency (ASI) and
  572. -other  public  funded research  institutions  like  ENEA  (National
  573. Council for  Research on  Nuclear and Alternative Energies Sources)  and
  574. the Consortium Tecnopolis CSATA etc.
  575.  
  576. The  network  services  are also accessible by  research  departments of
  577. private initiatives which have  cooperations and  common  projects  with
  578. public funded research environment.
  579.  
  580. The utilisation of the network is  allowed  for the activities connected
  581. to  the development  of research  programs,  higher  education,  to  the
  582. diffusion of scientific information and to the support and management of
  583. the  research programs.  The  utilisation of  the  GARR  network is  not
  584. allowed for
  585. -       commercial activities;
  586. -       exchange of information not pertinent to the scientific research or
  587.  higher education;
  588. -not permitted access  to the  facilities connected to the network for a
  589.  usage  that provokes waste  of resources,  infringement to the privacy,
  590.  etc.
  591.  
  592. The GARR Network Information Service  (GARR-NIS) is located at CNUCE-CNR
  593. in  Pisa,  which currently provides it with all the necessary resources:
  594. hardware, software, financing, personnel, etc.
  595. The GARR-NIS is running the IT top-level domain name server and the c=IT
  596. X.500 DSA.
  597.  
  598. GARR NIS is the reference-point for various registration procedures (for
  599. organisations,  networks,  domains, persons, etc.) required to access to
  600. the GARR network and to international networks.  GARR NIS main functions
  601. are:
  602.  
  603. to  be the reference-point  for  various registration procedures  (for
  604.  organisations,  networks, domains, persons, etc.) required to access to
  605.  the GARR network and to international networks.
  606.  
  607. to define procedures and registration  templates,  taking into account
  608.  the  information   requested  by  other  European  and  American  NISes
  609.  (GSI-NIC,  NNSC,  RIPE-NCC,  EASI- NIS, etc.  ), in accordance with the
  610.  Guidelines established by GARR and collaborating with the international
  611.  networks managers.
  612.  
  613. to acquire network information and  to mantain databases and directory
  614.  services in order to make such information accessible via the network.
  615.  
  616. to  provide  the Internet DNS and X.500  DSA services  at the national
  617.  root  level,  and to coordinate their  distributed  management  at  the
  618.  national level.
  619.  
  620. to  publicise,   duplicate  or  improve  the  accessibility   (through
  621.  directory  and/or  information  discovery  systems)  to useful  network
  622.  information provided by other NISes or information-servers.
  623.  
  624. to carry out promotional activities spreading information on the  GARR
  625.  network and NIS:  periodic reports, announcements, news about workshops
  626.  and seminars, etc.
  627.  
  628. GARR-NIS  is  reachable  at  the  following  address:  via  Internet  at
  629. INFO@NIS.GARR.IT and via  X.400 at c=it;  admd=garr;  prmd=garr;  o=nis;
  630. s=info
  631.  
  632. [I am sending via fax to ISOC a copy including two pictures]
  633.  
  634. *CNUCE - ISTITUTO DEL CNR
  635. PISA
  636.  
  637. ================================================
  638. n-2-1-012.55
  639.  
  640. New Developments in Hungarnet
  641. by Istvan Tetenyi,
  642. <tetenyi@hugbox.sztaki.hu>
  643.  
  644.  
  645. E-mail in Hungary
  646.  
  647. The coverage with e-mail of Hungarian users has significantly improved
  648. in the last couple of months.  Today, e-mail is the most popular
  649. service which is provided for the R&D community.  Users are e-mail
  650. "aware" as the first nation wide service called ELLA was introduced as
  651. early as 1988.
  652.  
  653. This rapid growth was foreseen and therefore the technical committee of
  654. Information Infrastructure Programme devised a technical guideline in
  655. late 1991, on how to improve the service.
  656.  
  657. The dilemma between choosing only one mail protocol and the diversity
  658. of options was very serious.  Mail protocols like SMTP, BSMTP,
  659. Mail-11, UUCP and the home grown ELLA protocol were all in use.  The
  660. transport protocols were also very rich: X.25, TCP/IP, NJE, DECNET and
  661. matters like RFC 822 addressing had to be introduced.
  662.  
  663. The solution finally chosen was based on the brilliant package of M.
  664. Maddison, the MX mail exchanger for VMS.  It allowed to integrate
  665. fully the ELLA protocol with all the other mail systems.  One very
  666. significant feature was the full support of SMTP over X.25.  The MX
  667. package had all those features which provided a sound basis for growth
  668. without protocolar constrains.  System administrators found it easy to
  669. manage MX and sites with VMS generally opted for it and this will be the
  670. general solution for the coming years.
  671.  
  672. The HBONE project
  673.  
  674. The aim of this project is to establish a TCP/IP backbone for the
  675. Hungarian research and education community.  The primary role of HBONE
  676. is to provide a private data network for TCP/IP networking.
  677.  
  678. To interconnect the backbone routers initially, 64kbit/sec speed leased
  679. lines will be used.  The X.25 service of the PTT will also be used in
  680. some cases as primary and in general as backup solution.  It is
  681. expected that by mid 1993 a star shaped network with six leaves around
  682. Budapest could be finalised.
  683.  
  684. Router suppliers were asked for proposals in 1992, and not surprisingly,
  685. cisco was given the option to provide the first ten routers for the
  686. R&D community.
  687.  
  688. HBONE will be connected to the FDDI backbone of three university
  689. campuses in Budapest and also the FDDI ring in the largest county city,
  690. Debrecen.
  691.  
  692. International connectivity is provided by two 64 kbit/s leased links
  693. to EBONE via neighbouring Austria.  The European Multiprotocol
  694. Backbone (Europenet) provides another 64kbit/s X.25 link which will be
  695. used also for IP traffic.
  696.  
  697. The network management of the HBONE is undecided as yet.  Initially, a
  698. cooperative management was adopted until the number of routers are
  699. below a given limit.  Last year, a Charta of acceptable usage policy
  700. was developed and accepted by backbone managers and end users.
  701.  
  702. There are concerns about the available bandwidth.  The number of
  703. active users in university campuses has grown with the completion of
  704. LAN/MAN-s.  Sites with 1000 users are not rare anymore.  The bandwidth
  705. per capita (a quantitative measure similar to GNP per capita) is very
  706. low in Hungary, therefore the preparations for introducing higher
  707. speed on HBONE links have been started, on some of the national links
  708. 2Mbps and on international links 128 kbps will be introduced in the
  709. next year.
  710.  
  711. Great emphasis is on client/server type applications.  The usage of
  712. batch oriented services like NJE is preferred.  This is the reason why
  713. we are expecting the need for rapidly growing speeds.
  714.  
  715. Sites without real TCP/IP connectivity are also cared for.  Mail
  716. service, gopher searches, and News reading are publicly available for
  717. users with simple X.29 access.
  718.  
  719. ================================================
  720. n-2-1-012.56
  721.  
  722. Romania
  723. by Stephen Ruth*
  724. ruth@gmuvax.gmu.edu
  725.  
  726. In less than two months, six major nodes have begun BITNET/
  727. EARN transmissions.   The
  728. Institute for Atomic Physics in Bucharest (ROIFA), led by
  729. Dr. Ghorghi Pascovici, has already registered five hundred
  730. users, aiming for a thousand, and is in contact with
  731. countries all over the world, aided by a grant from the
  732. Mellon Foundation.  Currently they are the busiest node but
  733. the country's largest university, Politechnic Institute,
  734. (ROIPB) will soon be connecting several thousand users,
  735. according to Dr. Paul Christea and Dr. Nino Popovici, who
  736. are leading the effort there.  Part of a
  737. Mellon grant is funding a group of highly skilled graduate
  738. students at IPB who call themselves the BEST team.    They
  739. are doing some of the training and working with their
  740. professors to become skilled networkers.
  741.  
  742. Current nodes include:
  743.  
  744.   ROEARN, routing-only destination, in Bucharest has about
  745.    one hundred users;  Eugen Staicut : ESTAICUT@ROEARN, and
  746.    George Macri  : GMACRI@ROEARN.
  747.  
  748.   ROIFA  (Institute for Atomic Physics)  growing to over
  749.    one thousand users;  Serban Constantinescu SERBAN@ROIFA
  750.  
  751.   ROIPB (Politechnic Institute) up and running now at full
  752.    capacity due to the recent COCOM approval,  with a total
  753.    potential of thousands of users;
  754.  
  755.   ROBCU (Central Univ. Library) recently connected,
  756.    mainly a D.B. server, but with about a hundred users
  757.    already
  758.  
  759.   ROUTT (Technical University of Timisoara) with a large
  760.    potential but only a few terminals
  761.  
  762.   ROIMAR (Institute of Mathematics) with potential of
  763.    connecting the Romanian Academy of Science to a powerful
  764.    DEC-based system  George Gussi,director of IMAR
  765.    Gussi@ROEARN.BITNET or GUSSI%ROEARN@VM.UNIVIE.AC.AT
  766.    The Academy : ACADROM@ROEARN.BITNET
  767.  
  768.  
  769. A ring of FIDONET stations
  770. was established around Bucharest in November , enabling
  771. dozens of new nodes to be established in a matter of weeks.
  772. The FIDO stations, first in Romania, have complimented the
  773. more robust network connections. FidoMaven Bob Barad's
  774. outstanding skills in the setup made this a reality.
  775.  
  776. Romania is gradually building up its infrastructure in
  777. terms of people and equipment as part of a long term plan.
  778. Romanians are also connecting in record
  779. numbers to the Internet and EARN because they realize that
  780. every new user helps to develop a greater opportunity to
  781. spread the benefits of networking.  They are also
  782. investing in spreading network benefits, even
  783. barely realized ones, to Brazov, Iasi, Timosoara and other
  784. cities outside of Bucharest.   They are poised for major
  785. progress but will need a lot of energy and sharing of
  786. resources internally and more help from the private-sector,
  787. governments, technology associations and interested Internet Society
  788. members every step of the way.
  789.  
  790.       A test of the country's resolve will be the degree to
  791. which humanists, liberal arts specialties and other
  792. disciplines that are often the last to be allowed to use
  793. network services are empowered to participate.   Dr.  Mahi
  794. Dragonescu, the president of the Romanian Academy of
  795. Sciences recently said that the Romanian
  796. plan is to have at least one humanist connected to the
  797. network for each engineer.   If this trajectory is achieved
  798. Romania's explosive entry into networking will be sustained
  799. and the country will become a model for eastern Europe and
  800. beyond.
  801.  
  802. * Professor, George Mason University
  803.  
  804. ================================================
  805. n-2-1-012.70.3
  806. Russia (GlasNet)
  807.  by Anatoly Voronov
  808. <avoronov@glas.apc.org> 
  809.  
  810.  
  811. GlasNet, the Russian network for democratic communications, is about
  812. to reach the one thousand users threshold in a couple of months.
  813.  
  814. The Russian economic situation, with hyperinflation and lack of
  815. political stability, forces us to be extremely inventive and astute in
  816. order to make ends meet.  Yet, positive changes are taking place.
  817.  
  818. A new packet switching service, Infotel, has been settled in Moscow,
  819. offering enhanced facilities of access.  Actually, an intercity call
  820. is almost the only way of access GlasNet host from other cities.
  821. Starting April, it will be possible to access GlasNet by local PADs in
  822. Ekaterinburg, Novosibirsk, Rostov-on-Don.  A PAD in St. Petersburg is
  823. up and running.  The service is being planned to expand to Novgorod,
  824. Barnaul, Krasnoyarsk, Voronezh, Vladivostok.
  825.  
  826. GlasNet, with its reasonable rates and policy which encourages private
  827. persons to use telecommunications, attracts the interest of academic
  828. and research workers, offering them an opportunity of direct and
  829. independent connection with their colleagues in the USA and other
  830. Western countries.  GlasNet's heavy users are Protein Research
  831. Institute in Puschino (Moscow region), Lebedev Institute of Physics
  832. (Moscow), Vernadsky Institute of Geochemistry (Moscow).
  833.  
  834. The traditional bottleneck is the bandwidth to the West.  The dialup
  835. connection to the IGC (Institute for Global Communications) host in
  836. San Francisco, California, is growing more and more expensive.  In
  837. January, rates for international calls increased four times.
  838.  
  839. In this context, GlasNet is looking forward to get an access to a new
  840. 64 kbit/s channel granted by the Soros Foundation, to foster better
  841. information facilities for Russian academic workers.
  842.  
  843. The appeal for used modems and other hardware, placed in the previous
  844. ISOC News issue, has worked: David Lisbona sent us from Israel a modem
  845. and a laptop, to give them "second birth" in Russia.
  846.  
  847.  
  848. Note to Tony, Steve G. handed this "submission" to me at the 
  849. NORDUnet conference while we were in Helsinki.  He said he
  850. didn't know where you wanted to put this in the News, but trusts us to
  851. place it appropriately.
  852.  
  853. ================================================
  854. n-2-1-012.70.4
  855.  
  856. Soros Generosity Assists Russian Connectivity
  857. by Steve Goldstein
  858. <sgoldste@nsf.gov>
  859.  
  860.  
  861. In December 1992, George Soros, the Hungarian-born U.S. financier and
  862. philanthropist, announced the formation of the International Science
  863. Foundation (ISF) for the Former Soviet Union (FSU), and his intent to
  864. donate US $100 million over two years through the ISF to help
  865. stabilize the practice of science and relaxed scholarly activity in
  866. the countries which have emerged from the FSU.
  867.  
  868. In a series of meetings among advisors to the ISF, a strong consensus
  869. and clear message emerged: "Internet connectivity is vital to the
  870. well-being of scientists in the FSU".  Mr. Soros received the message
  871. favorably, and now telecommunications is an integral activity of the
  872. ISF program.
  873.  
  874. The National Science Foundation (NSF) assists the ISF by providing
  875. advice and access to selected NSF networking infrastructure support
  876. activities.  The immediate focus will be assisting ISF's work with the
  877. Russian science community to implement one or more 64kbps external
  878. (international) links.  Similar activities with other FSU countries is
  879. also being pursued.  The next steps will be to help with the
  880. improvement of in-country connectivity in the FSU countries.  Also,
  881. ISF will consider supporting activities to train service providers to
  882. provide assistance to end users and to help prospective end-users gain
  883. access and learn how to use the networks.  In all instances, ISF will
  884. seek cooperation with existing service providers and work with other
  885. international assistance activities (e.g., NORDUnet, German, and
  886. Polish initiatives).  Collectively, we look forward to reducing the
  887. isolation of our colleagues in the FSU through the facilities of the
  888. Internet.
  889.  
  890.  
  891.  
  892.  
  893. ================================================
  894. n-2-1-013.30
  895.  
  896. Israel
  897. by Hank Nussbacher
  898. <HANK@vm.biu.ac.il>
  899.  
  900. Israel has upgraded its internal ILAN backbone to 128kb/sec leased
  901. lines.  In addition, it has also upgraded its link to PSI in the USA
  902. to 128kb/sec (satellite connection), giving Israel a total of 192kb
  903. international capacity (the other 64kb is to Europe).
  904.  
  905. ================================================
  906. n-2-1-013.95
  907.  
  908. Iranian Mullahs on the Internet?
  909.  
  910. According to a recent press release from Iran's
  911. news agency, INRNA, three thousand Iranian mullahs have been
  912. trained to use computers for research in Islamic sciences.
  913. The director of a centre introducing computers to
  914. theological schools in Iran's main centre of Shi'ite moslem learning
  915. of Qom said it planned to link up with international
  916. computer-based information networks.
  917. The mainstream of Shi'ite moslem clergy has generally resisted
  918. technological innovations over centuries, but Iran's Islamic leaders
  919. say this should change.
  920.  
  921.  
  922. ================================================
  923. n-2-1-014.10.2
  924.  
  925. Some Thoughts on Computer Networking in sub-Saharan Africa
  926. by Paul Nash*
  927. <paul@frcs.Alt.ZA>
  928.  
  929.  
  930. Introduction
  931.  
  932. Africa might need peace and stability, but it also needs e-mail.
  933. While the telecommunications infrastructure is poor, there is an
  934. ever-growing need to communicate.  More and more non-government
  935. organisations (NGOs) are sending workers, often with existing computer
  936. skills, into the field to assist with health-care, developing
  937. infrastructures, etc.  These workers need to communicate with each
  938. other and with the various aid agencies funding them.
  939.  
  940. Telephone lines are often few and far between, and line quality
  941. shocking.  Fax transmissions seldom come through, and time-zone
  942. differences can make voice communication difficult.  However,
  943. electronic mail makes good use of limited bandwidth, and the various
  944. transfer protocols allow for error detection and/or correction and
  945. restarting transmission.  Store-and-forward facilities allow a number
  946. of shorter, more reliable local hops, leaving the intercontinental
  947. links to those with more reliable telecommunications.
  948.  
  949. Due to the poor quality of phone lines, only one brand of modem is of
  950. any use in most of this continent: the Telebit Trailblazer and
  951. derivatives.  While I hate to endorse any vendor's products, PEP beats
  952. the various CCITT modulation schemes hands down, providing up to
  953. 400cps over lines that will not support V.22bis.
  954.  
  955. UUCP/UUPC
  956.  
  957. The easiest way to transport Internet-format mail over erratic dial-up
  958. links is to use UUCP in its various flavours.  Among its advantages
  959. are its ubiquity, with versions available for most Unix platforms,
  960. MS-DOS, Apple Mac and many other platforms.  The protocol, however,
  961. shows its age.  Even with Telebit's UUCP spoofing, throughput is not
  962. as high as it could be, and failed transfers are not restartable.
  963.  
  964. Nonetheless, a simple laptop computer running MS-DOS can use a
  965. combination of Pegasus Mail and UUPC to provide a simple,
  966. cost-effective mail system.
  967.  
  968. Fidonet
  969.  
  970. Fidonet, the hobbyist network, uses an addressing scheme far removed
  971. from Internet standards.  However, it normally uses Z-modem as the
  972. transport, and so gains in throughput what it loses in
  973. interoperability.  For this reason, Fidonet technology networks have
  974. made great inroads into the African e-mail arena, and have become the
  975. de facto standard of most NGOs.
  976.  
  977. Gateways between Internet mail and Fidonet can be complex, especially
  978. when they are to be kept as transparent as possible.  I use RFMAIL
  979. under Unix to gate between the two networks, with a multiplicity of
  980. kluges to convert Fidonet addresses to Internet (and vice versa).  My
  981. personal opinion is that the gains at the transport layer are
  982. seriously outweighed by the incompatibilities at application level.
  983.  
  984. Current connections
  985.  
  986. There are an ever-growing number of links into Africa.  While I cannot
  987. describe all of them (and probably am not aware of half of them), I
  988. can provide an idea of the current status.
  989.  
  990. Probably the most heavily used is the Greennet/Worknet network, which
  991. starts with Greennet in the UK, and uses Fidonet protocols to reach
  992. down through Africa, ending at Worknet in South Africa.  From Worknet,
  993. traffic passes through the RFMAIL gateway to reach the South African
  994. universities' network (Uninet) and the rest of the world.
  995.  
  996. Uninet also has a Fidonet gateway, which provides connections to the
  997. University of Zambia, as well as dial-up UUCP links to the
  998. Universities of Mozambique (Maputo), Namibia and Zimbabwe.
  999.  
  1000. There are also UUCP dial-up links between my Unix machine and
  1001. Mozambique (Nampula), Zambia and Zimbabwe.  These use Distnet, a PC
  1002. package developed by SKAN Communications in Canada, and U-Access, a
  1003. Macintosh package.  There are further links on the cards to Angola
  1004. (once the peace dies down) and places further afield.
  1005.  
  1006. Experiences
  1007.  
  1008. The experience so far has been extremely heartening.  E-mail has
  1009. proved a great success, and the demand seems to be growing.  However,
  1010. the telephone lines prove a greater and greater problem.  Recently,
  1011. the Zimbabwean PTT changed its international telephone exchange, and
  1012. the University found that only two out of over two thousand attempted
  1013. calls to South Africa succeeded.
  1014.  
  1015. The link from northern Zambia to South Africa succeeds about one in
  1016. four, with throughputs of around 100 cps (from modems that should
  1017. provide 18000).  In addition, although South Africa has reasonably good
  1018. communications, the PTT here is opposed to "third-party" traffic, and
  1019. tries to prevent such cooperative ventures.
  1020.  
  1021. Although this may seem less than perfect, the current situation is a
  1022. great advance on anything that went before.  There is, however, room
  1023. for a vast number of improvements.
  1024.  
  1025. Future developments
  1026.  
  1027. The field is ripe for alternative transport mechanisms, which can
  1028. avoid the current shortage of telephone cables.  Two that spring to
  1029. mind are satellite and radio, and both should have a place in network
  1030. plans.
  1031.  
  1032. Satellite links can be most economically provided with
  1033. micro-satellites, which act as flying mailboxes, while whizzing by in
  1034. low orbit.  The earth-station requirements for these machines can be
  1035. met for as little as $5000.  Due to their design, mail must be sent on
  1036. a store-and-forward basis.
  1037.  
  1038. There is at least one geostationary satellite over Africa, with
  1039. bandwidth to spare.  One of the ex-USSR military satellites now has
  1040. bandwidth for sale, for those who can afford the $750000 C-band earth
  1041. station and space-segment costs.
  1042.  
  1043. Lastly, humble HF or VHF radios should not be ignored.  These are
  1044. cheap to provide, and while providing a comparatively low bandwidth,
  1045. can provide real-time delivery.
  1046.  
  1047. Conclusion
  1048.  
  1049. To be competitive, UUCP needs a more efficient transport mechanism,
  1050. such as Z-modem or Ian Lance Taylor's UUCP-i, to be used to deliver
  1051. e-mail to non-Unix computers, and close the gap with Fidonet
  1052. technology.  A simple user interface, such as Pegasus Mail, allows
  1053. neophyte users to operate a system with minimal training.  Finally,
  1054. consideration should be given to communications media that are not
  1055. dependent on copper wires, as these are in short supply.
  1056.  
  1057.  
  1058. *Communications Software Developer, Free Range Computer Systems
  1059.  
  1060. ================================================
  1061. n-2-1-015.28
  1062.  
  1063. 630 msec to McMurdo
  1064.  
  1065. February is an active time in Antarctica.  Lots of needed work is
  1066. done before the bad weather sets in.  Recently, an Internaut received
  1067. an e-mail message from a technician at the satellite tracking station in
  1068. McMurdo, Antarctica, who noted that they recently gained access to the
  1069. INTERNET.  Whereupon he proceeded to traceroute to mcmvax.mcmurdo.gov
  1070.  
  1071.  traceroute to mcmvax.mcmurdo.gov (157.132.103.50), 30 hops max, 40 byte packets
  1072.   1  dellrouter.dell.com (143.166.224.2)  30 ms  10 ms  10 ms
  1073.   2  UT6-S6.sesqui.net (128.241.4.161)  20 ms  10 ms  0 ms
  1074.   3  UT1-E2.sesqui.net (128.241.0.241)  20 ms  10 ms  20 ms
  1075.   4  RICE2-S5.sesqui.net (128.241.3.129)  50 ms  20 ms  20 ms
  1076.   5  ENSS.sesqui.net (128.241.0.94)  30 ms  20 ms  10 ms
  1077.   6  t3-1.Houston-cnss65.t3.ans.net (140.222.65.2)  20 ms  10 ms  20 ms
  1078.   7  t3-3.Houston-cnss64.t3.ans.net (140.222.64.4)  20 ms  20 ms  20 ms
  1079.   8  t3-2.Los-Angeles-cnss16.t3.ans.net (140.222.16.3)  40 ms  50 ms  50 ms
  1080.   9  t3-2.San-Francisco-cnss8.t3.ans.net (140.222.8.3)  50 ms  70 ms  60 ms
  1081.  10  t3-0.San-Francisco-cnss9.t3.ans.net (140.222.9.1)  70 ms  80 ms  70 ms
  1082.  11  t3-0.enss144.t3.ans.net (140.222.144.1)  130 ms  60 ms  100 ms
  1083.  12  ARC1.NSN.NASA.GOV (192.52.195.2)  80 ms  110 ms  140 ms
  1084.  13  * ARC5.NSN.NASA.GOV (192.100.12.5)  60 ms  70 ms
  1085.  14  128.161.115.2 (128.161.115.2)  660 ms  640 ms  620 ms
  1086.  15  157.132.100.15 (157.132.100.15)  640 ms  640 ms  630 ms
  1087.  16  mcmvax.mcmurdo.gov (157.132.103.50)  650 ms  630 ms  650 ms
  1088.  
  1089. Indeed McMurdo is connected!
  1090.  
  1091. [Please conserve their bandwidth and don't do this yourself.]
  1092.  
  1093. ================================================
  1094. n-2-1-020.17
  1095.  
  1096. Medical Informatics
  1097.  
  1098. The State University of Campinas, Campinas, SP, Brazil is noted for
  1099. Internet activism.  It hosts the worldwide biodiversity efforts.  It also hosts
  1100. a global initiative for medical informatics.  Dr. Renato M.E. Sabbatini operates
  1101. the Center for Biomedical Informatics from the University and publishes the
  1102. Electronic Newsletter on Medical Informatics
  1103.  
  1104. As part of the Center's activities, it maintains an on-line catalog of 
  1105. public-domain medical
  1106. software for IBM-PC compatibles.  It offers two kinds of software:
  1107.  
  1108.    Free-copy public-domain software, which was acquired from other
  1109.    sources. It can be download by anonymous FTP from the host
  1110.   <CCSUN.UNICAMP.BR> (143.106.1.5)
  1111.  
  1112.   Shareware medical software. This software is protected by copyright
  1113.    and thus has a small price tag attached to it. It was developed
  1114.    by the staff of the Center for Biomedical Informatics of the
  1115.    State University of Campinas. The only way to acquire it is
  1116.    by sending a check in US dollars of UNESCO coupons to the
  1117.    address below.  The diskettes are sent by airmail.
  1118.  
  1119.  
  1120. In addition to the software, medical personal around the world can subscribe
  1121. to Dr. Sabbatini's newsletter by sending a one-line message containing:
  1122.  
  1123. SUBSCRIBE NIBNEWS Your Name
  1124. to LISTSERV@CCSUN.UNICAMP.BR
  1125.  
  1126. The shareware includes advanced tools in multiple languages, including:
  1127.  
  1128. A shell program for generic building of rule-based
  1129. expert systems in Medicine.  The program is used in
  1130. Medical Informatics and Artificial Intelligence courses at under-
  1131. graduate and graduate levels in the institution.
  1132.  
  1133. An educational program for teaching medical
  1134. image processing techniques.
  1135.  
  1136. A powerful, but simple to use, bibliographical
  1137. reference manager. References are entered by means of a common word
  1138. processor, and fields are tagged as in MEDLARS.
  1139.  
  1140. A simple problem-oriented medical record package.
  1141.  
  1142. An educational program for teaching digital ECG processing techniques.
  1143.  
  1144. A neural network emulator for research and educational purposes.
  1145.  
  1146. An educational software package for Windows 3.1, developed using Visual BASIC
  1147. several common physiological simulations
  1148.  
  1149. Dr. Sabatini can be reached at: SABBATINI@CCVAX.UNICAMP.BR or SABBATINI@BRUC.BIT
  1150. NET
  1151.  
  1152.  
  1153. ================================================
  1154. n-2-1-020.20
  1155.  
  1156. Experimenting with Library of Congress Classification in GopherSpace
  1157. by Billy Barron*
  1158. <billy@sol.acs.unt.edu>
  1159.  
  1160. In my last column, I discussed the CICNet Electronic Journal Project.
  1161. Recently, we have been conducting an experiment into the use of
  1162. Library of Congress Classification for categorizing electronic
  1163. journals in our Gopher server.
  1164.  
  1165. Why Library of Congress Classification (LCC)?  We picked LCC because
  1166. the majority of the CIC libraries use it.  Over the past few months, I
  1167. have been involved in numerous discussions about the taxonomy of
  1168. subject-oriented Gophers.  The conclusion I have drawn is that there
  1169. are numerous ways to classify materials and all have their relative
  1170. merits.  With some people though, the choice seems to be a religious
  1171. issue.
  1172.  
  1173. One of the problems with LCC is that some related topics are widely
  1174. separated from each other.  This is natural in any classification
  1175. scheme that places an item in one place, which is necessary for
  1176. physical holdings.  To work around this problem, we have decided to
  1177. add Gopher links to tie together related topics.  For example, in LCC,
  1178. Computer Science is in QA75 and QA76 and Computer Networks are in
  1179. TK5105.5 to TK5105.9.  In the CICNet Gopher, I plan on putting an
  1180. entry under QA75-76 pointing at TK5105.5-9 to make finding the
  1181. information easier.
  1182.  
  1183. Another important aspect of this project is the building of a catalog
  1184. and a searchable index to all the journals.  I have yet to work on
  1185. this aspect of the project, but it should prove to be interesting.
  1186.  
  1187. I should stress that the use of LCC is just as a demonstration and
  1188. that I am not a cataloguer.  Therefore, I realize that some items are
  1189. classified incorrectly.  If you look through the collection
  1190. (gopher.cic.net) and can correctly recatalog some of the items, drop
  1191. me a note (billy@cic.net) and I will correct it.  Anyway, it should be
  1192. an interesting experiment.
  1193.  
  1194.  
  1195. *VAX/Unix Systems Manager, University of North Texas
  1196.  
  1197. ================================================
  1198. n-2-1-020.23
  1199.  
  1200. Network News from the American Mathematical Society--AMS
  1201. by William B. Woolf *
  1202.  <wbw@math.ams.org>
  1203. and David L. Rodgers**
  1204. <dlr@math.ams.org>
  1205.  
  1206. e-MATH--Services for Mathematicians
  1207.  
  1208. The American Mathematical Society (with funding from the National Science
  1209. Foundation--NSF) provides a number of services to the mathematical
  1210. community through its e-MATH.  Access is currently available to anyone
  1211. with VT100 terminal emulation on Internet, by typing "telnet
  1212. e-math.ams.org" or "telnet 130.44.1.100"; both the login name and the
  1213. password are currently "e-math" (lower case).  Among the services
  1214. provided are:
  1215.  
  1216.      o  the Combined Membership List of the American Mathematical
  1217.         Society, the Mathematical Association of America, and the Society
  1218.         for Industrial and Applied Mathematics;
  1219.  
  1220.      o  a library of public-domain software related to TeX, AMS-TeX, and
  1221.         AMS-Fonts;
  1222.  
  1223.      o  an employment information service, including all job listings
  1224.         which appear in the AMS publication "Employment Information in
  1225.         the Mathematical Sciences", plus the capability that job-hunters
  1226.         may post a brief curriculum vita which will be distributed to the
  1227.         employers with job listings;
  1228.  
  1229.      o  access via Gopher to a number of other services on the Internet,
  1230.         including preprint and directory services;
  1231.  
  1232.      o  listings of future AMS meetings;
  1233.  
  1234.      o  access to an author-lookup service based on the files of
  1235.         Mathematical Reviews;
  1236.  
  1237.      o  an electronic version of the Mathematics Classification Scheme;
  1238.  
  1239.      o  an electronic version of The Bulletin of the American
  1240.         Mathematical Society;
  1241.  
  1242.      o  a WAIS database containing items from the AMS Catalogue.
  1243.  
  1244. AMS developing e-journal platform
  1245.  
  1246. Work is under way at the AMS (with NSF support anticipated) on the
  1247. development of a software platform to support the creation and
  1248. distribution of electronic journals with advanced features including
  1249. support of cooperative authoring, utilizing version-control and
  1250. annotation capabilities.
  1251.  
  1252. SGML and Mathematics--A DTD for mathematics fragments
  1253.  
  1254. A subcommittee of the American Association of Publishers (AAP) convened
  1255. by W. B. Woolf (AMS) is at work on the development of a DTD (Document
  1256. Type Definition) for mathematics within SGML (Standard Generalized Markup
  1257. Language).  It is hoped to find a DTD which synthesizes the best features
  1258. of an existing draft standard from AAP and an existing International
  1259. Standards Organization standard (ISO 9573 TR 1988-1).  A series of
  1260. meetings including representatives of Euromath, Elsevier, ISO, CERN,
  1261. Springer-Verlag, AMS, etc., has culminated in the creation of a small
  1262. technical working committee which hopes to have a revised draft available
  1263. for broad distribution late this winter.  People interested in the
  1264. technical issues involved can subscribe to the discussion list SGML-MATH
  1265. by sending the message "subscribe sgml-math your_name" to
  1266. "listserv@e-math.ams.org".
  1267.  
  1268. *Associate Executive Director, AMS
  1269. **Manager, System Development, Mathematical Reviews 
  1270. ================================================
  1271. n-2-1-030.50.2
  1272.  
  1273. Gigabit Networks
  1274. by Craig Partridge,
  1275. <craig@aland.bbn.com>
  1276.  
  1277. This column is about the different types of media that we can use to
  1278. transmit data at gigabits per second.
  1279.  
  1280. The first type of media is optical fiber.  Briefly, an optical fiber
  1281. is a strand of glass about the size of a human hair.  The glass is
  1282. specially treated so that at certain frequencies of light, light
  1283. travels through the glass with very little loss.  As a result it is
  1284. possible (at least in theory) to send signals hundreds or even
  1285. thousands of kilometers through a single piece fiber.  (I should
  1286. quickly note that these wonderful properties are a characteristic of
  1287. single mode fiber.  There's another type of fiber, called multimode
  1288. fiber, which is easier to install and terminate, but has less good
  1289. propogation properties).
  1290.  
  1291. The bandwidth of a fiber is limited by the number of frequencies of
  1292. light that we can transmit through it.  Currently technology allows us
  1293. to send about 75 TeraHertz (THz) through a single fiber, and we can
  1294. signal between 1 and 1.4 bits per Hz, so a single fiber has a
  1295. theoretical bandwidth of over 100 terabits per second.
  1296.  
  1297. How are we going to actually send data at those bit rates?
  1298.  
  1299. One way is to try to make the fiber into a wire with a big bandwidth.
  1300. That's the approach used by Synchronous Optical Network (SONET), a
  1301. telephony protocol for signalling over fiber.  (SONET is part of a
  1302. larger suite of CCITT standards known as the Synchronous Digital
  1303. Hierarchy or SDH).  In brief, SONET is a scaleable protocol that sends
  1304. frames of data over the fiber.  A SONET frame is made up of a number
  1305. of repeated 90*9 chunks of bytes.  To scale SONET up to higher speeds,
  1306. one simply sends more chunks in each frame, while keeping the frame
  1307. rate constant.  At the lowest SONET speed of 51.8 Mb/s (called Optical
  1308. Carrier or OC-1), the SONET frame is one 90*9 chunk.  At OC-3 (155
  1309. Mb/s), the SONET frame is three 90*9 chunks; at OC-12 (622 Mb/s) the
  1310. frame is twelve chunks, and so on.
  1311.  
  1312. One problem with treating the fiber as a big wire is that developing
  1313. fiber optic components that can signal at very high data rates is
  1314. difficult to do.  Currently, it is not possible to find components
  1315. that signal at rates faster than OC-48 (2.4 Gb/s), which is a very
  1316. small use of a 100 terabit per second fiber (OC-2,000,000 anyone?).
  1317.  
  1318. One way to solve the challenge of combining slow optical components
  1319. and large fiber bandwidths is to divide up the fiber frequencies into
  1320. different channels, and have different components transmit at
  1321. different wavelengths.  This practice is known as Wave Division
  1322. Multiplexing, or WDM.  It is a sort of radio-in-fiber approach, where
  1323. if your host and my host wish to communicate, we have to tune our
  1324. hosts to the same channel.
  1325.  
  1326. The key challenges in WDM are first, trying to pack the frequencies as
  1327. close together as possible without having signals at one frequency
  1328. interfere with signals at another frequency (a practice known as dense
  1329. WDM), and second figuring out how to make sure that your host and my
  1330. host can correctly (and quickly) find the right channel to tune to.
  1331. IBM has demonstrated a WDM network called RAINBOW that supports
  1332. several 300 Mb/s channels, and its designers hope to expand the
  1333. RAINBOW design to support up to 1,000 channels, each capable of 1
  1334. gigabit per second.
  1335.  
  1336. But what if you don't have access to fiber between two points?  Can
  1337. you still get gigabit performance?  Indeed you can.
  1338.  
  1339. If there's line of sight between the two points, then you can use a
  1340. radio link.  The Luckynet testbed at AT&T Bell Labs has an
  1341. experimental 2.4 Gb/s (OC-48) radio link that covers a 23 mile
  1342. distance between two labs.
  1343.  
  1344. If you don't have line of sight, then perhaps satellites will come to
  1345. the rescue.  NASA is launching the Advanced Communications Technology
  1346. Satellite (ACTS) in June.  ACTS can connect multiple sites in the
  1347. continental US at 622 Mb/s (OC-12) rates.  Experiments with ACTS over
  1348. the next two years will test how to effectively use satellite
  1349. communications links at very high data rates.
  1350.  
  1351. To learn more about fiber optic networking, consult Paul Green's new
  1352. book, Fiber Optic Networks (Prentice Hall, ISBN 013-319492-2).
  1353. Biswanath Mukherjee wrote a wonderful two part survey on the design of
  1354. WDM networks in the May and July '92 issues of IEEE Network Magazine.
  1355. The Luckynet radio link is described in a paper at the 1991 Globecom
  1356. Conference.
  1357.  
  1358. ================================================
  1359. n-2-1-030.65
  1360.  
  1361. U.S. President Holds Town Meeting on the Internet
  1362.  
  1363. During a recent visit of
  1364. President Clinton and V.P. Gore at Silicon Graphics
  1365. the proceedings - incuding the President's announcement of his new
  1366. National Information Infrastructure initiative - were distributed live over
  1367. the MBone Internet as an audio-video multicast.
  1368. Clinton's speech was followed by a Presidential  "town meeting".
  1369.  
  1370.  
  1371. ================================================
  1372. n-2-1-030.66
  1373. Internet Talk Radio
  1374. by Carl Malamud
  1375. <info@radio.com>
  1376.  
  1377. On March 31, I'm launching a new service on the Internet called Internet
  1378. Talk Radio.  Internet Talk Radio is a "radio" metaphor: professionally
  1379. produced radio programs that show up on the net as audio files.  You
  1380. can multicast them, or you can simply FTP the files and play.  All I'm
  1381. doing is producing the information and you are free to distribute at
  1382. will using the protocol of your choice and to change the encoding format
  1383. of the data to suit your computing platform.
  1384.  
  1385. Distribution starts from UUNET and fans out to regional networks in an 
  1386. attempt to try and avoid excessive duplicate transfers.  If you're a local
  1387. net, you should contact your service provider.  If you're a service provider,
  1388. send mail to info@radio.com and I'll send you back instructions.  If you're
  1389. in Europe, mcsun at EUnet will be the initial spool point.  If you're in
  1390. Japan, WIDE and IIJ will do distribution.  If you're a Alternet customer,
  1391. you'll simply anonymous FTP from UUNET.  We are not using the MBONE, although
  1392. the networks that constitute the MBONE is certainly welcome to use that
  1393. distribution medium if they feel that it is appropriate.
  1394.  
  1395. The first show is "Geek of the Week" (;-), an interview show with members
  1396. of the community.  The program will be around a half-hour (e.g., 15 Mbytes
  1397. in standard PCM, 8000 sample, 8 bit, mu-law encoding).  The program is
  1398. sponsored by Sun Microsystems and O'Reilly & Associates.  Before the ugly
  1399. spectre of AUP violations flames up .... we use a National Public Radio-style
  1400. ack scheme consisting of just a couple of sentences.  Indications from at
  1401. least two of the large government networks are that we are compliant with
  1402. their Appropriate Use Policies.
  1403.  
  1404. --ed. A more lengthy description of Internet Talk Radio can be found in
  1405. the February issue of ConneXions magazine.
  1406.  
  1407. ================================================
  1408. n-2-1-030.80
  1409.  
  1410. International Character Sets in the Generic Network Services
  1411. by Borka Jerman-Blazic
  1412. <jerman-blazic@ijs.si>
  1413.  
  1414. The support of the International Character Sets in the forthcoming IT
  1415. systems used through the network services is probably one of the most
  1416. crucial requirements expressed by European users on many international
  1417. forums.  In that context, RARE decided to contribute to the area by
  1418. acting as a focus for user-requirements in the emerging Character Set
  1419. Technology and ensuring ways and methods these requirements to be met
  1420. in the relevant standard documents and IT applications.  The
  1421. activities are carried out within the RARE Working Group on Character
  1422. Sets Technology and the COSINE project.
  1423.  
  1424. The group produced several papers about the problems and issues
  1425. related to the use of International Character Sets in the network
  1426. services.
  1427.  
  1428. The group decided the problems of Character Sets should be worked out
  1429. within two working levels (i.e., definition of the Character Sets
  1430. Repertoires for RARE users and its application in the network
  1431. services).  Two services were identified as most important and
  1432. relevant to the problem of Character Sets issues: MHS/X.400 and
  1433. Directory/X.500.  A document/report was produced which offers solutions
  1434. to the use of International Character Sets in the Message Handling
  1435. Systems.  The document is in phase of being published as a RTR (RARE
  1436. Technical Report) and is referenced in many international events in
  1437. the field as an IETF Internet-Draft.  Another document was also
  1438. produced which defines the mapping between the Multipurpose Internet
  1439. Mail Exchange protocol to MHS/X.400 providing solutions for gatewaying
  1440. Internet mail containing message bodies coded with International Coded
  1441. Character Sets standards to X.400 systems.
  1442.  
  1443. The problem of the Directory and the support of International
  1444. Character Sets is quite complex, and for that reason it was decided
  1445. within the group that this subject is to be addressed in several
  1446. steps.  The major identified items which are planned to be worked
  1447. on within the Task Force groups of the RARE Working Group on Character
  1448. Sets set up recently within the new RARE Technical Program are the
  1449. following:
  1450.  
  1451.         Definition of the Repertoire (mainly based on the CCITT T.61
  1452.         recommendation and subrepertoires of ISO 10 646 to be derived
  1453.         from ISO 646 in collaboration with CEN TC 304).
  1454.  
  1455.         Definition of transliteration and conversion rules/tools for
  1456.         the Character Set Code Tables used by the majority of users in
  1457.         RARE community (i.e., ISO 646 compatible, ISO 8859 family,
  1458.         8-bit EBCDIC family, 8-bit IBM PC code pages, 8-bit Macintosh,
  1459.         Hewlett-Packard ROMANS8, etc.).
  1460.  
  1461.         Promotion of DUAs and DSA of PARADISE, with the defined tables
  1462.         and developed conversion tools.
  1463.  
  1464. The group is planning in the future to work on the
  1465. Internationalization problems within networking by introducing pilots
  1466. or Task Forces for special issues, in particular the following items
  1467. are planned to be worked out:
  1468.  
  1469.         Character Set Technology, i.e., identification, coding methods,
  1470.         transformation/ conversion, correspondence between characters
  1471.         and glyphs, visual presentations at the device/user
  1472.         interfaces, and registrations via the Internet Assigned
  1473.         Numbers Authority (IANA).
  1474.  
  1475.         Promotion/piloting with the new Document Processing and
  1476.         Interchange Technology with support and use of different
  1477.         character sets repertoires and fonts, i.e., SGML, ODA, ODE,
  1478.         EDI/EDIFACT, and DSSSL.
  1479.  
  1480.         Evaluation of standards under development and providing input
  1481.         regarding user requirements.
  1482.  
  1483.  
  1484. ================================================
  1485. n-2-1-040.31.1
  1486.  
  1487. Resource Discovery and Privacy
  1488. by Mike Schwartz*
  1489. <schwartz@latour.cs.colorado.edu>
  1490.  
  1491. As resource discovery and information services proliferate on the
  1492. Internet, a number of privacy issues arise.  The most obvious examples
  1493. concern directories of people.  What rights should people have to
  1494. control what information about themselves is visible, who can access
  1495. this information, and how the information is updated?
  1496.  
  1497. Privacy problems arise in other types of directories as well.  For
  1498. example, from time to time users of the archie FTP directory service
  1499. discover information that was intended only
  1500. for limited distribution.  Typically, this happens when a user looking
  1501. for a particular program or document happens across other information
  1502. while browsing the FTP site where the needed information was located.
  1503. This happened, for example, with an early draft of a document being
  1504. created by a networking organization last year.
  1505.  
  1506. Another privacy problem arises in conjunction with the provision of
  1507. directory service: access logs (which are routinely collected by many
  1508. Internet services) can be used to determine peoples' interests,
  1509. relationships, and other sensitive information.  For example, logs of
  1510. an individual's use of archie or Gopher could indicate interests in
  1511. particular personal discussions.  While it has always been possible to
  1512. collect such information from older, non-directory oriented services
  1513. (such as USENET news servers), the current generation of directory
  1514. services can collect information about a much larger, more widely
  1515. distributed collection of network users.  It is typical for such
  1516. services to receive requests from thousands of users around the world
  1517. every day.
  1518.  
  1519. In some cases, an explicit directory is not even needed to violate
  1520. privacy.  For example, it is possible to determine shared interest
  1521. relationships between thousands of people by briefly monitoring and
  1522. analyzing electronic mail "To:/From:" logs from a handful of sites.
  1523. It is difficult to protect against this sort
  1524. of invasion, because the needed data are not easily masked.  Privacy
  1525. Enhanced Mail does not protect against this type of
  1526. analysis, because the actual content of mail messages (which is what
  1527. PEM protects) is not needed for the analysis.  Protecting against this
  1528. type of traffic analysis would require generating
  1529. spurious traffic, to hide patterns in the real traffic.  Doing so
  1530. could be costly.
  1531.  
  1532. In some cases, users become more concerned about privacy when
  1533. directory information becomes more widely or easily accessible.  This
  1534. is the case with Campus Wide Information Systems that get connected to
  1535. the Internet, allowing people all over the world to locate information
  1536. that previously was available only to people within a university.
  1537. These problems also underlie some tension that has surrounded the
  1538. Netfind user directory service.
  1539. Originally, "finger" information was accessible only
  1540. within local campus internets.  As campuses connect to the Internet,
  1541. this information becomes accessible to anyone with Internet access.
  1542. Netfind makes it easy to harness this widely distributed information,
  1543. and use it as a directory service.  Because of this, some people have
  1544. suggested that Netfind poses a privacy invasion, even though it
  1545. provides no information that was not already publically available.
  1546.  
  1547. What can be done about these privacy problems?  A common approach is
  1548. to enact security barriers, to protect sensitive information.  Such
  1549. barriers help, but often the goals of privacy and security are not
  1550. well matched.  The priority in most security systems is to protect a
  1551. site's computer systems.  Personal privacy is only protected to the
  1552. extent that it overlaps with this goal.  Yet, in most of the above
  1553. examples, privacy could be threatened without violating a security
  1554. perimeter.  Moreover, in some cases privacy and security are at odds
  1555. with one another.  Every system administrator can tell a story of a
  1556. time when, in an effort to track down a security problem, they faced a
  1557. decision about whether to look into a personal mailbox for clues.
  1558.  
  1559. Security mechanisms represent policies that have been formalized to
  1560. the point of explicit controls over what users can do.  Often, less
  1561. formalized policies exist, in the form of proclaimed constraints on
  1562. acceptable activities.  For example, a university computing support
  1563. group might have written policies describing the conditions under
  1564. which a system administrator is allowed to inspect a personal mailbox.
  1565.  
  1566. Still less formal policies exist concerning what type of behavior is
  1567. acceptable when accessing machines across the Internet.  For example,
  1568. it is considered acceptable to login and retrieve files from a known
  1569. remote anonymous FTP file system, but it is not considered acceptable
  1570. to try to discover anonymous FTP servers by systematically attempting
  1571. to login to a list of machines.  In this case, the policy is really no
  1572. more than conventional wisdom that has developed over years of
  1573. collective Internet usage experiences.  Sometimes this type of
  1574. information is written down, in the form of new user guides.  
  1575. Often, however, it exists simply as folklore.
  1576.  
  1577. A difficulty with defining privacy policies is that no governing body
  1578. has the authority to legislate and enforce global policies.  While a
  1579. number of groups have stepped forward to suggest policies, 
  1580. there are no global privacy standards.  Indeed, different
  1581. countries currently have very different privacy laws and mechanisms.  
  1582. Even within a country, one can see a range of
  1583. different directory privacy policy choices.  For example, in the
  1584. United States one extreme is occupied by mailing list brokers, which
  1585. compile lists of everyone they can locate (assisted by the U.S.  Post
  1586. Office), and offer no assured way for people to modify or restrict
  1587. access to the information listed about them.  Telephone companies have
  1588. a more moderate policy, listing everyone by default, but allowing
  1589. individuals to restrict the content or presence of their listings.
  1590. Still more moderate are the policies put forward by the North American
  1591. Directory Forum (NADF).  NADF advocates several principles, including
  1592. the right to be informed when a person's directory entry is created,
  1593. the right not to be listed, the right to correct inaccurate
  1594. information, and the right to remove specific information.
  1595.  
  1596. Notice that none of the above policies requires that users give prior
  1597. consent to be listed - which is often what people upset about privacy
  1598. intrusions really want.  Even the NADF policy allows users to enforce
  1599. their privacy preferences only after the information has been visible
  1600. for some initial period of time.  Given today's technology, even a
  1601. short period of time may be enough to spread private information to
  1602. many derived databases.
  1603.  
  1604. There are at least three reasons why privacy policies tend to be
  1605. weaker than individuals would like.  The first is ubiquity of
  1606. coverage.  A user directory is only valuable if it contains listings
  1607. for many people.  Requiring prior approval makes this goal nearly
  1608. unattainable.  The second problem is more vexing: invading privacy can
  1609. be very profitable (as in the case of direct mail marketing lists).
  1610. Third, governments often want to maintain more detailed information
  1611. about people than their citizens would like, in the name of national
  1612. security.
  1613.  
  1614. There are no easy solutions to privacy problems.  However, I have
  1615. three suggestions.  First, we need to educate users about the many
  1616. ways that networked information can invade their privacy.  In a sense,
  1617. networks represent an "electronic society", participation in which
  1618. brings with it some loss of privacy, just as being a member of any
  1619. society does.
  1620.  
  1621. Second, we need to increase the amount of research and development
  1622. oriented towards ensuring privacy.  Technical conferences on the
  1623. subject often focus almost entirely on system security, with few
  1624. papers about privacy.
  1625.  
  1626. Third, we need to form policies oriented towards current technology.
  1627. The world has changed substantially since the U.S.  Privacy Act of
  1628. 1974 was introduced, and that legislation does not effectively address
  1629. many of the privacy problems that face us today (nor is it effectively
  1630. enforced).  One possibility would be for the U.S.
  1631. National Research Council to commission a study parallel to last
  1632. year's security study, focused on
  1633. privacy problems raised by networked information.  Or perhaps the
  1634. Internet Society could commission such a study, being an international
  1635. organization.
  1636.  
  1637. There are many other privacy problems introduced by electronic data
  1638. processing, beyond issues raised by Internet directory and information
  1639. services.  The interested reader can contact one of the offices of the
  1640. Computer Professionals for Social Responsibility (the main office
  1641. being in Palo Alto, California), or proceedings of the recent
  1642. conferences on Computers, Freedom & Privacy.
  1643.  
  1644. (-ed. References and citations in this article are available upon request
  1645. from Prof. Schwartz.)
  1646.  
  1647. *Professor, Computer Science Department
  1648. University of Colorado.
  1649.  
  1650. ================================================
  1651. n-2-1-040.33.1
  1652.  
  1653. Towards an Internet Security Architecture: Part III
  1654. by Stephen Kent*
  1655. kent@bbn.com
  1656.  
  1657.  
  1658.         This is the third installment in a multi-part series
  1659. addressing architectural security issues in the Internet.  The columns
  1660. in this series explore various aspects of an Internet security
  1661. architecture as the community begins to explore these issues.  Some of
  1662. the material in this column reflects observations contained in the
  1663. chapter on Architectural Security in the "Internet System Handbook"
  1664. published by Addison Wesley in October 1992.  This installment
  1665. continues the exploration of security services, and security
  1666. mechanisms used to provide these services, using the terminology
  1667. introduced in ISO 7498-2, the OSI security architecture.
  1668.  
  1669.         As noted previously, security services are abstract
  1670. characterizations of security functionality, independent of the
  1671. underlying mechanisms used to implement the functionality.  Thus
  1672. security service definitions provide a helpful vocabulary for end
  1673. users, and network or application service providers, to express
  1674. security requirements.  These definitions also serve as a means for
  1675. protocol and application designers to express the security functions
  1676. provided by protocols and applications or required of an underlying
  1677. communication system.
  1678.  
  1679.         The second security service to be explored is that of
  1680. integrity.  Data afforded the integrity service is protected from
  1681. undetected, unauthorized modification.  ISO 7498-2 further
  1682. characterizes integrity as connection-oriented or connectionless,
  1683. depending on the communication protocol context for which the service
  1684. is provided.  The distinctions between these two forms of integrity
  1685. have real implications both in terms of the security features provided
  1686. to the client of the service and in terms of the mechanisms used to
  1687. implement the service.  In some ways the integrity security services
  1688. are analogous to the integrity services one expects of a reliable a
  1689. communication protocol.  However, a security-oriented integrity
  1690. service provides protection in the face of malicious attacks against
  1691. data whereas a reliability-oriented integrity service provides
  1692. protection against benign errors, accidents, acts of God, etc.
  1693.  
  1694.         Connectionless integrity is applied to individual packets or
  1695. messages.  This service strives to provide to the recipient of a
  1696. packet (message) with confidence that the received data has not been
  1697. modified enroute.  Note that a simple error detection code, e.g., a
  1698. CRC, is not, by itself, sufficient to afford this security service.
  1699. The reason is that a malicious attacker is presumed to be capable of
  1700. modifying a packet and computing a new CRC with a "correct" value.
  1701. This is an example of why the security mechanisms developed for benign
  1702. error situations are generally not sufficient to provide protection
  1703. against malicious attacks.
  1704.  
  1705.         Instead, integrity mechanisms for use in hostile environments
  1706. must be able to protect against attackers who are presumed to be
  1707. capable of performing any algorithmic transformation, e.g., checksum
  1708. calculation, that the sender or receiver can perform.  The only
  1709. "leverage" afforded the legitimate participants in a communication is
  1710. the knowledge of some secret quantities which may be shared between
  1711. the sender and receiver, or which may be linked to publically known
  1712. quantities (as in public-key cryptography).
  1713.  
  1714.         Numerous algorithms been developed for checking the integrity
  1715. of individual packets exchanged between a pair of communicating
  1716. parties, many of which are termed "manipulation detection codes."
  1717. Examples are codified in the ANSI X9.9 specification and the SNMP
  1718. security enhancements (e.g., RFC 1352).  For multi-cast environments,
  1719. more stringent techniques are required, to counter the possibility
  1720. that one of the legitimate recipient might attempt to modify a message
  1721. and pass it on to other recipients.  The Privacy Enhanced Mail (PEM)
  1722. specifications (RFCs 1421-24) describe a means of providing integrity
  1723. in such environments.
  1724.  
  1725.         Connection-oriented integrity extends the connectionless
  1726. integrity guarantee to include detection of "any modification,
  1727. insertion, deletion, or replay of any data within a [packet]
  1728. sequence," according to ISO-7498-2.  This defines a fairly strict
  1729. integrity service well suited to a range of applications, e.g.,
  1730. virtual terminal and file transfer.  Such applications require that
  1731. absolutely all packets be delivered in sequence and without error.
  1732. However, this service characterization does not represent the extreme
  1733. on a spectrum of services.
  1734.  
  1735.         Applications such as packet speech or packet video will
  1736. function acceptably well even if some packets never arrive, or are
  1737. damaged.  However, these applicatins are sensitive to variability in
  1738. delays.  Thus integrity can be viewed as a multi-dimensional security
  1739. service.  This motivates the more general concept of "stream
  1740. integrity," which attempts to encompass a wide range of integrity
  1741. services which may be appropriate for varying applications.  Stream
  1742. integrity also seems a preferable service description since not some
  1743. of the applications which require more than simple connectionless
  1744. integrity do not make use of connection-oriented protocols.
  1745.  
  1746.         Mechanisms for providing stream integrity are quite varied.
  1747. No single stream integrity mechanism is ideal, or even appropriate,
  1748. for all applications, because of different application integrity
  1749. requirements.  Stream integrity techniques usually include the
  1750. connectionless integrity techniques alluded to above, then add
  1751. features such as non-repeating sequence numbers, timestamps,
  1752. challenge-response exchanges, etc.
  1753.  
  1754.         Finally, in isolation, integrity is not a very valuable
  1755. security service.  When an individual packet or message or a stream
  1756. of data arrives, the recipient usually wants to know not only that the
  1757. data has not been modified in any way, but also who transmitted the
  1758. data.  This latter service is referred to as authenticity and is the
  1759. topic of the next column.
  1760.  
  1761. *Chief Scientist
  1762. BBN Communications
  1763.  
  1764.  
  1765. ================================================
  1766. n-2-1-040.33
  1767.  
  1768. Privacy and Security Research Group Workshop on Network
  1769. and Distributed System Security
  1770. by Jeffrey I. Schiller*,
  1771. <jis@mit.edu>
  1772.  
  1773.  
  1774. On February 11th and 12th, 1993 the Privacy and Security Research
  1775. Group held the first PSRG Workshop on Network and Distributed System
  1776. Security.  Co-sponsored by the Internet Society and the Lawrence
  1777. Livermore Laboratory, the workshop was held in San Diego, California
  1778. and attracted approximately 150 networking professionals from around
  1779. the globe.  The workshop was divided into two types of presentations,
  1780. paper sessions and panel sessions.  Papers ranging from policy making
  1781. to technical dissertation were presented.  Topic areas covered Privacy
  1782. for Large Networks, Electronic Documents, Privacy Enhanced Mail (PEM),
  1783. and Practical Distributed System Security.
  1784.  
  1785. The panel sessions were designed to present the attendees with an
  1786. opportunity to discuss timely and in some cases controversial security
  1787. topics.  Panels included the question of in which layer(s) of the OSI
  1788. reference model security should be implemented in.  Smart cards and
  1789. their applications were discussed in another panel.  One panel
  1790. discussed exportable encryption algorithms (and what their use
  1791. implied).  The closing panel asked the question: "Should security be
  1792. legislated?" (i.e., should workstations have required security
  1793. features in the same way that automobiles and airliners must meet
  1794. safety standards).  Although each panel had several presenters, group
  1795. participation of all workshop attendees resulted from the extended
  1796. question and answer periods.
  1797.  
  1798. The workshop Banquet featured Scott Charney, Chief Computer Crime
  1799. Bureau of the U.S. Justice Department, going over the challenges
  1800. facing law enforcement when it comes to apprehending and prosecuting
  1801. computer criminals.  Among the issues covered he included a discussion
  1802. of the motivation behind the CERT's (Computer Emergency Response Team)
  1803. recent advice to warn network users of keystroke monitoring, a topic
  1804. that has spawned significant debate within the network community.
  1805. Scott explained that quirks in U.S. law rather then a desire to "spy
  1806. on the community" is behind the advice.
  1807.  
  1808. The session on Electronic Documents had papers presented on secure
  1809. electronic meeting management and secure electronic document handling.
  1810. Both papers presented ways to use networking, and the Internet, to
  1811. handle business/administrative tasks in a secure fashion.
  1812.  
  1813. The PEM session speakers presented papers covering the security issues
  1814. of implementating PEM in a multi-user UNIX environment and VAX/VMS PEM
  1815. implementation and user experiences.  An implementation of a hardware
  1816. certificate signing unit was presented, as well as a paper outlining
  1817. some of the subtle security issues (and solutions) for implementing
  1818. PEM with symmetric key cryptography.
  1819.  
  1820. The session on distributed systems discussed practical applications of
  1821. security technology, to the problems of distributed systems and shared
  1822. file systems.
  1823.  
  1824. All in all, the workshop was well attended and extremely productive.
  1825. The papers were excellent and the panel discussions enlightening.
  1826. Current plans call for this workshop to become an annual Symposium.
  1827. It is a Symposium worth investigating.  Be on the lookout for the next
  1828. Call for Papers!
  1829.  
  1830.  
  1831. *MIT Network Manager, Massachusetts Institute of Technology
  1832.  
  1833. ================================================
  1834. n-2-1-040.35
  1835.  
  1836. How Reliable are PTT International Links?
  1837. by Hank Nussbacher
  1838. <HANK@taunivm.tau.ac.il>
  1839.  
  1840. Nowadays, countries order high speed data communications links for
  1841. hundreds of thousands of dollars.  For example, Israel spends $207,000
  1842. per year on a 128kb satellite line to the USA and another $140,000 per
  1843. year on a 64/kb fiber link to Europe.  But just how reliable are those
  1844. expensive circuits to abroad?
  1845.  
  1846. The CCITT (International Telegraph and Telephone Consultative
  1847. Committee) has stated that intercontinental circuits should not
  1848. experience more than 3 hours per month down time (99.6% up time) and
  1849. that continental links should not experience more than 1 hour down
  1850. time (99.9% up time).
  1851.  
  1852. Unfortunately, a recent INTUG (International Telecommunications User
  1853. Group) report that monitors various PTTs throughout the world, shows
  1854. that on average 64kb circuits are available only 99.03% (7 hours per
  1855. month downtime).
  1856.  
  1857. How has Bezek, the Israeli monopoly PTT, been doing compared to its
  1858. European cousins?  The table below uses two international circuits for
  1859. the basis of its analysis: a satellite 64kb (128kb as of 26 January
  1860. 1993) circuit from Weizmann Institute in Rehovot to New York City
  1861. (USA) and a second 64kb circuit that goes via the EMOS, a fiber optic
  1862. undersea link, from Tel Aviv University to Geneva.  This table shows
  1863. that Bezek is more or less on par with around 99.1% uptime for
  1864. international circuits, but which is clearly below the CCITT
  1865. recommendation of 99.6% uptime.  IDB, the USA carrier for the other
  1866. half of the USA-Israel circuit, states in their contract that
  1867. reliability will not be less than 99.5%.  Clearly, they do not reach
  1868. that objective.
  1869.  
  1870.  
  1871.        Israel-USA                 |       Israel-Europe
  1872.        (satellite)                | (EMOS - fiber optic cable)
  1873.                                   |
  1874.                                   |
  1875. Month   Downtime  # of      %     | Downtime  # of      %
  1876.         in min.   failures  avail | in min.   failures  avail
  1877. ------  --------  --------  ----- | --------  --------  -----
  1878. Jul 92   462       20       99.0  |  532       24       98.9
  1879. Aug 92   657       68       98.5  |  300       15       99.3
  1880. Sep 92   424       47       99.1  |  276       14       99.4
  1881. Oct 92   100       25       99.8  |  230       89       99.5
  1882. Nov 92   524       26       98.8  |  297       31       99.3
  1883. Dec 92    28       17       99.9  |  134       37       99.6
  1884. Jan 93   568       32       98.7  | 1114       88       97.5
  1885.  
  1886.  
  1887. What are the major causes of a digital telecommunications circuit to
  1888. go out of service?  Synchronization and multiplexing signals on high
  1889. bandwidth international links is more complicated than on slower speed
  1890. analog links.  Synchronizing at the international level is
  1891. particularly tricky because different carriers (PTTs) often use
  1892. different signalling schemes.  These synchronization problems usually
  1893. result in a link disruption of under 2 minutes, long enough to force
  1894. users off a remote application.
  1895.  
  1896. For example, over the period of October 3rd & 4th, the circuit from
  1897. Israel to Geneva had 64 line failures, each on average 18 seconds in
  1898. length.  Fortunately, we use equipment that requires only 10 seconds
  1899. to recover full user connectivity in the event of a line failure.  But
  1900. someone who would be using certain vendor equipment that would require
  1901. a reboot after every line failure, may experience 20-30 minute outages
  1902. for every 18 second line synchronization problem.
  1903.  
  1904. Due to the fact that different PTTs use different signalling
  1905. standards, it is close to impossible for PTTs to monitor digital
  1906. circuits and instead wait for customers to call them to report circuit
  1907. outages.  PTTs usually show higher availability statistics than
  1908. customers, since they only start their "down clock" when a customer
  1909. reports the problem, which is often 15-30 minutes after the line has
  1910. gone down.
  1911.  
  1912. Interestingly enough, the higher the data speed, the more reliable the
  1913. digital data circuit (from the INTUG report):
  1914.  
  1915.  
  1916.                 Speed        Uptime
  1917.                 ------       ------
  1918.                 768kb        99.99%
  1919.                 384kb        99.94
  1920.                 1544kb (T1)  99.94
  1921.                 1024kb       99.9
  1922.                 128kb        99.88
  1923.                 1984kb       99.88
  1924.                 512kb        99.87
  1925.                 2048kb (E1)  99.56
  1926.                 64kb         99.03
  1927.                 256kb        97
  1928.  
  1929. Looking at the above table, users would be recommended to stay away
  1930. from 256kb circuits and to upgrade as fast as possible from 64kb to
  1931. 128kb circuits.  Almost all higher speed lines (other than 64kb and
  1932. 256kb) meet the CCITT recommendations.
  1933.  
  1934. I would be interested in forming a group in the Internet to discuss
  1935. these matters and to exchange statistics, and I am prepared to
  1936. coordinate the matter as well as attempt to prepare coordinated
  1937. reports on link uptime and reliability of lines based on country.
  1938. Those interested in discussing this, should send me e-mail at the
  1939. address stated above and if we get enough of a turnout, we might be
  1940. able to improve the reliability of our leased lines.
  1941.  
  1942. ================================================
  1943. n-1-4-040.51
  1944. User Services
  1945. by Joyce K. Reynolds*
  1946.  <jkrey@isi.edu>
  1947.  
  1948. On 5 January 1993, the National Science Foundation's (NSF) Network
  1949. Information Services Awards were announced.  Enclosed is an
  1950. abbreviated announcement of this new and important award for the
  1951. Internet community.
  1952.  
  1953. In cooperation with the Internet community, the National Science
  1954. Foundation developed and released, in the spring of 1992, Project
  1955. Solicitation for one or more Network Information Services Managers to
  1956. provide and/or coordinate (i) Registration Services, (ii) Directory
  1957. and Database Services, and (iii) Information Services for the NSFNET.
  1958. As a result of this solicitation, three separate organizations were
  1959. competitively selected.  Together, these three awards constitute the
  1960. NIS Manager Project, named the INTERNIC.  Network Solutions will
  1961. provide registration services, AT&T will provide directory and
  1962. database services, and General Atomics will provide information
  1963. services.  The three awardees have developed a detailed concept and
  1964. plan to provide this seamless interface called the "INTERNIC" and have
  1965. agreed to the structuring of their three separate awards as one
  1966. collaborative project.
  1967.  
  1968. Network Solutions will provide registration services as the IP
  1969. registrar, issue IP numbers worldwide using delegated registries under
  1970. the guidance of the Internet Assigned Numbers Authority and also
  1971. register domain names, and track points of contact.  Applications for
  1972. assignment will be accepted via email or facsimile.  The information
  1973. from these assignments will be provided to the directory and database
  1974. services provider to be made available to the entire Internet
  1975. community.  As a part of the Domain registration efforts Network
  1976. Solutions will periodically release the top level zone files to be
  1977. used by all root Domain Name servers.
  1978.  
  1979. AT&T will develop and maintain a Directory of Directories, including
  1980. lists of FTP (File Transfer Protocol) sites, lists of various types of
  1981. servers available on the Internet, lists of white and yellow page
  1982. directories, library catalogs and data archives. AT&T will also
  1983. provide white and yellow pages type Directory Services. Access to
  1984. these services will initially be provided through several currently
  1985. popular in-use interface methods while migrating to the use of X.500
  1986. technology, the current standard specification for distributed
  1987. information storage and retrieval.  The database services which AT&T
  1988. will provide include the establishment of Database Services to extend
  1989. and supplement the resources of the NSFNET, such as extend and
  1990. supplement the resources of the NSFNET, such as databases of
  1991. contributed materials of common interest to the user community.  AT&T
  1992. will also offer database design, management, and maintenance to
  1993. institutions and groups for inclusion in the Internet.
  1994.  
  1995. General Atomics will provide Information Services acting as the NIC of
  1996. first and last resort and the NIC of NICs.  The INTERNIC information
  1997. services will include a full-service Reference Desk, a database of
  1998. comprehensive networking materials called the Info Source, training
  1999. classes and documentation, and coordination services among all
  2000. appropriate groups in the community.  In keeping with the innovative
  2001. spirit of the Internet, several new approaches to distributing
  2002. services will be implemented.  Among these innovations is NICLink, a
  2003. user-friendly hypermedia interface offering access to the Info Source
  2004. and all the information it contains.  NICLink will be distributed on
  2005. both standard computer diskettes and CD-ROM.  Another is the concept
  2006. of the Info Scout, an individual who will scout out new resources and
  2007. innovative uses of the network for inclusion in the Info Source.
  2008.  
  2009. National Science Foundation Contact     Network Solutions Contact
  2010. Don Mitchell                            Mary Bloch 
  2011. (202) 357-9717                          (703) 742-4740
  2012. dmitchel@nsf.gov                        maryb@netsol.com
  2013.  
  2014. AT&T Contact                            General Atomics Contact 
  2015. Shelly London                           Susan Calcari             
  2016. (908) 221-4355                          (619) 455-3900
  2017. london@attmail.com                      calcaris@cerf.net
  2018.  
  2019.  
  2020. *Member of the Technical Staff, Information Sciences Instititue,
  2021. University of Southern California
  2022.  
  2023. ================================================
  2024. n-2-1-040.68
  2025.  
  2026. All You Didn't Want to Know About BITNET and Were Afraid To Ask
  2027. by Eric Thomas
  2028. <ERIC@SEARN.SUNET.SE>
  2029.  
  2030. BITNET's store-and-forward technology may not deliver the best round
  2031. trip figures for electronic mail, but there is one area in which it
  2032. outperforms current Internet technology by a large factor: bulk mail
  2033. delivery.  This article will show that, contrary to popular belief,
  2034. this difference is not made irrelevant by upgrading your access line
  2035. to T1.
  2036.  
  2037. In a previous article ("What's the Response Time", by Frode Greisen
  2038. and Greg Lloyd), we saw that the average round-trip time for a typical
  2039. 50-lines mail message over the EARN backbone is on the order of
  2040. 300-400 seconds, or about 3 minutes for the one-way trip.  Even though
  2041. these figures include downtime and some of the countries on the EARN
  2042. backbone do not have satisfactory connectivity, this is still pretty
  2043. unimpressive.  Even between well-connected countries, the average
  2044. transmission time would be on the order of 30-90 seconds during peak
  2045. hours, assuming the lines are up.  Between the same machines, SMTP
  2046. delivers the same message in 5 seconds, maybe 10 if the machines are
  2047. loaded.
  2048.  
  2049. So why aren't the BITNET folks working on dismantling this outdated
  2050. technology and migrating everything to IP?  Well, we computer people
  2051. can compare figures and argue about the conditions of our benchmarks
  2052. to our heart's content, but the reality is that users don't care
  2053. whether a message is delivered in 5 seconds or 2 minutes.  It took them
  2054. 5 minutes to type it, usually with two fingers, and as long as it gets
  2055. there within some 10-15 minutes they will be satisfied.  That is,
  2056. genuine end-users aren't going to judge a technology solely on whether
  2057. it takes 5 seconds or 2 minutes to deliver a piece of mail; this will
  2058. be just a minor factor among many others in their overall evaluation
  2059. of the service.
  2060.  
  2061. Now, while Joe Bitnetter is willing to wait 10-15 minutes for his
  2062. message to be delivered, he of course expects the message to be
  2063. delivered within that 10-15 minutes period regardless of whether it
  2064. was sent to a single person or to a mailing list.  After all, the
  2065. network handles millions of messages a day, so a couple thousand
  2066. additional messages should make no difference.  And this is, indeed,
  2067. the way the post office works: a thousand letters mailed first class
  2068. take the same time to arrive as a single one.
  2069.  
  2070. And here it is where the Internet fails to deliver.  The round trip
  2071. time observed on the IETF list (from a T1-connected site) ranges from
  2072. 30 minutes to several hours.  The message gets to CNRI in less than
  2073. one minute, but takes about an hour to come back.
  2074.  
  2075. BITNET, on the other hand, uses a bulk delivery algorithm known as
  2076. "DISTRIBUTE", which uses knowledge of the topology to optimize the
  2077. distribution in a store-and-forward fashion.  There are about 150
  2078. DISTRIBUTE servers spanning 28 countries, and the distribution
  2079. algorithm ensures that a single copy of the message is sent over any
  2080. given "link" (originally these were actual, physical leased lines,
  2081. nowadays they are mostly virtual TCP circuits between designated
  2082. machines).  For instance, a LISTSERV somewhere in California could
  2083. forward a copy of the message to a server on the East Coast, which
  2084. would fan it out to a number of other East Coast servers and send a
  2085. copy to Stockholm, where the message would be delivered to recipients
  2086. in Sweden and then passed on to Poland and Finland - and so on.  A
  2087. study has shown that, on the average, this reduces the load by a
  2088. factor of 5 to 25, depending on the topology and usage patterns.  Note
  2089. that 35-40% of BITNET mailing lists are highly-specialized interest
  2090. groups with around 100 recipients or less: the savings are of course
  2091. higher with larger lists.
  2092.  
  2093. The bandwidth saved through this algorithm is clearly a gold mine to
  2094. countries with a weak economy, such as eastern countries, which simply
  2095. haven't got the money to purchase fast lines (leased lines usually
  2096. have to be paid for in hard currency).  With two 64k connections,
  2097. Poland is by far the best connected eastern country, and that was
  2098. accomplished (partly) through subsidies.  If a particular software
  2099. technology can reduce the bandwidth used up by e-mail by a factor of
  2100. 10, you will have a hard time convincing countries connected at 9.6k
  2101. or even 64k that this is a minor side-effect of an obsolete technology
  2102. they should strive to migrate away from.  Unless, of course, you get
  2103. them a free ride on a T1 in exchange.
  2104.  
  2105. In addition to this purely financial benefit, we come to another
  2106. significant aspect of this distribution mechanism: it evens out the
  2107. cost of delivering messages to mailing lists of more than a couple
  2108. hundred subscribers.   It doesn't make much of a difference for the
  2109. network backbone whether there are 500 or 10,000 recipients, because
  2110. the message will have to be delivered to (almost) all the
  2111. participating DISTRIBUTE servers in both cases.  The difference is that
  2112. there will be a lot more deliveries on local area networks and
  2113. faster/cheaper regional lines, which usually aren't backlogged.  This
  2114. is why BITNET passes the "post office" test in regions without chronic
  2115. bandwidth problems (and considerably eases the load on regions which
  2116. do have continuous backlogs).
  2117.  
  2118. To quantify that point, we conducted an experiment with a moderately
  2119. large but pretty active list (about 1,200 recipients and over 100
  2120. daily postings), hosted in the US.  We selected two "guinea pig"
  2121. accounts, one in the US (but in a different State) and one in Poland.
  2122. Both accounts were subscribed three times to the mailing list, under
  2123. different incarnations: once with the machine's BITNET address, once
  2124. with an Internet address for which a "site gateway" had been
  2125. registered in the BITNET gateways database, and once with an Internet
  2126. address for which no particular gateway was defined (in fact we used
  2127. source-routing in the second case to simulate the behaviour we wanted,
  2128. since the sites in question had chosen not to register any "site
  2129. gateway").  We were careful to add the addresses in the middle of the
  2130. list file, so that they wouldn't get unfair (or "too fair") treatment.
  2131. We then recorded the arrival time of the various "triplets" on a 24
  2132. hour cycle, to compare the relative efficiency of the 3 delivery
  2133. methods:
  2134.  
  2135.         1. BITNET/NJE all the way.
  2136.  
  2137.         2. BITNET/NJE to the "site gateway", then SMTP to the final
  2138.            mailbox.
  2139.  
  2140.         3. SMTP all the way.
  2141.  
  2142. In all but one case, the first method was the fastest.  The round trip
  2143. time (between 'Date:' time stamp and last 'Received:' field) was on
  2144. the order of 10 minutes for the US recipient and 15 for the Polish
  2145. one, give or take a couple minutes (the clocks of the various machines
  2146. were not synchronized and we had no time to check the offset of the
  2147. individual clocks of each and every poster on that day).  On the
  2148. average, the copy sent to the "type 2" address arrived 1 minute 30
  2149. seconds later for the US recipient and 4 minutes 40 seconds later for
  2150. the Polish recipient.
  2151.  
  2152. However, the copy with the plain "type 3" Internet address (SMTP all
  2153. the way) arrived more than an hour after the other two, for both
  2154. addressees.  Now, this might be excusable for the Polish address,
  2155. since the IP route to this host is usually saturated, but what about
  2156. the T1-connected US university?  What would they tell Joe
  2157. (ex-)Bitnetter if they were to leave BITNET and he suddenly had to
  2158. wait an extra hour for his copy of all postings to medium-to-large
  2159. mailing lists?  On active lists, getting everything 1 hour after
  2160. everyone else may effectively cut you from the argument: by the time
  2161. your reply arrives, it is already 2 hours older than what the BITNET
  2162. folks have posted and you are probably just repeating what other
  2163. people said before - and giving the unfortunate impression that you
  2164. don't read what has been said before replying.
  2165.  
  2166. Of course, one way to address this problem is to buy faster lines and
  2167. bigger machines, thus making it possible for SMTP servers to handle
  2168. 500 concurrent TCP connections and 5,000 outstanding name server
  2169. queries, and then run name servers which can take 20,000 simultaneous
  2170. queries without timing out a single one.  The technology to handle
  2171. such workload exists, even though cost and other factors have caused
  2172. it not to be widely deployed.  But why not use smaller machines that
  2173. do a good job because they only need to deliver a dozen copies of a
  2174. message, rather than machines which are so big that they can handle
  2175. the full 1200, every third minute during peak hours, for each of the
  2176. hundreds of large mailing lists we now have?  As the network and its
  2177. community grows, there is no limit to the further resources a
  2178. "non-DISTRIBUTE" delivery system will require.
  2179.  
  2180. LISTSERV is delivering 2-6 million messages a day without hassle -
  2181. without anything special to do when creating a large list, and without
  2182. having to worry about finding a suitable newsgroup to move the
  2183. discussion to once the list grows large.  The distribution is
  2184. efficient, not only in terms of bandwidth and computer resources
  2185. (about one second of CPU time per thousand recipients on the smallest
  2186. machines you can buy from IBM, rated at just 3 S/370 MIPS), but above
  2187. all in terms of manpower.  The system takes care of itself and you
  2188. don't have to press people to set up local redistributions to avoid
  2189. saturating your machine or getting complaints from your local network
  2190. or system administrator.
  2191.  
  2192. While this distribution mechanism is implemented over BITNET, it can,
  2193. like most other LISTSERV services, be used from the Internet without
  2194. problem.  In fact, you can take advantage of DISTRIBUTE to optimize
  2195. the turnaround time of your sendmail exploders, simply by entrusting
  2196. the delivery to the DISTRIBUTE backbone, as explained in informational
  2197. RFC 1429 (Listserv Distribute Protocol).
  2198.  
  2199. Furthermore, a number of projects are underway to improve the
  2200. efficiency of this distribution mechanism for Internet recipients (for
  2201. which it is difficult to obtain accurate topological information).
  2202. LISTSERV is being modified to support "network aware" mode in
  2203. Internet-only environments; that is, within a few months it will be
  2204. possible to install fully functional LISTSERV servers on VM systems
  2205. without BITNET connectivity, and these servers will be able to
  2206. participate to the DISTRIBUTE backbone.  Another project concerns
  2207. itself with the collection of topological data for the Internet,
  2208. without which there can be no efficient distribution.  The EARN
  2209. Association, in particular, is going to review the possibility of
  2210. collecting, updating and maintaining such information in a standard
  2211. form as a value-added service to its membership.
  2212.  
  2213. ================================================
  2214. n-2-1-040.70
  2215.  
  2216. USENET
  2217. by Rick Adams
  2218. <rick@uunet.uu.net>
  2219.  
  2220. [graphics separately provided}
  2221.  
  2222. ================================================
  2223. n-2-1-040.90
  2224.  
  2225. News from RARE
  2226. by Josefien Bersee
  2227. <bersee@rare.nl>
  2228.  
  2229.  
  2230. START-UP CONTRACT OPERATIONAL UNIT SIGNED BY RARE
  2231.  
  2232. The setting up of the Operational Unit for the provision of networking
  2233. services to the European research community is progressing.  RARE -
  2234. acting on behalf of the OU - has signed the contract with the CEC for
  2235. the start-up of the OU, which will be located in Cambridge in the UK.
  2236.  
  2237. RARE TECHNICAL COMMITTEE REAPPOINTED
  2238.  
  2239. The RARE Technical Committee, the expert body guiding all RARE's
  2240. technical activities since April last year has been reappointed for a
  2241. two years' term, ending 1 May 1995.  In addition to the existing
  2242. members, Milan Sterba (Prague School of Economics) was designated to
  2243. represent RIPE.  Currently there is one vacancy, as Eike Jessen had to
  2244. resign.
  2245.  
  2246. The current RTC is chaired by Tomaz Kalin, RARE Secretary-General; Tim
  2247. Dixon, RARE Project Development Officer acts as Secretary. Other
  2248. members are: Brian Gilmore (Edinburgh University, United Kingdom),
  2249. Erik Huizer (SURFnet, Netherlands), Jean-Paul Le Guigner (CICB,
  2250. France), Bernhard Plattner (ETH Zuerich, Switzerland) and Sven
  2251. Tafvelin (NORDUnet, Chalmers Technical Institute, Sweden).  Howard
  2252. Davies (RARE Vice-President, University of Exeter, UK) liaises between
  2253. the RTC and the RARE Executive Committee and Christian Huitema (INRIA,
  2254. France) liaises between RARE and the Internet Architecture Board.
  2255.  
  2256. PUBLICATION OF RARE/EARN JOURNAL 
  2257.  
  2258. During its last meeting in Luxembourg in February, the RARE Council of
  2259. Administration approved the budget for the production of a paper
  2260. version of a new journal jointly published by RARE and EARN.  The new
  2261. publication will appear as quarterly supplement to the Elsevier North
  2262. Holland Journal, "Computer Networks and ISDN Systems".  The first issue
  2263. is planned to be published in Spring 1993.
  2264.  
  2265. PRELIMINARY PROGRAMME 4TH JENC AVAILABLE
  2266.  
  2267. The preliminary programme and registration form for the 4th Joint
  2268. European Networking Conference is now available from the RARE
  2269. Secretariat, on paper as well as electronically.  The conference will
  2270. be held in Trondheim, Norway, at the campus of the Norwegian Institute
  2271. of Technology.
  2272.  
  2273. NEW PROJECT DEVELOPMENT OFFICER AT RARE SECRETARIAT
  2274.  
  2275. Jeroen Houttuin has started work as PDO at the RARE Secretariat in
  2276. Amsterdam on January 1st.  He studied telematics at the University of
  2277. Twente and has been involved in R&D networking projects at GMD-FOKUS,
  2278. ETH Zuerich, and SWITCH.  He participated in the COSINE MHS Project
  2279. Team.  Jeroen will be involved in RARE Working Group activities,
  2280. upper-layer related issues in particular.
  2281.  
  2282. ================================================
  2283. n-2-1-050.01
  2284.  
  2285. NEW ADMINISTRATION BACKS INFORMATION SUPERHIGHWAYS
  2286. by Mike Roberts 
  2287. <roberts@ebony.educom.edu>
  2288.  
  2289.  
  2290. At a well publicized meeting in Silicon Valley in late February,
  2291. President Bill Clinton and Vice President Al Gore announced a technology
  2292. initiative for their new administration with potentially up to US $20
  2293. billion in funding over the next several years.
  2294.  
  2295. Contained within the plan is a major initiative for "Information
  2296. Superhighways" that is intended to build on Vice President Gore's
  2297. previous support for a National Research and Education Network (NREN)
  2298. and expand it to include investment in the information infrastructure of
  2299. the entire U.S.  Specific investments are targeted for networking
  2300. support in education at all levels, in manufacturing technology, health
  2301. care, and lifelong learning.
  2302.  
  2303. Although the announcement covered many areas of interest to the
  2304. networking community, details are still sparse.  The Administration will
  2305. not release its detailed budget for FY94, which begins 1 October 1993,
  2306. until the first week of April.  Many important positions in the federal
  2307. executive necessary to carry out the initiative are still vacant.
  2308.  
  2309. Controversy has arisen over whether the Clinton Administration intends
  2310. that the federal government have an operational role in a national high
  2311. performance computer network.  Many American telecommunications firms
  2312. are anxious to avoid any expansion of federal activity in markets they
  2313. consider already too regulated.
  2314.  
  2315. At the same time, public interest advocates are concerned that excessive
  2316. reliance on market forces will exclude many citizens from network
  2317. access, thus impacting their ability to acquire necessary work skills in
  2318. an increasingly information based economy.
  2319.  
  2320. In the Congress, both House and Senate members have introduced
  2321. legislation dealing with aspects of networking, ranging from
  2322. telecommunications policy to the assignment of network responsibilities
  2323. to several federal agencies.
  2324.  
  2325. Both the U.S. computer industry and the university community have called
  2326. for the appointment of a high level official to manage the large scale
  2327. networking effort being undertaken by the new Administration.  Thus far,
  2328. this step is being resisted by forces within federal agencies and their
  2329. Congressional sponsors whose prerogatives might be adversely affected as
  2330. a result of putting a single individual in charge.
  2331.  
  2332. ================================================
  2333. n-2-1-075.01
  2334.  by Deborah Estrin
  2335. <estrin@usc.edu>
  2336.  
  2337. Internetworking: Research and Experience is a quarterly, refereed
  2338. journal published by Wiley (D.  Comer, R. Droms, D. Estrin, and L.
  2339. Svobodova are the editors.)
  2340.  
  2341. In the second 1993 issue of the journal there are two papers of
  2342. interest to the ISOC community.  The papers represent the diversity of
  2343. research in the field, from modeling to protocol design and
  2344. experimentation.
  2345.  
  2346. "Model and Analysis of a Virtual Circuit with Cross Traffic", by B.
  2347. Jain (IIT), A. Agrawala, and Dheeraj Sanghi (Univ. Maryland), models
  2348. the flow of packets between a source and destination host, while
  2349. taking into account processing and competing cross-traffic in the
  2350. network elements (switches).  The model's predictions of inter-packet
  2351. departure time as a function of inter-packet send time are analyzed
  2352. and compared to measurements taken between host pairs on the Internet.
  2353.  
  2354. "Inter-Domain Routing Protocol" by Y. Rekhter (IBM), describes and
  2355. analyzes a protocol for inter-domain routing based on a Path Vector
  2356. algorithm. Path vector protocols are distributed in the sense of
  2357. distance vector protocols, however they avoid loops by including the
  2358. full domain-level path in each routing entry, in addition to the usual
  2359. (destination, distance) tuple found in most distance vector protocols.
  2360. IDRP has been designed to accommodate networks of virtually unlimited
  2361. size; for example, aggregation of routing information is widely
  2362. deployed, and at the same time, flexible aggregation is widely
  2363. supported.  The protocol was developed originally for OSI routing but
  2364. can be applied to IP routing as well.
  2365.  
  2366. ================================================
  2367. n-2-1-075.04
  2368.  
  2369. ConneXions
  2370. by Ole J Jacobsen*
  2371. <ole@csli.stanford.edu>
  2372.  
  2373. The March 1993 edition of ConneXions is a special issue devoted to
  2374. INTEROP 93 Spring (March 8 - 12 in Washington, DC). This edition
  2375. starts with an article on the INTEROPnet, INTEROP's unique show
  2376. network to which all exhibitors are required to connect and
  2377. demonstrate interoperability. This is followed by and article on APPI,
  2378. the alternative to IBM's APPN. OSF's Distributed Computing Environment
  2379. (DCE) is described next, as well as the soon-to-debut Internet Talk
  2380. Radio.  Finally you will find an article entitled "Multiprotocol
  2381. Internets: User's Best Hope for Open Systems." The article describes
  2382. several important trends in the networking marketplace.
  2383.  
  2384. We are pleased to offer all Internet Society members a 20% discount on
  2385. ConneXions subscription. Indicate your membership number on the order
  2386. form. For a complimentary sample issue, list of back issues and
  2387. subscription information, please send e-mail with your POSTAL address
  2388. to connexions@interop.com.
  2389.  
  2390. Future INTEROP dates and locations:
  2391. -----------------------------------
  2392. INTEROP 93 Fall:         San Francisco, CA, August 23 - 27, 1993
  2393. INTEROP 93 Europe:       Paris, France,     October 25 - 29, 1993
  2394. NETWORLD + INTEROP 94    Las Vegas, NV,     May 2 - 6, 1994
  2395. NETWORLD + INTEROP 94    Atlanta, GA,       September 12 - 16, 1994
  2396.  
  2397.  
  2398. *Editor and Publisher
  2399. ConneXions--The Interoperability Report
  2400. Interop Company
  2401.  
  2402. ================================================
  2403. n-2-1-075.05
  2404.  
  2405. Computer Networks and ISDN Systems
  2406. by Philip H. Enslow, Jr.*,
  2407. <enslow@cc.gatech.edu>  
  2408.  
  2409.  
  2410. Computer Networks and ISDN Systems, Published by North Holland,
  2411. Amsterdam.
  2412.  
  2413.  
  2414. As reported previously, Computer Networks and ISDN Systems is now
  2415. published twelve times a year.  We are well along into the 1993 volume
  2416. with issue number 7 having just been received by subscribers.  Volume
  2417. 25, Number 7, February, 1993 is a special issue on, "Tools for FDTs"
  2418. with Juan Quemada as the Guest Editor.  Plans are underway to
  2419. significantly increase the coverage of research networking in Europe.
  2420. More on that in the next issue of ISOC News.
  2421.  
  2422.  
  2423. *Editor-in-Chief, "Computer Networks and ISDN Systems"
  2424.  
  2425. ================================================
  2426. n-2-1-075.06
  2427.  
  2428. Matrix News
  2429. by John S. Quarterman*
  2430. jsq@tic.com
  2431.  
  2432. ]*indicates italics*]
  2433.  
  2434. The December 1992 *Matrix News* included a technical overview of ``MIME:
  2435. Multimedia Across the Internet,'' by Mark Thacker, an essay on ``Paying
  2436. for Internet Goods and Services...,'' by Peter Deutsch, and an
  2437. extensive list of ``Recent Internet Books,'' by John Quarterman, with a
  2438. table comparing the books by length, type, price, intended audience,
  2439. and type (e.g., user guide, travelog, or textbook).  You'll probably
  2440. find your favorite book in the list.  If not, let us know.  We're
  2441. always publishing more reviews and adding to the list.
  2442.  
  2443. The January 1993 issue contained much of the paper trail Gordon Cook
  2444. compiled in his investigation of ``NSFnet Privatization,'' by use of
  2445. the Freedom of Information Act (FOIA).  This is extended excerpts from
  2446. the actual documents, with very little editorializing.  In the same
  2447. issue, Eric Theise reviewed the book ``Zen and the Art of the Internet,''
  2448. by Brendan Kehoe, and Smoot Carl-Mitchell reviewed two items from
  2449. InfoMagic: a CD-ROM with many documents and software, and a set of
  2450. floppy disks.  Both have RFCs; the disks have them in Hypertext.  We
  2451. also ran the announcement by NFS of the ``Network Information Services
  2452. Awards'' and the announcement by EFF of ``Major Changes at the
  2453. Electronic Frontier Foundation.''
  2454.  
  2455. For February 1993 we have a special *Matrix News* issue with one article,
  2456. ``Maps of Networks by Country.'' This article consists almost entirely
  2457. of bar graph maps, with a bar over each country or region, showing the
  2458. number of hosts on a network in that area.  There are maps for each of
  2459. FidoNet, UUCP, BITNET, and the Internet.  Each network is shown in each
  2460. of the world, Europe, and the United States, for twelve maps total.
  2461.  
  2462. The March 1993 issue of *Matrix News* will have some material on
  2463. the most networked countries, the most northerly and southerly
  2464. networked places, and a bit of a graphical surprise, in color.
  2465.  
  2466. *Matrix Information and Directory Services, Inc. (MIDS)
  2467. tel:+1-512-451-7602
  2468.  
  2469. ================================================
  2470. n-2-1-100.08
  2471.  
  2472. IFIP News
  2473. by Howard L. Funk
  2474. <funk@vnet.ibm.com>
  2475.  
  2476. IFIP mourns the death of its key founder, Mr. Isacc L. Auerbach, who
  2477. died of myelofibrosis on 24 December 1992. He was instrumental in the
  2478. creation of IFP and served as its first president from 1960 to 1965.
  2479. We owe him an immeasurable debt.
  2480.  
  2481. FOCUS, the United Representative to IFIP has elected new officers.
  2482. Dr. Robert M. Aiken - Chair; Dr. Mario R. Barbacci - Secretary/Treasurer:
  2483. Dr. Stuart H. Zweben, Dr. J. Tom Cain, and Prof. Gordon B. Davis -
  2484. Directors.
  2485.  
  2486. Through the good offices of the Internet Society information about
  2487. IFIP and FOCUS now lives on GOPHER. The ftp repository is
  2488. software.watson.ibm.com in the /pub/ifip directory. The listserve
  2489. repository is in LISTSERV@CEARN (request index txt to see what is
  2490. available).
  2491.  
  2492. Last September the IFIP Technical Assembly approved the formation of
  2493. a Working Group on Human-Computer Interaction and People with
  2494. Special Needs. For additional information contact the Chair of this
  2495. group, Porf. J. Gonzales-Abascal (julio@si.ehu.es).
  2496.  
  2497. The Council of European Professional Informatics Societies (CEPIS)
  2498. met in Vienna in March. IFIP decided to hold its Council meeting in
  2499. Vienna during the same week to give the leadership of both organizations
  2500. the opportunity to meet to discuss future relationships.
  2501.  
  2502. The following meetings may be of special interest to members of the
  2503. Internet Society.
  2504.  
  2505. Third International Symposium of Integrated Network Management, 18-23
  2506. April 93, San Francisco, USA.
  2507.  
  2508. Ninth International Conference on Computer Security, 12-14 May 93,
  2509. Toronto, Canada.
  2510.  
  2511. Thirteenth International Symposium on Protocol Specification, Testing,
  2512. and Verification, 25-28 May 93, Leige, Belgium.
  2513.  
  2514. First Working Conference on Development and Implementation of
  2515. Computer-Based Information and Communications Networks, 16-18 June 93,
  2516. Vienna, Austria.
  2517.  
  2518. For additional information about any of these events contact the
  2519. IFIP Secretariat: ifip@cgeueg51.bitnet.
  2520.  
  2521. ================================================
  2522. n-2-1-900.07
  2523. Internet Research Task Force (IRTF)
  2524. by Jon Postel*
  2525. <postel@isi.edu>
  2526.  
  2527.  
  2528. The research groups of the IRTF are oriented towards longer term
  2529. Internet research issues.  The research groups tend to be small (that
  2530. is, about 10 to 20 people), and to have consistent membership.  The
  2531. results of the research groups tend to be experiments in new protocol
  2532. ideas, new applications, and new approaches.  Any results of research
  2533. groups that are appropriate for wide spread use in the Internet are
  2534. submitted to the normal IETF standards process.  Many of the
  2535. participants in the research groups are also active in the computer
  2536. science research community and there is a healthy interaction between
  2537. the work in the research groups and work in other venues (such as ACM
  2538. SIGCOMM).
  2539.  
  2540. The IRTF is composed of the following research groups:
  2541.  
  2542.         Research Group Name     Chair
  2543.         -------------------     ----------------
  2544.         Autonomous Networks     Deborah Estrin (USC)
  2545.         End-to-End Services     Bob Braden (ISI)
  2546.         Resource Discovery      Mike Schwartz (U Colorado)
  2547.         Privacy and Security    Steve Kent (BBN)
  2548.         Libraries               Cliff Lynch (UCOP)
  2549.  
  2550. The IRTF Steering Group (IRSG) is composed of the research group
  2551. chairs (above) and the following at large members:
  2552.  
  2553.         Dave Clark (MIT)
  2554.         Dave Mills (UDEL)
  2555.         Bruce Schatz (U Arizona)
  2556.  
  2557.  
  2558. *Associate Director for Networking HPCC Division, Information Sciences
  2559. Institute, University of Southern California
  2560.  
  2561.  
  2562. ================================================
  2563. n-2-1-900.08
  2564.  
  2565. Note from the RFC-Editor
  2566. by Jon Postel*
  2567. <postel@isi.edu>
  2568.  
  2569.  
  2570. Request for Comments documents (RFCs) are now available via FTP from
  2571. at least 20 on-line repositories around the world, and at least 6 of
  2572. these provide automated retrieval via email.
  2573.  
  2574. A complete listing of these sources and other "help" information about
  2575. accessing RFCs can be obtained via an email request to the RFC-INFO
  2576. service:
  2577.  
  2578.         To: RFC-INFO@ISI.EDU
  2579.         Subject: Accessing RFCs
  2580.  
  2581.         Help: ways_to_get_rfcs
  2582.  
  2583. In the last five months, 61 RFCs have been published.
  2584.  
  2585.         Oct     Nov     Dec     Jan     Feb
  2586.         10      10      1       27      13
  2587.  
  2588. The most recent summary of the status of various standards and their
  2589. corresponding RFCs is "IAB Official Protocol Standards" which is STD-1
  2590. and RFC-1360.
  2591.  
  2592.  
  2593. *Associate Director for Networking HPCC Division, Information Sciences
  2594. Institute, University of Southern California
  2595.  
  2596. ================================================
  2597. n-1-2-900.09
  2598.  
  2599. The Internet Assigned Numbers Authority (IANA)
  2600.  by JonPostel*
  2601.  <postel@isi.edu>
  2602.  
  2603.  
  2604. The IANA is the central coordinator for the assignment of unique
  2605. parameter values.  Requests for parameter assignments should be sent
  2606. to <iana@isi.edu>.
  2607.  
  2608. The most recent summary of these assigned parameter values is
  2609. "Assigned Numbers" which is STD-2 and RFC-1340.
  2610.  
  2611.  
  2612. *Associate Director for Networking HPCC Division, Information Sciences
  2613. Institute, University of Southern California
  2614.  
  2615. ================================================
  2616. n-2-1-900.12
  2617.  
  2618. Standards Actions
  2619. by Steve Coya*
  2620. <scoya@cnri.reston.va.us>
  2621.  
  2622. The Internet Engineering Steering Group (IESG) approved or recommended
  2623. the following twenty-two (22) actions between 1 January 1993 and 28 February
  2624. 1993:
  2625.  
  2626.    o  Network Time Protocol <rfc1305> as a Draft Standard.
  2627.    o  A String Representation of Distinguished Names
  2628.       <draft-ietf-osids-distnames> as a Proposed Standard.
  2629.    o  Using the OSI Directory to Achieve User Friendly Naming
  2630.       <draft-ietf-osids-friendlynaming> as an Experimental Protocol.
  2631.    o  Privacy Enhancement for Internet Electronic Mail: Part I: Message
  2632.       Encryption and Authentication Procedures <draft-ietf-pem-msgproc>
  2633.       as a Proposed Standard.
  2634.    o  Privacy Enhancement for Internet Electronic Mail: Part II:
  2635.       Certificate-Based Key Management <draft-ietf-pem-keymgmt> as a
  2636.       Proposed Standard.
  2637.    o  Privacy Enhancement for Internet Electronic Mail: Part III:
  2638.       Algorithms, Modes, and Identifiers <draft-ietf-pem-algorithms> as
  2639.       a Proposed Standard.
  2640.    o  Privacy Enhancement for Internet Electronic Mail: Part IV: Key
  2641.       Certification and Related Services <draft-ietf-pem-forms> as a
  2642.       Proposed Standard.
  2643.    o  Definitions of Managed Objects for the DS1 Interface Type <rfc1232>
  2644.       now has a status of Historic.
  2645.    o  Definitions of Managed Objects for the DS3 Interface Type <rfc1233>
  2646.       now has a status of Historic.
  2647.    o  Definitions of Managed Objects for the DS1 and E1 Interface Types
  2648.       <draft-ietf-trunkmib-ds1e1mib> as a Proposed Standard.
  2649.    o  Definitions of Managed Objects for the DS3/E3 Interface Type
  2650.       <draft-ietf-trunkmib-ds3e3mib> as a Proposed Standard.
  2651.    o  FYI on a Network Management Tool Catalog: Tools for Monitoring and
  2652.       Debugging TCP/IP Internets and Interconnected Devices
  2653.       <draft-ietf-noctool2-debug-tcpip> as an Informational Document
  2654.    o  SMTP Service Extensions <draft-rose-extensions> as a Proposed
  2655.       Standard.
  2656.    o  SMTP Service Extension for Message Size Declaration
  2657.       <draft-moore-extension-size> as a Proposed Standard.
  2658.    o  Transition of Internet Mail from Just-Send-8 to 8Bit-SMTP/MIME
  2659.       <draft-ietf-smtpext-transition> as an Informational Document
  2660.    o  SMTP Service Extension for 8bit-MIMEtransport
  2661.       <draft-ietf-smtpext-8bit-mime> as a Proposed Standard.
  2662.    o  Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
  2663.       <draft-ietf-x400ops-mapsmail> as an Experimental Protocol.
  2664.    o  Lightweight Directory Access Protocol <draft-ietf-osids-lightdirect>
  2665.       as a Proposed Standard.
  2666.    o  The String Representation of Standard Attribute Syntaxes
  2667.       <draft-ietf-osids-syntaxes> as a Proposed Standard.
  2668.    o  Internet Users' Glossary <draft-ietf-userglos-glossary> as an
  2669.       Informational Document
  2670.    o  Directed ARP <draft-ietf-iplpdn-directed_arp> as an Experimental
  2671.       Protocol.
  2672.    o  DUA Metrics <draft-ietf-osids-dua-metrics> as an Informational
  2673.       Document
  2674.  
  2675. Forty (40) Requests for Comments (RFC) were published between 1 January
  2676. and 28 February 1993:
  2677.  
  2678.   RFC       St  Title
  2679.   -------   --  -------------------------------------
  2680.   RFC1384   I   Naming Guidelines for Directory Pilots
  2681.   RFC1387   I   RIP Version 2 Protocol Analysis
  2682.   RFC1388   PS  RIP Version 2 Carrying Additional Information
  2683.   RFC1389   PS  RIP Version 2 MIB Extension
  2684.   RFC1390   S   Transmission of IP and ARP over FDDI Networks
  2685.   RFC1391   I   The Tao of IETF: A Guide for New Attendees of the Internet
  2686.                 Engineering Task Force
  2687.   RFC1392   I   Internet Users' Glossary
  2688.   RFC1393   E   Traceroute Using an IP Option
  2689.   RFC1394   I   Relationship of Telex Answerback Codes to Internet Domains
  2690.  
  2691.   RFC1395   I   BOOTP Vendor Information Extensions
  2692.   RFC1396   I   The Process for Organization of Internet Standards Working
  2693.                 Group (POISED)
  2694.   RFC1397   PS  Default Route Advertisement In BGP2 And BGP3 Versions Of
  2695.                 The Border Gateway Protocol
  2696.   RFC1398   DS  Definitions of Managed Objects for the Ethernet-like
  2697.                 Interface Types
  2698.   RFC1401   I   Correspondence between the IAB and DISA on the use of DNS
  2699.                 throughout the Internet
  2700.   RFC1402   I   There's Gold in them thar Networks! Searching for Treasure
  2701.                 in all the Wrong Places
  2702.   RFC1403   PS  BGP OSPF Interaction
  2703.   RFC1404   I   A Model for Common Operational Statistics
  2704.   RFC1405   E   Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
  2705.   RFC1406   PS  Definitions of Managed Objects for the DS1 and E1
  2706.                 Interface Types
  2707.   RFC1407   PS  Definitions of Managed Objects for the DS3/E3 Interface
  2708.                 Type
  2709.   RFC1408   PS  Telnet Environment Option
  2710.   RFC1409   E   Telnet Authentication Option
  2711.   RFC1411   E   Telnet Authentication: Kerberos Version 4
  2712.   RFC1412   E   Telnet Authentication : SPX
  2713.   RFC1413   PS  Identification Server
  2714.   RFC1414   PS  Ident MIB
  2715.   RFC1415   PS  FTP-FTAM Gateway Specification
  2716.   RFC1416   E   Telnet Authentication Option
  2717.   RFC1417   I   NADF Standing Documents: A Brief Overview
  2718.   RFC1421   PS  Privacy Enhancement for Internet Electronic Mail: Part I:
  2719.                 Message Encryption and Authentication Procedures
  2720.   RFC1422   PS  Privacy Enhancement for Internet Electronic Mail: Part
  2721.                 II: Certificate-Based Key Management
  2722.   RFC1423   PS  Privacy Enhancement for Internet Electronic Mail: Part
  2723.                 III: Algorithms, Modes, and Identifiers
  2724.   RFC1424   PS  Privacy Enhancement for Internet Electronic Mail: Part
  2725.                 IV: Key Certification and Related Services
  2726.   RFC1425   PS  SMTP Service Extensions
  2727.   RFC1426   PS  SMTP Service Extension for 8bit-MIMEtransport
  2728.   RFC1427   PS  SMTP Service Extension for Message Size Declaration
  2729.   RFC1428   I   Transition of Internet Mail from Just-Send-8 to
  2730.                 8Bit-SMTP/MIME
  2731.   RFC1429   I   Listserv Distribute Protocol
  2732.   RFC1430   I   A Strategic Plan for Deploying an Internet X.500 Directory
  2733.                 Service
  2734.   RFC1431   I   DUA Metrics
  2735.  
  2736.  
  2737. Key to RFC Status: S Internet Standard
  2738.                    PS Proposed Standard
  2739.                    DS Draft Standard
  2740.                    E Experimental
  2741.                    I Informational
  2742.  
  2743. * Executive Director, IETF Secretariat
  2744.  
  2745. ================================================
  2746. n-2-1-fill1
  2747.  
  2748. Silicon Valley Realtors on the Internet
  2749.  
  2750. A recent issue of the Palo Alto Weekly carried a full-page ad for a
  2751. Realty Company in Saratoga California. Like most such advertisements,
  2752. it has a photograph of each of the 35 realtors who work for the agency.
  2753. Under each photograph is an Internet address of them.
  2754.  
  2755. ================================================
  2756. n-2-1-fill2
  2757.  
  2758. 4th JOINT EUROPEAN NETWORKING CONFERENCE
  2759.  
  2760. The 4TH Joint European Networking Conference will take place
  2761. in Trondheim, Norway, from May 10-13, 1993.
  2762.  
  2763. Theme of the conference is: "EUROPEAN RESEARCH NETWORKING IN A GLOBAL
  2764. CONTEXT"
  2765.  
  2766. The event is organized by RARE in cooperation with: ACM SIGCOMM, EARN,
  2767. EUnet/EurOpen, IFIP TC6, Internet Architecture Board, Internet Society,
  2768. NORDUnet, and UNINETT.  The conference will be held at the main campus 
  2769. of the Norwegian Institute of Technology
  2770.  
  2771. The programme includes a wide variety of technical, operational, and
  2772. developmental topics.
  2773.  
  2774. This year for the first time tutorials will be organized, and held
  2775. at the end of the Conference.
  2776.  
  2777. The registration fee includes the full set of papers as they will be
  2778. presented during the conference, and all festivities.
  2779.  
  2780. For more information: RARE Secretariat, Josefien Bersee (bersee@rare.nl)
  2781.  
  2782. ================================================
  2783. n-2-1-fill3
  2784.  
  2785. _The Internet Society's On-Line Information Services_
  2786. by John W. Stewart III
  2787. <jstewart@cnri.reston.va.us>
  2788.  
  2789. The Internet Society has taken steps to make it easier for people
  2790. to access information of interest to ISOC members. Information is
  2791. available via Gopher, anonymous FTP, and WAIS servers, all at
  2792. ietf.cnri.reston.va.us.
  2793.  
  2794. (An introduction to Gopher can be found via anonymous FTP on
  2795. boombox.micro.umn.edu under:
  2796.  
  2797.       /pub/gopher/gopher_protocol/protocol.txt.)
  2798.  
  2799. The Gopher is currently configured to provide information about the
  2800. Internet Society, Internet Engineering Task Force, International
  2801. Federation for Information Processing and, as a special bonus, US
  2802. White House press releases. For all three of these organizations,
  2803. the Gopher provides text files, gateways to anonymous FTP areas,
  2804. and gateways for keyword searching of documents. The Internet
  2805. Society News is accessible on-line through these services.
  2806.  
  2807. The anonymous FTP files of particular interest are in sub-
  2808. directories:  iesg, ietf, ietf-mail-archive, internet-drafts and
  2809. isoc.
  2810.  
  2811. WAIS information databases of interest include INFO, isoc, rfc and
  2812. internet-drafts.
  2813.  
  2814. The Gopher server has been registered with the University of
  2815. Minnesota, and can be accessed by choosing the "Internet Society"
  2816. entry underneath the "North America / USA / General" listing.
  2817.  
  2818. ================================================
  2819. n-2-1-fill4
  2820.  
  2821. Dynamic WAIS Prototype Announcement
  2822. by Mike Schwartz
  2823. <schwartz@cs.colorado.edu>
  2824.  
  2825. Dynamic WAIS is a system that extends the WAIS (Wide Area Information
  2826. Service) paradigm to support information from remote search systems (as
  2827. opposed to the usual collection of static documents).  We have a
  2828. prototype that supports gateways from WAIS to Archie and to Netfind,
  2829. using the Z39.50 information retrieval protocol to seamlessly integrate
  2830. the information spaces.  Unlike menu-level gateways (such as the current
  2831. interim telnet interface from the Internet Gopher system to Netfind),
  2832. Dynamic WAIS uses the Z39.50 information retrieval protocol to
  2833. seamlessly integrate the information spaces.  This approach allows users
  2834. to access a great deal of diverse information without learning multiple
  2835. user interfaces.
  2836.  
  2837. The key idea behind the Dynamic WAIS gateways is the conceptual work of
  2838. constructing mappings between the WAIS search-and-retrieve operations,
  2839. and the underlying Archie and Netfind operations.  In the case of
  2840. Netfind, for example, when the Dynamic WAIS user requests a search using
  2841. the "dynamic-netfind.src" WAIS source, the search is translated to a
  2842. lookup in the Netfind seed database, to determine potential domains to
  2843. search.  The Netfind domain selection request is then mapped into a WAIS
  2844. database selection request.  Once the user selects one of the domains to
  2845. search, the WAIS retrieval phase is mapped into an actual domain search
  2846. in Netfind.
  2847.  
  2848. The actual implementation of Dynamic WAIS involves fairly
  2849. straightforward extensions to the standard WAIS code.  Whereas standard
  2850. WAIS has a search and a retrieval phase, with dynamic WAIS the retrieval
  2851. phase can trigger a remote search (which could cascade if the retrieval
  2852. for that search caused another search, although the current prototype
  2853. only goes one level deep).  The problem that arises is that the standard
  2854. WAIS client does not send the keywords to the server during the
  2855. retrieval phase.  The Dynamic WAIS client sends the keywords in both
  2856. phases, and also understands how to display the results of Dynamic
  2857. searches.
  2858.  
  2859. If you would like to learn more about Dynamic WAIS, you can obtain the
  2860. source to the Dynamic WAIS prototype via anonymous ftp from
  2861. ftp.cs.colorado.edu in /pub/cs/distribs/dynamicwais.  This directory
  2862. also contains WAIS ".src" files for the Dynamic WAIS gateways to Archie
  2863. and Netfind.  A paper on Dynamic WAIS is in preparation.
  2864.  
  2865. This WAIS server was created in January 1993 by Darren R. Hardy and
  2866. Michael F. Schwartz as part of the Networked Resource Discovery
  2867. Project.
  2868.  
  2869. ================================================
  2870. n-2-1-fill5
  2871.  
  2872. TCP/IP "Bake-Off" HELD TO ENSURE INTEROPERABILITY
  2873. - --First Test Meet Sees 13 Vendors Testing Protocol Suite Implementations--
  2874.  
  2875. Engineers from 14 companies gathered at North Andover, Massachusetts,
  2876. in February
  2877. for a multivendor Transmission Control Protocol/Internet
  2878. Protocol (TCP/IP) "Bake-Off".  The vendors attending the Bake-Off
  2879. exercised their implementations of the TCP/IP
  2880. protocol suite to test interoperability between products.
  2881.  
  2882. Participating in the week of testing were: BSDI, Data General Corporation,
  2883. Digital Equipment Corporation, Empirical Tools and Technologies, Inc.,
  2884. FTP Software, Inc., Hewlett-Packard Company, InterCon Systems Corporation,
  2885. Lachman Technology, Inc., Mentat Inc., Microsoft Corporation, Novell, Inc.,
  2886. TGV, Inc., Tule Network Services, and Xyplex, Inc.
  2887.  
  2888. While there have been multivendor networks at trade shows such as UniForum,
  2889. the Federal Computer Conference and INTEROP for nearly 10 years now, as well
  2890. as groups who meet regularly to work with SNMP, NFS, X and similar standards,
  2891. there has been little cooperative testing of the underlying TCP/IP stacks and
  2892. their associated application-level protocol suites.  This appears in the
  2893. fact that there are some implementations currently available which
  2894. are unable to successfully negotiate even some of the more basic
  2895. communications options, or keep network links open when hardware or software
  2896. anomalies occur.
  2897.  
  2898. "Networking customers do - and should be able to - expect a wide range of
  2899. products to be able to interoperate", said one of the organizers of the
  2900. event.  "Participation in a testing event such as this demonstrates a
  2901. vendor's commitment to quality, and at the same time provides another
  2902. potent quality control function for networking consumers."  He went on to
  2903. say that "network vendors are presented with an unique paradox:  in order
  2904. to compete against each other, they have to work together - because any
  2905. networking product that cannot communicate with another networking product
  2906. rather rapidly ceases to have discernable practical utility."
  2907.  
  2908. The Bake-Off effort began when an open invitation to participate was given
  2909. at the November 1992 IETF (Internet Engineering Task Force) meeting in
  2910. Washington D.C., the Bake-Off was founded on an example set by Jon Postel
  2911. of USC's Information Sciences Institute, one of the original TCP/IP
  2912. designers, almost 12 years ago.  While the recent testing took place in a
  2913. secure area, and actual test results will not be made public, some of the
  2914. tests designed and used by the participants will be made openly available to
  2915. members of the networking industry.
  2916.  
  2917. Since this was the first such event in so long a time, it was expected,
  2918. in part, to be a trial effort.  All participants felt that the exercise was
  2919. a success, and there are plans to hold another Bake-Off within the year.
  2920. In fact, several vendors have reported that improvements developed at the
  2921. Bake-Off would be included in future releases.
  2922.  
  2923. ================================================
  2924. n-2-1-fill6
  2925.  
  2926. Internet and the Handicapped
  2927.  
  2928. For many of us, the Internet has become an indispensible
  2929. part of our professional life and career activities.  For
  2930. other Internauts, it is somewhat more special.  The
  2931. following note was recently posted by David Richman 
  2932. <D_RICHMAN@UNHH.UNH.EDU> on the Shakespeare Electronic
  2933. Conference list:
  2934.  
  2935.   A query to anyone on this list associated with *Shakespeare Bulletin* or
  2936.   *Shakespeare Quarterly*.  Any chance of either of these periodicals becoming
  2937.   available electronically, perhaps through GOPHER or some other electronic
  2938.   service.  Being blind, I and my speech synthesizer take delight in online
  2939.   material.  I would be willing to pay up to twice the normal subscription
  2940.   rate for either of these journals in electronic form.  Thanks.
  2941.  
  2942. ================================================
  2943. n-2-1-fill7
  2944.  
  2945. The Secret Internet
  2946.  
  2947. As the Internet continues to scale exponentially worldwide, it is being constantly
  2948. featured in numerous publications.  One of the more unusual, however, was the
  2949. 26 December issue of THE ECONOMIST.   An articled entitled  "THE GOOD
  2950. NETWORK GUIDE - Being one of us" ranked networking groups on several factors.
  2951. The Internet  made this noted list, but with rather curious attributes.
  2952.  
  2953.  
  2954.   The following are measured on a scale from 0 to 5, 0 = lowest, 5 = highest:
  2955.   P = Power
  2956.   S = Secrecy
  2957.   O = Organization
  2958.   B = Strength of Beliefs
  2959.   P = Peculiarity of rituals
  2960.   E = Exclusivity
  2961.  
  2962.   Conspiracy ("Network")                          P    S    O    B    P    E
  2963.   ---------------------------------------------  ---  ---  ---  ---  ---  ---
  2964.   Old Etonians                                    3    1    1    2    3    4
  2965.   Cambridge University Conservative Association   3    1    4    0    2    2
  2966.   Skull and Bones                                 2    4    2    0    5    5
  2967.   Inspection Generale de Finance                  5    2    5    3    1    5
  2968.   Doon School                                     4    1    2    3    1    4
  2969.   law school of Tokyo U.                          5    2    5    3    1    5
  2970.   Rhodes scholarship                              3    0    3    1    1    4
  2971.   Mont Pelerin Society                            2    3    3    5    2    3
  2972.   Committee to Defend the Workers (KOR)           4    3    3    4    1    4
  2973.   The Communist Party (XSU)                       4    5    2    1    1    3
  2974.   Broederbond                                     4    4    4    4    4    2
  2975.   Muslim Brotherhood                              2    3    4    5    3    1
  2976.   Opus Dei                                        2    4    4    5    5    1
  2977.   Freemasonry                                     3    4    4    3    5    2
  2978.   Trilateral Commission                           4    3    3    1    0    5
  2979.   USENET and Internet                             2    0    1    2    5    1
  2980.   Order of Illuminati                             5    5    5    5    5    5
  2981.  
  2982. ================================================
  2983.  n-2-1-fill8
  2984.  
  2985. ISOC Nominations Committee Report
  2986.  
  2987. Six Trustee positions are to be determined in the 1993 elections. Four
  2988. of these positions  are Trustee  positions created  in  1993, and  two
  2989. positions are the result  of the  standing down of Trustees  Harms and
  2990. Aiso.
  2991.  
  2992. Selected Candidates
  2993. ---------------------
  2994.  
  2995. The  following  individuals have  been  selected  by  the  Nominations
  2996. Committee as candidates in the 1993 election:
  2997.  
  2998.         Peter Bakonyi           h25bak@huella.bitnet
  2999.         Xavier Baquero          xbaquero@ecnet.ec
  3000.         Scott Bradner           sob@das.harvard.edu
  3001.         Nevil Brownlee          nevil@ccu1.aukuni.ac.nz
  3002.         Brian Carpenter         brian@dxcern.cern.ch
  3003.         Susan Estrada           estradas@cerf.net
  3004.         Dave Farber             farber@cis.upenn.edu
  3005.         Howard Funk             funk@vnet.ibm.com
  3006.         Haruhisa Ishida         ishida@u-tokyo.ac.jp
  3007.         Gary Malkin             malkin@xylogics.com
  3008.         Jean Polly              jpolly@nysernet.org
  3009.         Dave Sincoskie          sincos@thumper.bellcore.com
  3010.  
  3011.  
  3012. Petition Candidates
  3013. ---------------------
  3014.  
  3015. The following individuals have submitted membership petitions signed by
  3016. a minimum of 50 ISOC individual members by the nominated due date:
  3017.  
  3018.         Jon Postel              postel@isi.edu
  3019.         Yakov Rekhter           yakov@watson.ibm.com
  3020.  
  3021.  
  3022. Candidate Details
  3023. -------------------
  3024.  
  3025. Submitted  details  of  all  listed candidates  are  held on  the host
  3026. aarnet.edu.au in the directory /pub/isoc/candidates
  3027.  
  3028. Biographies of all candidates are also available in the Internet
  3029. Society Gopher server (ietf.cnri.reston.va.us) and also in the
  3030. ftp/isoc/elections anonymous FTP directory on the same machine.
  3031.  
  3032. The Internet Society Nominations Committee:
  3033.         G. Huston (Chair)
  3034.         R. Blokzijl
  3035.         I. Fuchs
  3036.         T. Kalin
  3037.         C. Partridge
  3038.         H. Tokuda
  3039.  
  3040.  ================================================
  3041.  n-2-1-fill9
  3042.  
  3043. Transition to the New INTERNIC Team
  3044.  
  3045. Please note, after 31 MARCH, operations of the NSF Network Service
  3046. Center (NNSC) will be discontinued.  The services formerly provided
  3047. by the NNSC will be transferred to a new Network Information Services
  3048. Management team, collectively known as the INTERNIC (the Internet
  3049. Network Information Center).
  3050.  
  3051. As a result of a competitive solicitation, the National Science
  3052. Foundation (NSF) has awarded new contracts for NSFNET/NREN services:
  3053.  
  3054.    *  Network Solutions (NSI), has provided registration for the
  3055.       NSFNET since January 1992, and will continue to perform
  3056.       these services.
  3057.  
  3058.    *  AT&T will provide expanded directory and database services.
  3059.  
  3060.    *  General Atomics, which now operates CERFnet and the San
  3061.       Diego Supercomputer Center, will provide a Help Desk and
  3062.       general information services.
  3063.  
  3064. The new INTERNIC phone number is 800-444-4345 and email is
  3065. info@internic.net.  The phone number is scheduled to be in
  3066. service on 1 April  1993 with a voice menu:
  3067.  
  3068.         1 - REGISTRATION SERVICES               Direct dial: 703-742-4757
  3069.                 Network Solutions, Inc. (NSI)   Email: hostmaster@nic.ddn.mil
  3070.                 Herndon, VA
  3071.  
  3072.         2 - DIRECTORY AND DATABASE SERVICES     Direct dial: 908-668-6587
  3073.                 AT&T                            FAX: 908-668-3763
  3074.                 5000 Handley Road, Room 2F25    Email: admin@ds.internic.net
  3075.                 South Plainfield, NJ 07080
  3076.  
  3077.         3 - INFORMATION SERVICES                Direct dial: 619-455-4600
  3078.                 General Atomics                 Email: info@internic.net
  3079.                 San Diego, CA
  3080.  
  3081.         4 - TO SPEAK WITH A RECEPTIONIST
  3082.  
  3083. After April 1, the resource-guide and policies-procedures online files
  3084. will be made available through AT&T/INTERNIC, as will the shadow
  3085. copies of RFCs, internet-drafts, ietf, iesg, and isoc.  The NNSC
  3086. Info-Server will no longer be available, but the INTERNIC hosts will
  3087. provide email servers.  The nnsc.nsf.net will announce details as they
  3088. become available.
  3089.  
  3090. A longer version of this announcement is in /nsfnet/transition
  3091. in the anonymous ftp directory on nnsc.nsf.net, or send email to
  3092. info-server@nnsc.nsf.net with the these lines in the text field:
  3093.         request: nsfnet
  3094.         topic: transition
  3095.  
  3096.  ================================================
  3097.  n-2-1-fill10
  3098.  
  3099. INET'93 - Towards a Global Community
  3100. International Networking Conference
  3101. Internet Society
  3102. San Francisco, CA  17-20 August 1993
  3103.  
  3104. The International Networking Conference is the annual conference of the
  3105. Internet Society, a new professional society serving the Internet
  3106. community. Following the very successful INET'92, INET'93 will be held
  3107. on 17-20 August 1993 in San Francisco.  Focusing on worldwide issues of
  3108. research and academic networking, the goal of INET'93 is to bring
  3109. together individuals from university, industry and government who are
  3110. involved with planning, developing, implementing, managing and funding
  3111. national, regional and international research, academic, and commercial
  3112. networks.
  3113.  
  3114. The conference
  3115. agenda will include plans and status reports on research and academic
  3116. networks throughout the world.  Major topics include:
  3117.  
  3118.   Network Technology: Advances in the Network Technology Base
  3119.  
  3120.   Network Engineering: Building the Global Infrastructure
  3121.  
  3122.   Application Technology: Enabling Technologies for Distributed
  3123.   Applications
  3124.  
  3125.   User Applications: Support for International Communities of Interest
  3126.  
  3127.   Regional Issues: Networking Around the Globe
  3128.  
  3129.   Policy Issues: Governance, Management, and Financing of International
  3130.   Networks
  3131.  
  3132. The conference will be held immediately preceding Fall Interop '93,
  3133. the leading trade show for Internet technologies. This will make
  3134. possible attending both events as well as tutorials given as part of
  3135. Interop '93.
  3136.  
  3137.  
  3138. Workshop for Developing Countries
  3139.  
  3140. A workshop designed to assist developing countries in their installation
  3141. and use of networking technology and services is being organized and will
  3142. take place during the week before the conference in the San Francisco Bay
  3143. Area.
  3144.  
  3145. Conference Chair:          Eric Benhamou, President, 3Com
  3146.  
  3147. To be added to the conference mailing list or for other requests, send
  3148. mail, fax or E-mail to:
  3149.  
  3150. USRA
  3151. ATTN: INET'93
  3152. 625 Ellis Street, Suite 205
  3153. Mountain View, CA  94043
  3154. USA
  3155. tel: +1 415 390-0317
  3156. fax: +1 415 390-0318
  3157. Request@inet93.stanford.edu
  3158.  the INTERNIC (the Internet
  3159. Network Information Center).
  3160.