NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Erik Huizer <Erik.Huizer@sec.nl>
Operations and Management Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uu.net>
Deirdre Kostick <kostick@qsun.att.com>
Scott Bradner <sob@harvard.edu>
General Discussion:2000@nic.surfnet.nl
To Subscribe: listserv@nic.surfnet.nl
In Body: subscribe 2000 <your name> in body
Archive:
According to the trade press billions of dollars will be spend the upcoming three years on the year 2000 problem, also called the millenium problem (though the third millenium will only start in 2001). This problem consists of the fact that many software packages and some protocols use a two digit field for the year in a date field. Most of the problems seem to be in administrative and financial programs, some of which have been written in archaic languages like Cobol. A lot of organizations are now starting to make an inventory of which software and tools they use will suffer from the millenium problem.
With the increasing popularity of the Internet, more and more organizations start to use the Internet as a serious business tool. This means that most organizations will want to analyze the millenium problems due to the use of Internet protocols and popular Internet software. In the trade press the first articles suggest that the Internet will collapse at midnight the 31st of December 1999.
To counter these suggestions (that are obviously wrong) and to avoid that all over the Internet people will redo the same inventory over and over again the WG is to make an inventory of all important Internet protocols and their most popular implementations with respect to the millenium problem. Only software and protocols directly related to the Internet will be considered.
The inventory will be published as an informational RFC. The RFC will contain:
· Description of the year 2000 problems and when they will occur · Summary of possible solutions and timelines for those solutions · Inventory of the year 2000 problem in the most popular Internet protocols and their most popular implementations · Suggested solutions to the problems noted in the inventory · A disclaimer that the RFC does not pretend to be complete and that the proposed solutions should be tested before being relied upon (this for the US readers).
The WG will only meet once (in Memphis, April 1997), most of the work will be done via the mailing list.
Goals and Milestones:
|
Feb 97 |
|
Begin collecting inventory. |
|
Sep 97 |
|
Submit Internet-Draft to IESG for publication as an Informational RFC. |
Minutes of the OPS 2000 Working Group.
Reported by: Dave Horacek, Andersen Consulting <dhoracek@swbell.net>
The session began with Erik Huizer reviewing the agenda as follows:
2. Charter, goals, objectives
- Verify if this is correct and 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
- Review the list to see what the issues are with respect to Y2K
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 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.
Should the working group have a broader scope, for example how will PCs respond to the year 2000 problem?
The working group should stick with the net.
How will someone be able to distinguish between internet problems and PC problems?
Should the working group include implementation issues also?
Only if the protocols are implemented and there are questions about them.
Evaluate protocol by protocol and indicate which ones may have a problem and identify the problem with an implemented protocol.
Issue a note saying protocol is correct but implementation is wrong.
Should there be a set of test cases developed? For example, when mail is sorted by date, do the entries appear in the correct order?
Does the working group have an obligation to identify/announce broken implementations?
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.
Erik said he would submit a revised charter to the mailing list and follow-up with the area directors.
Do we have enough expertise and the right kind of expertise?
We will probably have to search for expertise from other areas. Need to list areas that need expertise and get one or two people to sign up.
Do we want 15 areas issuing status or a unified status?
There will likely be 15 areas from which status will be summarized by the editors and issued to the mailing list.
A list of protocols has been sent to the mailing list. The changes to the list are shown below along with the contact(s) responsible for initiating work in their respective areas.
------------------------------------------------------------
e-mail Paul Hoffman <phoffman@imc.org>
Ned Freed <freed@innosoft.com>
name serving Michael Patto <map@pobox.com>
Robert Elz <kre@munnari.oz.au>
virtual terminal Chris Newman <Chris.Newman@innosoft.com>
network man. Bob Moore <remoore@ralvm6.vnet.ibm.com>
information serv. Neal McBurnett <nealmcb@bell-labs.com>
security serv. Philip Nesser <pjnesser@martigny.ai.mit.edu>
Mike StJohns <stjohns@home.net>
directory serv. Rick Wesson <rick@organic.com>
disk sharing Barbara Jennings <jennings@sandia.gov>
autoconfig. Alex Latzko <latzko@hardees.rutgers.edu>
games and chat Jason Nealis <nealis@erols.com>
NTP David Mills <mills@udel.edu>
Routing Erik-Jan Bos <bos@surfnet.nl>
Alex Latzko <latzko@hardees.rutgers.edu>
ip, tcp, ppp, etc Robert Elz <kre@munnari.oz.au>
Are we limiting our scope to level four or should it go beyond?
As the base, the scope should include 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.
Should the working group be looking for other groups that are doing similar work?
We can refer to them, but need not seek them out.
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.
Is the SMI correct under SNMP? There once was a problem with calculating either the universal date or the local date.
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 a request to the entire IETF list suggesting that if anyone 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, and Alex Latzko volunteered to coordinate hosting.
Should we have a required section in RFCs for Y2K information?
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 a reminder to IETF chairs.
Should we contact other organizations (i.e., W3C) about Y2K issues in X.400, X.500, mail group, etc.?
Erik will contact ISO liaisons and the W3C.