home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / tcpip / 5745 < prev    next >
Encoding:
Text File  |  1992-12-24  |  5.7 KB  |  161 lines

  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!noc.near.net!vaxeline.ftp.com!flaky.wco.ftp.com!edwin
  3. From: edwin@vax.ftp.com  (Edwin Chow)
  4. Subject: Request for Bakeoff Test Proposals
  5. Message-ID: <921224124316@flaky.wco.ftp.com>
  6. Nntp-Software: PC/TCP NNTP
  7. Lines: 146       
  8. Sender: root@vaxeline.ftp.com (vaxeline.ftp.com root account)
  9. Nntp-Posting-Host: flaky.wco.ftp.com
  10. Reply-To: edwin@wco.ftp.com
  11. Organization: FTP Software, Inc., Wakefield, MA
  12. Date: Thu, 24 Dec 1992 12:43:16
  13.  
  14. Hi,
  15.  
  16. On February 8 - February 12 several TCP/IP vendors will be meeting to
  17. test the interoperablity of their products at a "TCP/IP bakeoff".
  18.  
  19. The following is a form that you can use to submit test cases for the
  20. upcoming TCP/IP bakeoff.  The sponsoring companies will then create these
  21. test cases which will be used to test interoperablity at the bakeoff.
  22.  
  23. You can also send me your suggestions without using the form and I will edit
  24. them for you.
  25.  
  26. We feel that it is important to get a wide variety of test proposals from the
  27. internet community in order to understand what are the major concerns 
  28. involving TCP/IP interoperability. While these tests will not be an official
  29. verification suite, we will make the list of tests run at the bakeoff 
  30. available in hopes of helping everyone developing TCP/IP products.
  31.  
  32. ***** Send the tests to me at edwin@wco.ftp.com *****
  33.  
  34. ***** Send further inquires about the bakeoff to bakeoff@TGV.com *****
  35.  
  36. I will also make the current list of tests available to anyone who is 
  37. interested.
  38.  
  39. Thanks,
  40.  
  41. Ed
  42.  
  43. P.S.  Also enclosed is a press release describing the bakeoff.
  44. ---------------------------------------------------------------------------
  45. Edwin Chow - edwin@wco.ftp.com
  46. FTP Software Inc.
  47.  
  48. ******************************************************************************
  49.  
  50.  
  51.                         Bakeoff Test Proposal Sheet
  52.                         ---------------------------
  53.  
  54. Name of Test:
  55. Submitted by:
  56. Phone Number:
  57. Company Name:
  58. Date:
  59.  
  60. RFC REQUIREMENT LEVEL
  61. (M)ust, (S)hould, m(A)y:
  62.  
  63. TCP/IP LAYER BEING TESTED
  64. (A)pplication, (T)ransport, (I)nternet, (L)ink:
  65.  
  66. TCP/IP Feature Being Tested (include RFC reference and page number if
  67. possible:
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74. Brief Description of Test:
  75.  
  76.  
  77.  
  78.  
  79.  
  80. Required Length of Test:
  81.  
  82. Does it requre any other equipment (Yes/No):
  83. If so, what and who will provide it:
  84.  
  85.  
  86.  
  87.  
  88. TEST SHOULD TAKE PLACE ON THE
  89. (S)table Net, (B)attle Net:
  90.  
  91. ****************************************************************************
  92.  
  93. Dated:                  December 8, 1992
  94.  
  95.                          THE  1993  TCP/IP  BAKE-OFF
  96.  
  97. After much thought and planning, and based on input gleaned from reading an
  98. Internet mailing list of the same name, a group of four companies has come
  99. up with a format for what they hope will the be the first of many multivendor 
  100. "TCP/IP Bake-Off" gatherings.
  101.  
  102. The first such get-together took place several years ago, when the protocol 
  103. was much younger.  Mr. Jon Postel, one of the original protocol architects, 
  104. worked on a few test meets in December of 1978, January of 1979, and April 
  105. of 1980.  Since then, apart from occasional multivendor networks at shows 
  106. such as UniForum, FCC and INTEROP, there has not been a great deal of 
  107. multivendor testing of the main TCP/IP protocol suite.
  108.  
  109. While there are groups who meet regularly to work with SNMP, NFS, and similar 
  110. standards, telnet, ftp and smtp - as well as TCP and IP themselves - are mostly
  111. neglected.  This is starting to show up in the fact that there are some 
  112. implementations currently available which are unable to successfully negotiate 
  113. even some of the more basic communications options, or keep network links 
  114. open when hard- or software anomalies occur.
  115.  
  116. FTP Software, TGV, Empirical Tools and Technology, and InterCon Systems have
  117. taken the example set by Jon Postel and his colleagues, and are building on 
  118. his ideas.  The "TCP/IP Bake-Off" was first announced publicly at the November 
  119. IETF Meeting in Washington DC.  Vendors of products with TCP/IP protocol 
  120. stacks are invited to come, in a spirit of intervendor cooperation, and assist 
  121. in providing network customers with the finest possible range of products 
  122. from which to choose.  As this is a first meeting, the number of participants 
  123. is being limited to between 25 and 30 manufacturers;  and with attendance 
  124. being on a first-come first-served basis, the ranks are filling rapidly.
  125.  
  126. This will be solely an engineering gathering.  Programmers from many 
  127. competing companies will be there to make sure that their code is able to 
  128. communicate with that of everyone else.  None of the information learned in 
  129. these meetings will go beyond the walls of the meeting venue.  Strict 
  130. guidelines will apply as to what information, and how much of it, is 
  131. disseminated from the Bake-Off;  and to ensure the security of data acquired 
  132. at the Bake-Off, all participants will be governed by a non-disclosure 
  133. agreement.
  134.  
  135. In the field of networking hardware and software, vendors are confronted with 
  136. a unique paradox:  in order to compete, they have to work together - because 
  137. any networking product that cannot communicate with another networking product 
  138. rather quickly loses its reason to exist....  For this reason, a gathering of 
  139. competitors on neutral ground ends up benefiting the consumer tremendously - 
  140. as well as the vendors themselves who are able to uncover potential problems 
  141. before their customers do, or who were able to return home secure in the 
  142. knowledge that their code is truly solid.
  143.  
  144. The actual results of this testing and coding will not be made public.  The 
  145. intent is that the participants, by repeatedly coming together, will know 
  146. that their products are good;  and that their customers, knowing that their 
  147. vendor is one of the active participants, will know that the products that 
  148. they are buying are among the most robust available.
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.