Editor's Note: These minutes have not been edited. Here are the minutes taken by Dave Horacek . Minutes of the OPS 2000 Working Group Meeting at IETF 38 Date: April 7, 1997 Time: 1300-1500. Session began with Erik Huizer reviewing the agenda as follows: 1. Opening 2. Charter, goals, objectives - to see if this is correct, and to see who wants to work on this - do we have the right expertise available 3. The list of protocols and implementation - to which this working group will restrict itself 4. Start inventory based on list -work down the list to see what the issues are with respect to Y2K 2a. Goals and Objectives ------------------------ The goal of the working group is to address the popular suggestion circulating externally that the Internet will crash in the year 2000 due to date problems. To achieve the goal, it is suggested that a summary of protocols addressed by RFCs should be developed and suggested solutions should be offered perhaps, but not necessarily, via an RFC. The general feeling among the area directors and others with specific knowledge is that although some implementations may be at risk due to a faulty application of a protocol, the protocols themselves are relatively immune from year 2000 problems by design, particularly the routing protocols. Question: Should the working group have a broader scope, for example how will PCs respond in the year 2000 problem? Responses: The working group should stick with the net. Question: How will someone be able to distinguish between Internet problems and PC problems? Question: Should the working group include implementation issues also? Responses: Only if the protocols are implemented and there are questions about them. Go protocol by protocol and indicate which ones may have a problem and identify problem with implemented protocol. Issue a note saying protocol is correct but implementation is wrong. Question: Should there be a set of test cases developed? For example, when you sort your mail by date, do the entries appear in the correct order? Question: Does the working group have an obligation to identify/announce broken implementations? Responses: This may result in improper publicity for some vendors and strained relationships for the working group. We could divide the protocols into levels such as protocols that are Y2K proof and those that are subject to problems. We can look for indications of problems on the mailing list. We could create a FAQ. Erik said he would submit a revised charter to the mailing list and take up with the area directors. 2b. Areas Of Expertise ---------------------- Question: Do we have enough expertise and the right kind of expertise? Will probably have to search for expertise from other areas. Need to list areas that need expertise and get 1-2 people to sign up. Question: Do we want 15 areas issuing status or a unified status? Responses: There will likely be 15 areas from which status will be summarized by the editors and issued to the mailing list. 3. List of Protocols -------------------- A list of protocols has been sent on the mailing list. The changes to the list are shown below along with the contact(s) responsible for initiating work in their respective areas. AREA Researchers ------------------------------------------------------------ e-mail Paul Hoffman and Ned Freed name serving Michael Patto and Robert Elz virtual terminal Chris Newman network man. Bob Moore information serv. Neal McBurnett and filetransfer news Erik Fair real time serv. audio/video etc. security serv. Philip Nesser Mike StJohns directory serv. Rick Wesson disk sharing Barbara Jennings autoconfig. Alex Latzko games and chat Jason Nealis NTP David Mills Routing Erik-Jan Bos Alex Latzko ip,tcp, ppp, etc Robert Elz Question: Are we limiting our scope to level 4 or should it go beyond? Responses: Scope should include as the base, RFC standard protocols and then look at what popular protocols are in use. Update MIME register to indicate potential MIME contents that may have a Y2K problem. Update IANA lists/processes in general. MIBs need to be certified. The area oversights indicate there should be no Y2K problems. NNTP - INN people are aware of a problem and are working on it. List servers should be subject to rules of RFC 822. Question: Should the working group be looking for other groups that are doing similar work? Responses: We can refer to them, but no need to seek them out. Question: Should we look at X.509? Question: Are there problems with ANS.1 Response: Non-IETf standards are in principle out of scope. If they are known to be used significantly on the Internet they may be included. Erik will liaise with Iso SC18 and SC21 to get info on expected problems in X.400 and X.500. Question: Is the SMI correct under SNMP? There once was a problem with calculating either the Universal date or the local date. 4. Start Inventory - ------------------ Analysis will initially be done on the 15 classes/area of protocols identified previously. Implementation modeling activities can also be discussed. There is no reason to reinvent a solution to a problem found. We will use a central mailing list for all areas. Area leads should: Indicate what kind of problem may exist or Clear protocol and Report to the mailing list Erik will send request to entire IETF list suggesting that if any one wants to contribute, please respond. A list of all protocols looked at will be developed. RFCs will be associated with protocols. A web page will be put together that keeps track of protocols looked at - - Alex Latzko volunteered to coordinate hosting. Question: Should we have a required section in RFCs for Y2K information? Responses: Probably not since the IESG will be monitoring for year 2000 compliance. We don't want year 2000 problems reintroduced into already stable protocols. Erik will send reminder to IETF chairs. Question: Should we contact other organizations (i.e., W3C) about Y2K issues in X.400, X.500, mail group, etc. Responses: Erik will contact ISO liaisons and the W3C. - -------------------------------------------------------------------- Minutes taken by Dave Horacek, Andersen Consulting .