home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 2000 / 2000-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  8KB  |  425 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. Here are the minutes taken by  Dave Horacek <dhoracek@swbell.net>.
  5.  
  6. Minutes of the OPS 2000 Working Group Meeting at IETF 38
  7.  
  8. Date: April 7, 1997
  9.  
  10. Time: 1300-1500.
  11.  
  12. Session began with Erik Huizer reviewing the agenda as follows:
  13.  
  14.   1. Opening
  15.  
  16.   2. Charter, goals, objectives
  17.  
  18.     - to see if this is correct, and to see who wants to work on this
  19.  
  20.     - do we have the right expertise available
  21.  
  22.   3. The list of protocols and implementation
  23.  
  24.     - to which this working group will restrict itself
  25.  
  26.   4. Start inventory based on list
  27.  
  28.     -work down the list to see what the issues are with respect to
  29.  
  30.      Y2K
  31.  
  32. 2a. Goals and Objectives
  33.  
  34. ------------------------
  35.  
  36. The goal of the working group is to address the popular suggestion
  37.  
  38. circulating externally that the Internet will crash in the year 2000 due
  39.  
  40. to date problems. To achieve the goal, it is suggested that a summary of
  41.  
  42. protocols addressed by RFCs should be developed and suggested solutions
  43.  
  44. should be offered perhaps, but not necessarily, via an RFC.
  45.  
  46.  
  47.  
  48. The general feeling among the area directors and others with specific
  49.  
  50. knowledge is that although some implementations may be at risk due to a
  51.  
  52. faulty application of a protocol, the protocols themselves are
  53.  
  54. relatively immune from year 2000 problems by design, particularly the
  55.  
  56. routing protocols.
  57.  
  58.  
  59.  
  60. Question:
  61.  
  62. Should the working group have a broader scope, for example how will PCs
  63.  
  64. respond in the year 2000 problem?
  65.  
  66.  
  67. Responses:
  68.  
  69. The working group should stick with the net.
  70.  
  71.  
  72. Question:
  73.  
  74. How will someone be able to distinguish between Internet problems and PC
  75.  
  76. problems?
  77.  
  78.  
  79. Question:
  80.  
  81. Should the working group include implementation issues also?
  82.  
  83.  
  84. Responses:
  85.  
  86. Only if the protocols are implemented and there are questions about
  87.  
  88. them.
  89.  
  90.  
  91. Go protocol by protocol and indicate which ones may have a problem and
  92.  
  93. identify problem with implemented protocol.
  94.  
  95.  
  96. Issue a note saying protocol is correct but implementation is wrong.
  97.  
  98.  
  99. Question:
  100.  
  101. Should there be a set of test cases developed? For example, when you
  102.  
  103. sort your mail by date, do the entries appear in the correct order?
  104.  
  105.  
  106. Question:
  107.  
  108. Does the working group have an obligation to identify/announce broken
  109.  
  110. implementations?
  111.  
  112.  
  113. Responses:
  114.  
  115. This may result in improper publicity for some vendors and strained
  116.  
  117. relationships for the working group.
  118.  
  119.  
  120. We could divide the protocols into levels such as protocols that are Y2K
  121.  
  122. proof and those that are subject to problems.
  123.  
  124.  
  125. We can look for indications of problems on the mailing list.
  126.  
  127.  
  128. We could create a FAQ.
  129.  
  130.  
  131. Erik said he would submit a revised charter to the mailing list and
  132.  
  133. take up with the area directors.
  134.  
  135.  
  136. 2b. Areas Of Expertise
  137.  
  138. ----------------------
  139.  
  140. Question:
  141.  
  142. Do we have enough expertise and the right kind of expertise?
  143.  
  144.  
  145. Will probably have to search for expertise from other areas. Need to
  146.  
  147. list areas that need expertise and get 1-2 people to sign up.
  148.  
  149.  
  150. Question:
  151.  
  152. Do we want 15 areas issuing status or a unified status?
  153.  
  154. Responses:
  155.  
  156. There will likely be 15 areas from which status will be summarized by
  157.  
  158. the editors and issued to the mailing list.
  159.  
  160.  
  161. 3. List of Protocols
  162.  
  163. --------------------
  164.  
  165. A list of protocols has been sent on the mailing list. The changes to
  166.  
  167. the list are shown below along with the contact(s) responsible for
  168.  
  169. initiating work in their respective areas.
  170.  
  171.  
  172.  
  173. AREA                    Researchers
  174.  
  175. ------------------------------------------------------------
  176.  
  177. e-mail                  Paul Hoffman <phoffman@imc.org> and
  178.  
  179.                         Ned Freed <freed@innosoft.com>
  180.  
  181.  
  182.  
  183. name serving            Michael Patto <map@pobox.com> and
  184.  
  185.                         Robert Elz <kre@munnari.oz.au>
  186.  
  187.  
  188.  
  189. virtual terminal        Chris Newman <Chris.Newman@innosoft.com>
  190.  
  191.  
  192.  
  193. network man.            Bob Moore <remoore@ralvm6.vnet.ibm.com>
  194.  
  195.  
  196.  
  197. information serv.       Neal McBurnett <nealmcb@bell-labs.com>
  198.  
  199. and filetransfer
  200.  
  201.  
  202.  
  203. news                    Erik Fair <?>
  204.  
  205.  
  206.  
  207. real time serv.         <tbd>
  208.  
  209. audio/video etc.
  210.  
  211.  
  212.  
  213. security serv.          Philip Nesser <pjnesser@martigny.ai.mit.edu>
  214.  
  215.                         Mike StJohns <stjohns@home.net>
  216.  
  217.  
  218.  
  219. directory serv.         Rick Wesson <rick@organic.com>
  220.  
  221.  
  222.  
  223. disk sharing            Barbara Jennings <jennings@sandia.gov>
  224.  
  225.  
  226.  
  227. autoconfig.             Alex Latzko <latzko@hardees.rutgers.edu>
  228.  
  229.  
  230.  
  231. games and chat          Jason Nealis <nealis@erols.com>
  232.  
  233.  
  234.  
  235. NTP                     David Mills <mills@udel.edu>
  236.  
  237.  
  238.  
  239. Routing                 Erik-Jan Bos <bos@surfnet.nl>
  240.  
  241.                         Alex Latzko <latzko@hardees.rutgers.edu>
  242.  
  243.  
  244.  
  245. ip,tcp, ppp, etc        Robert Elz <kre@munnari.oz.au>
  246.  
  247.  
  248.  
  249.  
  250.  
  251. Question:
  252.  
  253. Are we limiting our scope to level 4 or should it go beyond?
  254.  
  255.  
  256.  
  257. Responses:
  258.  
  259. Scope should include as the base, RFC standard protocols and then look
  260.  
  261. at what popular protocols are in use.
  262.  
  263.  
  264.  
  265. Update MIME register to indicate potential MIME contents that may have a
  266.  
  267. Y2K problem.
  268.  
  269.  
  270.  
  271. Update IANA lists/processes in general.
  272.  
  273.  
  274.  
  275. MIBs need to be certified. The area oversights indicate there should be
  276.  
  277. no Y2K problems.
  278.  
  279.  
  280.  
  281. NNTP - INN people are aware of a problem and are working on it.
  282.  
  283.  
  284.  
  285. List servers should be subject to rules of RFC 822.
  286.  
  287.  
  288.  
  289. Question:
  290.  
  291. Should the working group be looking for other groups that are doing
  292.  
  293. similar work?
  294.  
  295.  
  296.  
  297. Responses:
  298.  
  299. We can refer to them, but no need to seek them out.
  300.  
  301.  
  302.  
  303. Question:
  304.  
  305. Should we look at X.509?
  306.  
  307.  
  308.  
  309. Question:
  310.  
  311. Are there problems with ANS.1
  312.  
  313.  
  314.  
  315. Response:
  316.  
  317. Non-IETf standards are in principle out of scope. If they are known to
  318.  
  319. be used significantly on the Internet they may be included. Erik will
  320.  
  321. liaise with Iso SC18 and SC21 to get info on expected problems in X.400
  322.  
  323. and X.500.
  324.  
  325.  
  326.  
  327. Question:
  328.  
  329. Is the SMI correct under SNMP? There once was a problem with calculating
  330.  
  331. either the Universal date or the local date.
  332.  
  333.  
  334.  
  335. 4. Start Inventory
  336.  
  337. - ------------------
  338.  
  339. Analysis will initially be done on the 15 classes/area of protocols
  340.  
  341. identified previously.
  342.  
  343.  
  344.  
  345. Implementation modeling activities can also be discussed. There is no
  346.  
  347. reason to reinvent a solution to a problem found.
  348.  
  349.  
  350.  
  351. We will use a central mailing list for all areas. Area leads should:
  352.  
  353.   Indicate what kind of problem may exist or
  354.  
  355.   Clear protocol and
  356.  
  357.   Report to the mailing list
  358.  
  359.  
  360.  
  361. Erik will send request to entire IETF list suggesting that if any one
  362.  
  363. wants to contribute, please respond.
  364.  
  365.  
  366.  
  367. A list of all protocols looked at will be developed.
  368.  
  369.  
  370.  
  371. RFCs will be associated with protocols.
  372.  
  373.  
  374.  
  375. A web page will be put together that keeps track of protocols looked at
  376.  
  377. - - Alex Latzko volunteered to coordinate hosting.
  378.  
  379.  
  380.  
  381. Question:
  382.  
  383. Should we have a required section in RFCs for Y2K information?
  384.  
  385.  
  386.  
  387. Responses:
  388.  
  389. Probably not since the IESG will be monitoring for year 2000 compliance.
  390.  
  391.  
  392.  
  393. We don't want year 2000 problems reintroduced into already stable
  394.  
  395. protocols.
  396.  
  397.  
  398.  
  399. Erik will send reminder to IETF chairs.
  400.  
  401.  
  402.  
  403. Question:
  404.  
  405. Should we contact other organizations (i.e., W3C) about Y2K issues in
  406.  
  407. X.400, X.500, mail group, etc.
  408.  
  409.  
  410.  
  411. Responses:
  412.  
  413. Erik will contact ISO liaisons and the W3C.
  414.  
  415.  
  416.  
  417. - --------------------------------------------------------------------
  418.  
  419. Minutes taken by Dave Horacek, Andersen Consulting
  420.  
  421. .
  422.  
  423.  
  424.  
  425.