draft-ietf-2000-issue-02.txt   draft-ietf-2000-issue-03.txt 
Network Working Group Philip J. Nesser II Network Working Group Philip J. Nesser II
Editor draft-ietf-2000-issue-03.txt Nesser & Nesser Consulting
draft-ietf-2000-issue-02.txt Nesser & Nesser Consulting The Internet and the Millennium Problem (Year 2000)
The Internet and the Millenium Problem (Year 2000)
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
skipping to change at line 29 skipping to change at page 1, line 28
Drafts as reference material or to cite them other than as a "working Drafts as reference material or to cite them other than as a "working
draft" or "work in progress". draft" or "work in progress".
Please check the I-D abstract listing contained in each Internet Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other Draft directory to learn the current status of this or any other
Internet Draft. Internet Draft.
Abstract Abstract
The Year 2000 Working Group(WG) has conducted an investigation into The Year 2000 Working Group(WG) has conducted an investigation into
the millenium problem as it regards Internet related protocols. the millennium problem as it regards Internet related protocols. This
This investigation only targeted the protocols as documented in the investigation only targeted the protocols as documented in the Request
Request For Comments Series (RFCs). This investigation discovered For Comments Series (RFCs). This investigation discovered little
little reason for concern with regards to the functionality of the reason for concern with regards to the functionality of the protocols.
protocols. A few minor cases of older implementations still using A few minor cases of older implementations still using two digit years
two digit years (ala RFC 850) were discovered, but almost all (ala RFC 850) were discovered, but almost all Internet protocols were
Internet protocols were given a clean bill of health. Several cases given a clean bill of health. Several cases of "period" problems were
of ''period'' problems were discussed where a time field would ''roll discovered, where a time field would "roll over" as the size of field
over'' as the size of field was reached. In particular, there are was reached. In particular, there are several protocols, which have
several protocols, which have 32 bit, signed integer representations 32 bit, signed integer representations of the number of seconds since
of the number of seconds since January 1, 1970 which will turn January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT
negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols 2038. Areas whose protocols will be effected by such problems have
will be effected by such problems have been notified so that new been notified so that new revisions will remove this limitation.
revisions will remove this limitation.
1.0 Introduction 1. Introduction
According to the trade press billions of dollars will be spend the According to the trade press billions of dollars will be spend the
upcoming three years on the year 2000 problem, also called the upcoming years on the year 2000 problem, also called the millennium
millenium problem (though the third millenium will only start in problem (though the third millennium will really start in 2001). This
2001). This problem consists of the fact that many software packages problem consists of the fact that many software packages and some
and some protocols use a two-digit field for the year in a date protocols use a two-digit field for the year in a date field. Most of
field. Most of the problems seem to be in administrative and the problems seem to be in administrative and financial programs, or
financial programs, or in the hardcoded microcomputers found in in the hardcoded microcomputers found in electronic equipment. A lot
electronic equipment. A lot of organizations are now starting to of organizations are now starting to make an inventory of which
make an inventory of which software and tools they use will suffer software and tools they use will suffer from the millennium problem.
from the millenium problem.
With the increasing popularity of the Internet, more and more With the increasing popularity of the Internet, more and more
organizations start to use the Internet as a serious business tool. organizations use the Internet as a serious business tool. This means
This means that most organizations will want to analyze the millenium that most organizations will want to analyze the millennium problems
problems due to the use of Internet protocols and popular Internet due to the use of Internet protocols and popular Internet software. In
software. In the trade press the first articles suggest that the the trade press the first articles suggest that the Internet will
Internet will collapse at midnight the 31st of December 1999. collapse at midnight the 31st of December 1999.
To counter these suggestions (that are obviously wrong) and to avoid To counter these suggestions, and to avoid having countless companies
that all over the Internet people will redo the same inventory over and redo the same investigation, this effort was undertaken by the IETF.
over again the WG is to make an inventory of all important Internet The Year 2000 WG has made an inventory of all-important Internet
protocols and their most popular implementations with respect to the protocols that have been documented in the Request for Comments (RFC)
millenium problem. Only software and protocols directly related to the series. Only protocols directly related to the Internet will be
Internet will be considered. considered.
The editor of this document would like to acknowledge the critical The editor of this document would like to acknowledge the critical
contributions of the follow for direct performance of research and the contributions of the follow for direct performance of research and the
provision of text: Alex Latzko, Robert Elz, Erik Huizer, Gillian provision of text: Alex Latzko, Robert Elz, Erik Huizer, Gillian
Greenwood, Barbara Jennings, R.E. (Robert) Moore, David Mills, Lynn Greenwood, Barbara Jennings, R.E. (Robert) Moore, David Mills, Lynn
Kubinec, Michael Patton, Chris Newman, Erik-Jan Bos, Paul Hoffman, Kubinec, Michael Patton, Chris Newman, Erik-Jan Bos, Paul Hoffman, and
and Rick H. Wesson. The pace with which this group has operated has Rick H. Wesson. The pace with which this group has operated has only
only been achievable by the intimate familiarity of the contributors been achievable by the intimate familiarity of the contributors with
with the protocols and ready access to the collective knowledge of the the protocols and ready access to the collective knowledge of the
IETF. IETF.
Disclaimer 2. Disclaimer
This RFC is not complete. It is an effort to analyze the Y2K impact on This RFC is not complete. It is an effort to analyze the Y2K impact
hundreds of protocols but is likely to have missed some protocols and on hundreds of protocols but is likely to have missed some protocols
misunderstood others. Organizations should not attempt to claim any and misunderstood others. Organizations should not attempt to claim
legitimacy or approval for any particular protocol based on this any legitimacy or approval for any particular protocol based on this
document. The efforts have concentrated on the identification of document. The efforts have concentrated on the identification of
potential problems, rather than solutions to any of the problems that potential problems, rather than solutions to any of the problems that
have been identified. Any proposed solutions are only that: proposed. have been identified. Any proposed solutions are only that: proposed.
A formal engineering review should take place before any solution is A formal engineering review should take place before any solution is
adopted. adopted.
Methodology It should also be noted that the research was performd on RFCs 1
through 2128. At that time the IESG was charted with not allowing
any new RFCs to be published that had any Year 2000 issues. Since
that cutoff time there has been work to correct issues discovered by
this Working Group. In particular, RWhois as documented by RFC 1714
has been updated to fix the problems found. RFC 2167 now documents
a fixed version of the RWhois protocol. The work of this group was
to look backwards, and hence new RFC's which supplant the old are
expected to make the information in this RFC obsolete. The work of
this group will truly be complete when this document is completely
obsolete.
A number of people have suggested looking into other "special" dates.
For example, the first leap year, the first "double digit" day
(January 10, 2000), January 1, 2001, etc. There is not one place
where days have been used in the protocols defined by the RFC series
so there is little reason to believe that any of these special dates
will have any impact.
3. Summary of Year 2000 Problems
Here is a brief description of all the Millenium issues discovered
in the course of this research. Note that many of the RFCs are
unclear on the issue. They mandate the use of UTCTime but do not
specify whether the two-digit or four-digit year representation
should be used.
3.1 "Directory Services"
rfc1274.txt - References UTC date/time
rfc1276.txt - References UTC date/time for version control.
rfc1488.txt - References UTC Time as printable strings.
rfc1608.txt - Refers to uTCTimeSyntax
rfc1609.txt - Refers to uTCTimeSyntax
rfc1778.txt - Refers to uTCTimeSyntax
3.2 "Information Services and File Transfer"
HTTP 1.1, as defined in RFC 2068, requires all newly generated date
stamps to conform to RFC 1123 date formats which are Year 2000
compliant, but it also requires acceptance of the older non-compliant
RFC850 formats. Some specific recommendations have been passed to
the HTTP WG.
HTML 2.0, as defined in RFC 1866, could allow a very subtle Year 2000
problem, but once again this recommendation has been passed on the
HTML WG.
RFC 1778 on String Representations of Standard Attribute Syntax's
define UTC Time in Section 2.21 and uses that definition in Section
2.25 on User Certificates. Since UTC Time is being used, there is a
potential millenium issue.
RFC 1440 on SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
defines an optional DATE command in Section 5 of the form mm/dd/yy
which is subject to millenium issues.
3.3 "Electronic Mail"
After reviewing all mail-related RFCs, it was discovered that while
some obsolete standards required two-digit years, all currently used
standards require four-digit years and are thus not prone to typical
Year 2000 problems.
RFCs 821 and 822, the main basis for SMTP mail exchange and message
format, originally required two-digit years. However, both of these
RFCs were later modified by RFC 1123 in 1989, which strongly
recommended 4-digit years.
3.4 "Name Serving"
While not a protocol issue, there is a common habit of writing serial
numbers for DNS zone files in the form YYXXXXXX. The only real
requirement on the serial numbers is that they be increasing (see
RFC 1982 for a complete description) and a change from 99XXXXXX to
00XXXXXX cause a failure. See the section on "Name Serving" for a
complete description of the issues.
3.5 "Network Management"
Versions 1 & 2 of SNMP specify the use of UTCTime. This could be an
issue depending on implementations.
3.6 "Network News"
There does exist a problem in both NNTP, RFC 977, and the Usenet News
Message Format, RFC 10336. They both specify two-digit year format.
A working group has been formed to update the network news protocols
in general, and addressing this problem is on their list of work
items.
3.7 "Real-Time Services"
A Year 2000 problem does occur in the Simple Network Paging Protocol,
versions 2 & 3. Both define a HOLDuntil option which uses a
YYMMDDHHMMSS+/-GMT field. Version 3 also defines a MSTAtus command,
which is required to store,dates and times as YYMMDDHHMMSS+/-GMT.
There is a small Year 2000 issue in RFC 1786 on the Representation of
IP Routing Policies in the ripe-81++ Routing Registry. In Appendices
C the "changed" object parameter defines a format of <email-address>
YYMMDD, and similarly in Appendix D "withdrawn" object identifier has
he format of YYMMDD. Since these are only identifiers there should be
little operational impact. Some application software may need to be
modified.
3.8 "Security"
RFC 1507 on Distributed Authentication Security Services (DASS)
use UTCTime. Because of the imprecision of the UTC time
definition there could be problems with this protocol.
RFCs 1421-1424 specifies that PEM uses UTC time formats which could
have a Millenium.
4. Summary of Other "Periodicity" Problems
By far, the largest area of "period" problems occurs in the year
2038. Many protocols use a 32-bit field to record the number of
seconds since January 1, 1970.
4.1 "Name Serivces"
DNS Security uses 32-bit timestamps which will roll over in 2038.
This issue has been refered to the appropriate Working Group so that
the details of rollover can be established.
4.2 "Routing"
IDPR suffers from the classic Year 2038 problem, by having a timestamp
counter which rolls over at that time.
5. Suggested Solutions
The real solution to the problem is to use 4 digit year fields for
applications and hardware systems. For counters that key off of a
certain time (January 1, 1970 for example) need to either: define a
wrapping solution, or to define a larger number space (greater than
32-bits), or to make more efficient use of the 32-bit space. A
trivial example might be to use to lower 12 bits to represent the
number of seconds in a day, and use next upper 19 bits to represent
days since January 1, 1970, and the set the highest bit to 1 so that
it is always larger than the current number of seconds since January
1, 1970. This would provide a unique counter until May 28, 3406.
(There are some drawbacks to this example, the most obvious being
the counter is no longer monotonically increasing. It was only
included as a simple example, not a serious suggestion.)
However, it will be impossible to completely replace currently
deployed systems, so solutions for handling problems are in order.
5.1 Fixed Solution
A number of organizations and groups have suggested a fixed solution
to the problem of two digit years. Given a two-digit year YY, if YY
is greater than or equal to 50, the year shall be interpreted as 19YY;
and where YY is less than 50, the year shall be intrepreted as 20YY.
While a simple and straightforward solution, it only pushes the
problem off 40 to 50 years, until the artificially generated Year
2050 problem needs to be addressed. However, it is easy to implement
and deploy, so it might be the most commonly adopted solution.
5.2 Sliding Window
Another solution is the "sliding window" approach. In this approach,
some value N is selected, and any two digit year that is less than or
equal to the current two digit year plus N is considered the future,
while any other two digit year is considered in the past.
For example, choosing N equal to 10, If the current year is 2012, and
I get a two digit year that is any of 12, 13, 14, 15, 16, 17, 18, 19,
20, 21 or 22, assume it is 20YY (i.e. the future), otherwise consider
it to be in the past(1923-1999, 2000-2011).
This solution has two advantages. First, no new fixed year problems
are introduced. Second, different applications and protocols could
choose different values of N. The drawback is that this solution is
harder to implement, and to work well the value of N will need to be
constant across different implementations.
6. Methodology
The first task was dividing the types of RFC's into logical groups The first task was dividing the types of RFC's into logical groups
rather than the strict numeric publishing order. Fifteen specific rather than the strict numeric publishing order. Sixteen specific
areas were identified. They are: "Autoconfiguration" , "Directory areas were identified. They are: "Autoconfiguration" , "Directory
Services", "Disk Sharing", "Games and Chat" ,"Information Services & Services", "Disk Sharing", "Games and Chat" ,"Information Services &
File Transfer", "Network & Transport Layer", "Electronic Mail", "NTP", File Transfer", "Network & Transport Layer", "Electronic Mail", "NTP",
Name Serving", "Network Management", "News", "Real Time Services", Name Serving", "Network Management", "News", "Real Time Services",
"Routing", "Security", and "Virtual Terminal". In addition to these "Routing", "Security", "Virtual Terminal", and "Other". In addition
categories many hundreds of RFC's were immediately eliminated because to these categories, many hundreds of RFC's were immediately eliminated
of the type of content. That is not to say that all Informational based on content. That is not to say that all Informational RFC's were
RFC's were not considered, many did contain some technical content or not considered, many did contain some technical content or overview
overview which demanded scrutiny. whichdemanded scrutiny.
Each area was assigned to a team for investigation. Although each team Each area was assigned to a team for investigation. Although each
used whatever additional investigation techniques which seemed team used whatever additional investigation techniques which seemed
appropriate (including completely reading each RFC, and in some cases appropriate (including completely reading each RFC, and in some cases
the source code for the reference implementation) at minimum each team the source code for the reference implementation) at minimum each team
used an automatic scanning system to search for the following items used an automatic scanning system to search for the following items
(case insensitively) in each RFC: (case insensitively) in each RFC:
- date - date
- GMT - GMT
- UTCTime - UTCTime
- year - year
- yy (that is not part of yyyy) - yy (that is not part of yyyy)
- two-digit, 2-digit, 2digit - two-digit, 2-digit, 2digit
- century - century
- 1900 & 2000 - 1900 & 2000
Note that all of these strings except "UTCTime" may occur in Note that all of these strings except "UTCTime" may occur in
conjunction with a date format that accommodates the Year 2000 conjunction with a date format that accommodates the Year 2000
crossing, as well as with one that does not. So "hits" on these string crossing, as well as with one that does not. So "hits" on these
do not necessarily indicate Year 2000 problems: they simply identify string do not necessarily indicate Year 2000 problems: they simply
elements that need to be examined. identify elements that need to be examined.
After the documents were scanned, therefore, each "hit" was examined After the documents were scanned, therefore, each "hit" was examined
individually. Those that cause no Year 2000 problems (e.g., those that individually. Those that cause no Year 2000 problems (e.g., those
encode the year as a two-byte integer, or as a four-character display that encode the year as a two-byte integer, or as a four-character
string) are not discussed here. Those that do cause Year 2000 problems display string) are not discussed here. Those that do cause Year 2000
are identified in this document, and the nature and impact of the problems are identified in this document, and the nature and impact of
problems they cause are described. the problems they cause are described.
Types of Year 2000 Problems
Summary of Solutions
2.0 Autoconfiguration 7. Autoconfiguration
Summary 7.1 Summary
The RFC's which were categorized into this group were primarily the The RFC's which were categorized into this group were primarily the
BOOT Protocol (BOOTP) and the Dynamic Host Configuration Protocol BOOT Protocol (BOOTP) and the Dynamic Host Configuration Protocol
(DHCP) for both IP version four and six. (DHCP) for both IP version four and six.
Examination of the BOOTP protocols and most popular implementations Examination of the BOOTP protocols and most popular implementations
show no year 2000 problems. All times are references as 32 bit show no year 2000 problems. All times are references as 32 bit
integers in seconds of UTC time. An investigation of all DHCP and the integers in seconds of UTC time. An investigation of all DHCP and the
IPv6 autoconfiguration mechanisms produced no year 2000 problems. All IPv6 Autoconfiguration mechanisms produced no year 2000 problems. All
references to time, in particular lease lengths, are 32 bit integers in references to time, in particular lease lengths, are 32 bit integers
seconds, allowing lease times of well over 100 years. in seconds, allowing lease times of well over 100 years.
Specifics 7.2 Specifics
The following RFCs were examined for possible millenium problems: 906, The following RFCs were examined for possible millennium problems:
951, 1048, 1084, 1395, 1497, 1531, 1532, 1533, 1534, 1541, 1542, 1970, & 906, 951, 1048, 1084, 1395, 1497, 1531, 1532, 1533, 1534, 1541, 1542,
1971. RFC 951's only reference to time or dates is a two byte filed in 1970, & 1971. RFC 951's only reference to time or dates is a two-byte
the packet which is number of second since the hosts was booted. RFC's field in the packet, which is number of second since the hosts, was
1048, 1084, 1395, 1497, 1531, & 1532 have either no references to dates booted. RFC's 1048, 1084, 1395, 1497, 1531, & 1532 have either no
and time, or they are the same as the RFCs which obsoleted them discuessed references to dates and time, or they are the same as the RFCs, which
in the next paragraph. obsoleted them, discussed in the next paragraph.
RFC 1533 enumerates all the known DHCP field types and a number of these have RFC 1533 enumerates all the known DHCP field types and a number of
to do with time. Section 3.4 defines a "Time Offset" field which specifies these have to do with time. Section 3.4 defines a "Time Offset" field
the offset of the clients subnet in seconds from UTC. This 4 byte field which specifies the offset of the clients subnet in seconds from UTC.
has no millenium issues. Section 9.2 defines the IP Address Lease Time field This 4 byte field has no millennium issues. Section 9.2 defines the
which is used by clients to request a specific lease time. This four byte IP Address Lease Time field which is used by clients to request a
field is an unsigned integer containing a number of seconds. Section 9.9 specific lease time. This four byte field is an unsigned integer
defines a Renewal Time Value field, Section 9.10 defines a Rebinding Time Value, containing a number of seconds. Section 9.9 defines a Renewal Time
both of which are similarly 32 bit fields which have no millenium issues. Value field, Section 9.10 defines a Rebinding Time Value, both of
which are similarly 32 bit fields, which have no millennium issues.
RFC 1534 has no references to times or dates. RFC 1534 has no references to times or dates.
RFC 1541 has two mentions of times/dates. The first is the "secs" field which, RFC 1541 has two mentions of times/dates. The first is the "secs"
similarly to RFC 951, is a 16 bit field for the number of seconds since the host field which, similarly to RFC 951, is a 16-bit field for the number of
has booted. There is also a discussion in section 3.3 about "Interpretation and seconds since the host has booted. There is also a discussion in
Representation of Time Values" which while clearly states that there is no section 3.3 about "Interpretation and Representation of Time Values"
millenium or period problems. which while clearly states that there is no millennium or period
problems.
RFC 1542 also references the "secs" field mentioned previously. RFC 1542 also references the "secs" field mentioned previously.
"Router Advertisment Message Format" the following fields are defined: Router RFC 1970 mentions a number of variables, which are time related. In
Lifetime, Reachable Time, & Retrans Timer. In section 4.6.2 "Prefix Information" section 4.2 "Router Advertisement Message Format" the following fields
the following are defined: Valid Lifetime, & Prefered Lifetime. In section are defined: Router Lifetime, Reachable Time, & Retrans Timer. In
6.2.1 "Router Configuration Variables the following are defined: MaxRtrAdvInterval, section 4.6.2 "Prefix Information" the following are defined: Valid
MinRtrAdvInterval, AdvReachableTime, AdvRetransTimer, AdvDefaultLifetime, Lifetime, & Preferred Lifetime. In section 6.2.1 "Router
AdvValidLifetime, & AdvPreferredLifetime. All of these fields specify counters Configuration Variables the following are defined: MaxRtrAdvInterval,
of some sort which have no millenium or periodicity problems. MinRtrAdvInterval, AdvReachableTime, AdvRetransTimer,
AdvDefaultLifetime, AdvValidLifetime, & AdvPreferredLifetime. All of
these fields specify counters of some sort which have no millennium or
periodicity problems.
RFC 1971 has some discussion of preferred lifetimes, depreciated lifetimes and RFC 1971 has some discussion of preferred lifetimes, depreciated
valide lifetimes of leases, but only discusses them in an expository way. lifetimes and valid lifetimes of leases, but only discusses them in an
expository way.
3.0 Directory Services 8. Directory Services
Summary 8.1 Summary
The RFC's which were categorized into this group were primarily X.500 The RFC's which were categorized into this group were primarily X.500
related RFC's, Whois, Rwhois, Whois++, and the Lightweight Directory related RFC's, Whois, Rwhois, Whois++, and the Lightweight Directory
Access Protocol (LDAP). Access Protocol (LDAP).
Upon review of the Directory Services related RFC's, no serious year Upon review of the Directory Services related RFC's, no serious year
2000 problems were discovered. Some minor issues were noted and 2000 problems were discovered. Some minor issues were noted and
explained below in the specifics portion of this section. explained below in the specific portion of this section.
Specifics 8.2 Specifics
RFCs that mentioned UTC Time or made reference to uTCTimeSyntax could RFCs that mentioned UTC Time or made reference to uTCTimeSyntax could
fail to be Y2K compliant. These should be updated to specify the fail to be Y2K compliant. These should be updated to specify the four
four year version of uTCTimeSyntax rather than giving the option of year version of uTCTimeSyntax rather than giving the option of using a
using a two year date representation. The following RFCs fall into this two-year date representation. The following RFCs fall into this
category: category:
rfc1274.txt - References UTC date/time rfc1274.txt - References UTC date/time
rfc1276.txt - References UTC date/time for version control. rfc1276.txt - References UTC date/time for version control.
rfc1488.txt - References UTC Time as printable strings. rfc1488.txt - References UTC Time as printable strings.
rfc1608.txt - Refers to uTCTimeSyntax rfc1608.txt - Refers to uTCTimeSyntax
rfc1609.txt - Refers to uTCTimeSyntax rfc1609.txt - Refers to uTCTimeSyntax
rfc1778.txt - Refers to uTCTimeSyntax rfc1778.txt - Refers to uTCTimeSyntax
Two RFC's have unusual date specifications and specify their own date Two RFC's have unusual date specifications and specify their own date
format. Both of these support Y2K compliant dates. format. Both of these support Y2K compliant dates.
RFC1714 (RWhois) specifies date formats that are not Y2K compliant, RFC1714 (RWhois) specifies date formats that are not Y2K compliant,
but it also support dates that are. Implementers of the RWhois but it also supports dates that are. Implementers of the RWhois
protocol should only use the %MY4 format protocol should only use the %MY4 format
RFC1834 (Whois++) requires the use of dates, but it didn't specify RFC1834 (Whois++) requires the use of dates, but it didn't specify the
the format, syntax, or representation of the date string to be used. format, syntax, or representation of the date string to be used.
4.0 Disk Sharing 9. Disk Sharing
Summary 9.1 Summary
The RFC's which were categorized into this group were those related to The RFC's which were categorized into this group were those related to
the Network File System (NFS). Other popular disk sharing protocols the Network File System (NFS). Other popular disk sharing protocols
like SMB and AFS were referred to their respective trustee's for like SMB and AFS were referred to their respective trustee's for
review. review.
After careful review, NFS has no year 2000 problems. After careful review, NFS has no year 2000 problems.
Specifics 9.2 Specifics
The reference to time in this protocol are the times of file data The references to time in this protocol are the times of file data
modification, file access, and file metadata change (mtime, atime, and modification, file access, and file metadata change (mtime, atime, and
time, respectively). These times are kept as 32 bit unsigned time, respectively). These times are kept as 32 bit unsigned
quantities in seconds since 1970-01-01, and so the NFS protocol will quantities in seconds since 1970-01-01, and so the NFS protocol will
not experience an Epoch event until the year 2106. not experience an Epoch event until the year 2106.
5.0 Games and Chat 10. Games and Chat
Summary 10.1 Summary
The RFC's which were categorized into this group were related to the The RFC's which were categorized into this group were related to the
Internet Relay Chat Protocol (IRC). No millenium problems exist in the Internet Relay Chat Protocol (IRC). No millennium problems exist in
IRC protocol. the IRC protocol.
Specifics 10.2 Specifics
There is only a single instance of time or date related information in the There is only a single instance of time or date related information in
IRC protocol as specified by RFC 1459. Section 4.3.4 defines a TIME message the IRC protocol as specified by RFC 1459. Section 4.3.4 defines a
type which queries a server for its local time. No mention is made of the TIME message type which queries a server for its local time. No
format of the repy or how it is parsed, the assumption being specific mention is made of the format of the reply or how it is parsed, the
implementations will handle the reply and parse it appropriately. assumption being specific implementations will handle the reply and
parse it appropriately.
6.0 Information Services & File Transfer 11. Information Services & File Transfer
Summary 11.1 Summary
The RFC's which were categorized into this group were divided among The RFC's which were categorized into this group were divided among
World Wide Web (WWW) protocols and File Transfer Protocols (FTP). WWW World Wide Web (WWW) protocols and File Transfer Protocols (FTP). WWW
protocols include the Hypertext Transfer Protocol (HTTP), a variety of protocols include the Hypertext Transfer Protocol (HTTP), a variety of
Uniform Resource formats (URL, URAs, etc.) and the HyperText Markup Uniform Resource formats (URL, URAs, etc.) and the HyperText Markup
Language(HTML). FTP protocols include the well known FTP protocol, the Language(HTML). FTP protocols include the well known FTP protocol,
Trivial File Transfer Protocol (TFTP) and a variety of extensions to the Trivial File Transfer Protocol (TFTP) and a variety of extensions
these protocols. Other information services includes the Finger to these protocols. Other information services includes the Finger
Protocol and the LPD protocol. Protocol and the LPD protocol.
HTTP 1.1 requires all newly generated date stamps to conform to RFC HTTP 1.1, as defined in RFC 2068, requires all newly generated date
1123 date formats which are Year 2000 compliant, but it also requires stamps to conform to RFC 1123 date formats which are Year 2000
acceptance of the older non-compliant RFC850 formats. Some specific compliant, but it also requires acceptance of the older non-compliant
recommendations are listed below and have been passed to the HTTP WG. RFC850 formats. Some specific recommendations are listed below and
have been passed to the HTTP WG.
HTML 2.0 could allow a very subtle Year 2000 problem, but once again HTML 2.0, as defined in RFC 1866, could allow a very subtle Year 2000
this recommendation has been passed on the HTML WG. problem, but once again this recommendation has been passed on the
HTML WG.
<<EDITOR'S NOTE: We need some serious help with this section because RFC 1778 on String Representations of Standard Attribute Syntax's
there are a lot of things still to check.>> define UTC Time in Section 2.21 and uses that definition in Section
2.25 on User Certificates. Since UTC Time is being used, there is a
potential millenium issue.
Specifics RFC 1440 on SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
defines an optional DATE command in Section 5 of the form mm/dd/yy
which is subject to millenium issues.
HTTP: 11.2 Specifics
The main IETF standards-track document on the HTTP protocol is The main IETF standards-track document on the HTTP protocol is RFC2068
RFC2068 on HTTP 1.1. It notes that historically three different on HTTP 1.1. It notes that historically three different date formats
date formats have been used, and that one of them uses a two-digit have been used, and that one of them uses a two-digit year field. In
year field. In section 3.3.1 it requires HTTP 1.1 implementations section 3.3.1 it requires HTTP 1.1 implementations to generate this
to generate this RFC1123 format: RFC1123 format:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
instead of this RFC850 format: instead of this RFC850 format:
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Unfortunately, many existing servers, serving on the order of one Unfortunately, many existing servers, serving on the order of one
fifth of the current HTTP traffic, send dates in the ambiguous fifth of the current HTTP traffic, send dates in the ambiguous RFC850
RFC850 format. format.
Section 19.3 of the RFC2068 says this: Section 19.3 of the RFC2068 says this:
o HTTP/1.1 clients and caches should assume that an RFC-850 date o HTTP/1.1 clients and caches should assume that an RFC-850 date
which appears to be more than 50 years in the future is in fact which appears to be more than 50 years in the future is in fact
in the past (this helps solve the "year 2000" problem). in the past (this helps solve the "year 2000" problem).
This avoids a "stale cache" problem, which would cause the This avoids a "stale cache" problem, which would cause the user to see
user to see out-of-date data. out-of-date data.
But to avoid unnecessary delays and bandwidth indicated in Scenario
2 below, this should be extended to say that a date which appears to
be more than 50 years in the past may be assumed to be in the
future, if a future date is legal for that field.
Scenario 3 indicates that servers may also want to follow these RFC 1986 documents experiments with a simple file transfer program
rules. over radio links using Enhanced Trivial FTP (ETFTP). There are a
number of timers defined which are all in seconds and have no year
2000 issues.
Here is some more background and justification for these arguments. In RFC 1866, on HTML 2.0,the <META> tag allows the embedding of
recommended values for some HTTP headers, including Expires. E.g.
The following headers use full dates: <META HTTP-EQUIV="Expires"
CONTENT="Tue, 04 Dec 1993 21:29:02 GMT">
HTTP/1.0: Servers should rewrite these dates into RFC1123 format if necessary.
Date:
Expires: # can be in the future
If-Modified-Since: # required to be in the past
Last-Modified: # required to be in the past
Retry-After: # can be in the future, also takes
# relative time - number of seconds
HTTP/1.1: RFC 1807 defines a format for bibliographic records and it specifies a
If-Range: DATE format, which requires 4 digit year fields.
If-Unmodified-Since: # required to be in the past
Note that clock skew between hosts can lead to confusion here - see RFC 1788 defines ICMP Domain Name messages. Section 3 defines a
the RFC for details. Domain Name Reply Packet, which contains a signed 32-bit integer.
This timer is not Year 2000 reliant and is certainly large enough for
it purposes.
Here are some scenarios of the implications of RFC850 dates, which RFC 1784 on TFTP Timeout Intervals and Transfer Size Options uses a
include stale caches, unnecessary requests for things which are field for the number of seconds for the timeout. It is an ASCII value
validly cached, delays for the user, extra bandwidth, and presenting from 1 to 255 octets in length. There is no Y2K issue.
incorrect information to the user.
Some cases involve comparisons with the current time, and others may RFC 1778 on String Representations of Standard Attribute Syntax's
involve comparisons between dates from different sources. The define UTC Time in Section 2.21 and uses that definition in Section
abbreviation "/99" is used to imply an RFC850 date with the value 2.25 on User Certificates. Since UTC Time is being used, there is a
"99" for the year. potential millenium issue.
RFC850 date from server RFC 1777 on LDAP defines a timelimit in Section 4.3 which is expressed
in seconds, but does not define any limits.
Scenario 1: RFC 1440 on SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
If a client gets an Expires /99 date after the year 2000, it defines an optional DATE command in Section 5 of the form mm/dd/yy,
should interpret it as 1999, to avoid ending up with a stale which is subject to millenium issues.
cache entry.
This is as already specified in RFC2068. RFC 1068 on the Background File Transfer Protocol (BFTP) defines two
commands in Sections B.2.12 and B.2.13, the Submit and Time commands.
>From the example usage's given in Appendix C it is clear that this
protocol will function correctly though the year 9999.
Scenario 2: RFC 1037 on NFILE (a file access protocol) discusses the a Date
If a client gets an Expires /00 date before the year 2000, and representation in Section 7.1 as the number of seconds since January
subsequently is faced with a choice to either retrieve the 1, 1900, but does not limit the field size. There should be no Y2K
document from its cache or look for an updated copy, it may issues.
interpret it as the year 2000, to avoid the unnecessary delay
and bandwidth of an extra request.
RFC850 date from client RFC 998 on NETBLT defines a Death time in Section 8, which is the
sender's death time in seconds.
Scenario 3: RFC 978 on the Voice File Interchange Protocol defines the Total Time
If a server gets an If-Modified-Since /99 date from a client of a message to be a 32-bit number of deci-seconds. This limits the
after the year 2000, it should interpret it as 1999 when size of a message but has no millenium issues.
comparing with the local modification date, in order to
possibly avoid sending a full GET response rather than a
HEAD response.
Note that an If-Modified-Since header must never be in the RFC 969 was obsoleted by RFC 998.
future.
HTML RFC 916 defines the Reliable Asynchronous Transfer Protocol (RATP).
Three timers are discussed in an expository manner in Section 5.4 and
its subsections. There are no relevant issues.
In RFC1866, on HTML 2.0,the <META> tag allows the embedding of RFCs 2122, 2056, 2055, 2054, 2044, 2016, 1960, 1959, 1874, 1865, 1862,
recommended values for some HTTP headers, including Expires. E.g. 1843, 1842, 1823, 1815, 1808, 1798, 1785, 1783, 1782, 1779, 1766,
1738, 1737, 1736, 1729, 1728, 1727, 1639, 1633, 1630, 1625, 1554,
1545, 1530, 1529, 1528, 1489, 1486, 1436, 1415, 1413, 1350, 1345,
1312, 1302, 1288, 1278, 1241, 1235, 1196, 1194, 1179, 1123, 1003, 971,
965, 959, 949, 913, 887, 866, 865, 864, 863, 862, 797, 795, 783, 775,
765, 751, 743, 742, 740, 737, 725, 722, 707, 691, 683, 662, 640, 624,
614, 607, 599, 412, 411, 410, 407, and 406 were found to have no
references to dates or times, and hence no millenium issues.
<META HTTP-EQUIV="Expires" RFCs 712, 697, 633, 630, 622, 610, 593, 592, 589, 573, 571, 570, 553,
CONTENT="Tue, 04 Dec 1993 21:29:02 GMT"> 551, 549, 543, 535, 532, 525, 520, 514, 506, 505, 504, 501, 499, 493,
490, 487, 486, 485, 480, 479, 478, 477, 472, 468, 467, 463, 454, 451,
448, 446, 438, 437, 436, 430, 429, 418, 414, and 409 were not
available for review.
Servers should rewrite these dates into RFC1123 format if necessary. RFCS below 400 were considered too obsolete to even consider.
7.0 Network & Transport Layer 12. Network & Transport Layer
Summary 12.1 Summary
The RFC's which were categorized into this group were the Internet The RFC's which were categorized into this group were the Internet
Protocol (IP) versions four and six, the Transmission Control Protocol Protocol (IP) versions four and six, the Transmission Control Protocol
(TCP), the User Datagram Protocol (UDP), the Point-to-Point Protocol (TCP), the User Datagram Protocol (UDP), the Point-to-Point Protocol
(PPP) and its extensions, Internet Control Message Protocol (ICMP), the (PPP) and its extensions, Internet Control Message Protocol (ICMP),
Address Resolution Protocol (ARP) and Remote Procedure Call (RPC) the Address Resolution Protocol (ARP) and Remote Procedure Call (RPC)
protocol. A variety of less known protocols were also examined. protocol. A variety of less known protocols were also examined.
Specifics After careful review of the nearly 400 RFC's in this catagory, no
millenium or year 2000 problems were found.
<<EDITOR'S NOTE: Not done yet but Robert Elz is almost finished>> 12.2 Specifics
8.0 Electronic Mail discusses the use if mandatory timers, but gives no mention as to how
they are implemented.
Summary RFC 2114 on a Data Link Switching Client Access Protocol defines a
retry timer of five seconds in Section 3.4.1.
RFC 2097 on the PPP NetBIOS Frame Control Protocol discuesses several
timer and timeouts in Section 2.1, none of which suffers from a year
2000 problem.
RFC 2075 on the IP Echo Host Service discusses timestamps and has no
millenium issues.
RFC 2005 on the Applicability for Mobile IP discusses using timestamps
as a security measure to avoid replay attacks (Section 3.), but does
not quantify them. There are no expected issues.
RFC 2002 on IP Mobility Support uses a 16-bit field for the lifetime
of a connection and notes the 18.2 hour limitation that this imposes.
Section 5.6.1 on replay protection requires the use of 64-bit time
fields, of a similar format to NTP packets.
RFC 1981 on Path MTU Discovery for IPv6 discusses timestamps and their
potential use to purge stale information in section 5.3. There is no
millenium issues in this use.
RFC 1963 on the PPP Serial Data Transport Protocol defines a flow
expiration time in section 4.9 which has no year 2000 issues.
RFC 1833 on Binding Protocols for ONC RPC Version 2 defines a variable
in Section 2.2.1 called RPCBPROC_GETTIME which returns the local time
in seconds since 1/1/1970. Since this value is not fields width
dependent, it may or may not wrap around the 32-bit value depending on
the operating system parameters.
RFC 1762 on the PPP DECnet Phase IV Control Protocol discusses a number
of timers in Section 5 (General Considerations). None of these timers
experience any millenium issues.
RFC 1761 on Snoop Version 2 Packet Capture File Format discusses two
32-bit timestamp values on Section 4 on Packet Record Formats. The
first of these may wrap in the year 2038, but should not effect anything
of any import.
RFC 1755 on ATM Signalling Support for IP Over ATM discusses timing
issues in Section 3.4 on VC Teardown. These limited timers have no
year 2000 issues.
RFC 1692 on the Transport Multiplexing Protocol (TMux) defines a TTL in
Section 2.3 and a timer in Section 3.3. Neither of these suffer from
any millenium or year 2000 issues.
RFC 1661 on PPP defines three timers in Section 4.6, none of which have
any year 2000 issues.
and the extended timers recommended in it.
RFC 1575 defines an echo function for CNLP discusses in the narrative
the use of the Lifetime Field in Section 5.3. There is nothing to
suggest that there is any year 2000 issues.
RFC 1329 on Dual MAC FDDI Networks discusses ARP cache administration
in Section 9.3 and 9.4 and various timers to expire entries.
RFC 1256 on ICMP Router Discovery Messages talks about lifetime fields
in Section 2 and defines three router configuration variables in Section
4.1. None of these have any millenium issues.
RFC 792 on ICMP discusses Timestamps and Timestamp Reply messages which
define a 32-bit timestamp which contains the number of milliseconds
since midnight UT.
RFC 791 on the Internet Protocol defines a packet type 68 which is an
Internet Timestamp, which defines a 32-bit field which contains the
number of milliseconds since midnght UT.
RFC 781 was defines the same option which is codified in RFC 791 as
a packet type 68.
RFC's 2126, 2118, 2113, 2107, 2106, 2105, 2098, 2067, 2043, 2023,
2019, 2018, 2009, 2004, 2003, 2001, 1994, 1993, 1990, 1989, 1979,
1978, 1977, 1976, 1975, 1974, 1973, 1972, 1967, 1962, 1954, 1946,
1937, 1936, 1934, 1933, 1932, 1931, 1926, 1924, 1919, 1918, 1917,
1916, 1915, 1897, 1888, 1887, 1885, 1884, 1883, 1881, 1878, 1877,
1868, 1860, 1859, 1853, 1841, 1832, 1831, 1809, 1795, 1791, 1770,
1764, 1763, 1756, 1754, 1752, 1744, 1735, 1726, 1719, 1717, 1710,
1707, 1705, 1698, 1693, 1688, 1687, 1686, 1683, 1682, 1681, 1680,
1679, 1678, 1677, 1676, 1674, 1673, 1672, 1671, 1670, 1669, 1667,
1663, 1662, 1638, 1634, 1631, 1629, 1624, 1622, 1621, 1620, 1619,
1618, 1613, 1605, 1604, 1598, 1590, 1577, 1570, 1561, 1560, 1553,
1552, 1551, 1549, 1548, 1547, 1538, 1526, 1518, 1498, 1490, 1483,
1475, 1466, 1454, 1435, 1434, 1433, 1393, 1390, 1385, 1379, 1378,
1377, 1376, 1375, 1374, 1365, 1363, 1362, 1356, 1347, 1337, 1335,
1334, 1333, 1332, 1331, 1326, 1323, 1314, 1307, 1306, 1294, 1293,
1277, 1263, 1240, 1237, 1236, 1234, 1226, 1223, 1220, 1219, 1210,
1209, 1201, 1191, 1188, 1185, 1172, 1171, 1166, 1162, 1151, 1146,
1145, 1144, 1141, 1139, 1134, 1132, 1122, 1110, 1106, 1103, 1088,
1086, 1085, 1078, 1072, 1071, 1070, 1069, 1063, 1062, 1057, 1055,
1051, 1050, 1046, 1045, 1044, 1042, 1030, 1029, 1027, 1025, 1016,
1008, 1007, 1006, 1002, 1001, 994, 986, 983, 982, 970, 964, 963, 962,
955, 948, 942, 941, 940, 936, 935, 932, 926, 925, 924, 922, 919, 917,
914, 905, 903, 896, 895, 894, 893, 892, 891, 889, 879, 877, 874, 872,
871, 848, 829, 826, 824, 815, 814, 813, 801, 793, 789, 787, 777, 768,
761, 760, 759, 730, 704, 696, 695, 692, 690, 689, 687, 685, 680, 675,
674, 660, 632, 626, 613, 611 were reviewed but were found to have no
millenium references.
RFC's 594, 591, 576, 550, 548, 528, 521, 489, 488, 473, 460, 459, 450,
449, 445, 442, 434, 426, 417, 398, 395, 394, 359, 357, 348, 347, 346,
343, 312, 301, 300, 271, 241, 210, 203, 202, 197, 190, 178, 176, 175,
166, 165, 161, 151, 150, 146, 145, 143, 142, 128, 127, 123, 122, 93,
91, 80, 79, 70, 67, 65, 62, 60, 59, 56, 55, 54, 53, 41, 38, 33, 23,
22, 20, 19, 17, 12 were deemed too old to be considered for millenium
investigation.
13. Electronic Mail
13.1 Summary
The RFC's which were categorized into this group were the Simple Mail The RFC's which were categorized into this group were the Simple Mail
Transfer Protocol (SMTP), Internet Mail Access Protocol (IMAP), Post Transfer Protocol (SMTP), Internet Mail Access Protocol (IMAP), Post
Office Protocol (POP), Multipurpose Internet Mail Exchange (MIME), and Office Protocol (POP), Multipurpose Internet Mail Exchange (MIME), and
X.400 to SMTP interaction. X.400 to SMTP interaction.
After reviewing all mail-related RFCs, it was discovered that while After reviewing all mail-related RFCs, it was discovered that while
some obsolete standards required two-digit years, all currently-used some obsolete standards required two-digit years, all currently used
standards require four-digit years and are thus not prone to typical standards require four-digit years and are thus not prone to typical
Year 2000 problems. Year 2000 problems.
Specifics 13.2 Specifics
RFCs 821 and 822, the main basis for SMTP mail exchange and message RFCs 821 and 822, the main basis for SMTP mail exchange and message
format, originally required two-digit years. However, both of these format, originally required two-digit years. However, both of these
RFCs were later modified by RFC 1123 in 1989, which strongly RFCs were later modified by RFC 1123 in 1989, which strongly
recommended 4-digit years. Although there might be a few very old recommended 4-digit years. Although there might be a few very old
SMTP systems using two-digit years, it is believed that almost all SMTP systems using two-digit years, it is believed that almost all
mail sent over the Internet today uses four-digit years. Mail that mail sent over the Internet today uses four-digit years. Mail that
contains two-digit years in its SMTP headers will not "fail", but contains two-digit years in its SMTP headers will not "fail", but
might be missorted in message stores and mail user agents. This might be mis-sorted in message stores and mail user agents. This
problem is avoided entirely by taking the RFC 1123 change as a problem is avoided entirely by taking the RFC 1123 change as a
requirement, rather than merely as a recommendation. requirement, rather than merely as a recommendation.
IMAP versions 1, 2, and 3 used two-digit years, but IMAP version 4 IMAP versions 1, 2, and 3 used two-digit years, but IMAP version 4
(defined in RFCs 1730 and 1732 in 1994) requires four-digit (defined in RFCs 1730 and 1732 in 1994) requires four-digit
years. There are still a few IMAP 2 servers and clients in use on years. There are still a few IMAP 2 servers and clients in use on the
the Internet today, but IMAP version 4 has already take over almost Internet today, but IMAP version 4 has already take over almost all of
all of the IMAP market. Mail stored on an IMAP server or client with the IMAP market. Mail stored on an IMAP server or client with
two-digit years will not "fail", but could possibly be missorted or two-digit years will not "fail", but could possibly be mis-sorted or
prematurely expired. prematurely expired.
RFC 1153 describes a format for digests of mailing lists, and uses RFC 1153 describes a format for digests of mailing lists, and uses
two-digit dates. This format is not widely used. The use of two-digit dates. This format is not widely used. The use of two-digit
two-digit dates could possibly cause missorting of stored messages. dates could possibly cause missorting of stored messages.
RFC 1327, which describes mapping between X.400 mail and SMTP mail, RFC 1327, which describes mapping between X.400 mail and SMTP mail,
uses the UTCTime format. uses the UTCTime format.
RFC 1422 describes the structure of certificates that were used in RFC 1422 describes the structure of certificates that were used in PEM
PEM (and are expected to be used in many other mail and non-mail (and are expected to be used in many other mail and non-mail
services). Those certificates use dates in UTCTime services). Those certificates use dates in UTCTime format. Poorly
format. Poorly-written software might prematurely expire or validate written software might prematurely expire or validate a certificate
a certificate based on comparisons of the date with the current based on comparisons of the date with the current date, although no
date, although no current software is known to do this. current software is known to do this.
9.0 Network Time Protocols 14. Network Time Protocols
Summary 14.1 Summary
The RFC's which were categorized into this group were the Network Time The RFC's which were categorized into this group were the Network Time
Protocol (NTP), and the Time Protocol. Protocol (NTP), and the Time Protocol.
NTP has been certified year 2000 compliant, while the Time Protocol NTP has been certified year 2000 compliant, while the Time Protocol
will "roll over" at Thu Feb 07 00:54:54 2036 GMT. Since NTP is the will "roll over" at Thu Feb 07 00:54:54 2036 GMT. Since NTP is the
current defacto standard for network time this does not seem to be an current defacto standard for network time this does not seem to be an
issue. issue.
Specifics 14.2 Specifics
There is no reference anywhere in the NTP specification or There is no reference anywhere in the NTP specification or
implementation to any reference epoch other than 1 January 1900. In implementation to any reference epoch other than 1 January 1900. In
short, NTP doesn't know anything about the millennium. short, NTP doesn't know anything about the millennium.
From the Time Protocol RFC (868): >From the Time Protocol RFC (868):
S: Send the time as a 32 bit binary number. S: Send the time as a 32 bit binary number.
... ...
The time is the number of seconds since 00:00 (midnight) 1 January The time is the number of seconds since 00:00 (midnight) 1 January
1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900
GMT; this base will serve until the year 2036. GMT; this base will serve until the year 2036.
10.0 Name Services 15. Name Services
Summary 15.1 Summary
The RFC's which were categorized into this group were the Domain Name The RFC's which were categorized into this group were the Domain Name
System (DNS), it's advanced add on features (Incremental Zone Transfer, System (DNS), it's advanced add on features (Incremental Zone
etc.). Transfer, etc.).
Specifics There have been no year 2000 relayed problems found with the DNS
protocols, or common implementations of them.
<<EDITOR'S NOTE: Still need this information>> 15.2 Specifics
11.0 Network Management One is a common practice of writing serial numbers in zone files as if
they represent a date, and using only two digits of the year. That
practice cannot survive into the year 2000. This is not a protocol
problem, the serial number is simply an integer, and any value is OK,
provided it always increases (see rfc1982 for a definition of what
that means). In any case, a change from 97abcd (or similar) to 00abcd
would be a decrease and so is not permitted. Zone file maintainers
have two choices, one easy (though irrational) one would be to
continue from 99 to 100 and so on. The other, is simply to switch, at
any time between now and when the serial number first needs updating
after the year 2000, to use 4 digits to represent the year instead of
2. As long as there are no more than 6 digits in the "abcd" part, and
this is done sometime before the year 2100, this is always an
increase, and therefore always safe. Should any zone files be of the
form yyabcdefg (with 7 digits after a 2-digit year) then the
procedures of section 7 of rfc2182 should be adopted to convert the
serial number to some other value.
Summary The other item of note is related to timestamps in DNS security.
Those are represented as 32 bit counts of seconds, based in 1970, and
hence have no year 2000 problems. however, they do obviously have a
natural end of life, and sometime before that time is reached, the
definitions of those fields need to be corrected, perhaps to allow
them to represent the number of seconds elapsed since the base, modulo
2^32, which is likely to be adequate for the purposes of DNS security
(signatures and keys are unlikely to need to be valid for more than 70
years). In any case, more work is needed in this area in the not too
far distant future.
16 Network Management
16.1 Summary
The RFC's which were categorized into this group were the Simple The RFC's which were categorized into this group were the Simple
Network Management Protocol (SNMP), a large number of Management Network Management Protocol (SNMP), a large number of Management
Information Bases (MIBs) and the Common Management Information Protocol Information Bases (MIBs) and the Common Management Information
(CMIP). Protocol (CMIP).
Although a few discrepancies have been found and outlined below, none Although a few discrepancies have been found and outlined below, none
of them should have an impacts on interoperability. of them should have an impact on interoperability.
Specifics 16.2 Specifics
1. Use of GeneralizedTime in CMOT (RFCs 1095 and 1189) 16.2.1 Use of GeneralizedTime in CMOT as defined in RFCs 1095 and 1189.
The standards for CMIP over TCP/IP specify an unusual use for the The standards for CMIP over TCP/IP specify an unusual use for the
GeneralizedTime type. (GeneralizedTime has a four-digit representation GeneralizedTime type. (GeneralizedTime has a four-digit
of the year.) representation of the year.)
If the system generating the PDU does not have the current time, yet If the system generating the PDU does not have the current time, yet
does have the time since last boot, then GeneralizedTime can be used to does have the time since last boot, then GeneralizedTime can be used
encode this information. The time since last boot will be added to the to encode this information. The time since last boot will be added to
base time "0001 Jan 1 00:00:00.00" using the Gregorian calendar the base time "0001 Jan 1 00:00:00.00" using the Gregorian calendar
algorithm. algorithm.
This is really a "Year 0" problem rather than a Year 2000 problem, and This is really a "Year 0" problem rather than a Year 2000 problem, and
in any case, CMOT is not currently deployed. in any case, CMOT is not currently deployed.
2. UTCTime in SNMP Definitions 16.2.2 UTCTime in SNMP Definitions
UTCTime is an ASN.1 type that includes a two-digit representation of UTCTime is an ASN.1 type that includes a two-digit representation of
the year. There are several options for UTCTime in ASN.1, that vary in the year. There are several options for UTCTime in ASN.1, that vary
precision and in local versus GMT, but these options all have two-digit in precision and in local versus GMT, but these options all have
years. The standards for SNMP definitions specify one particular two-digit years. The standards for SNMP definitions specify one
format: particular format:
YYMMDDHHMMZ YYMMDDHHMMZ
The first usage of UTCTime in the standards for SNMP definitions goes The first usage of UTCTime in the standards for SNMP definitions goes
all the way back to RFC 1303. It has persisted unchanged up through all the way back to RFC 1303. It has persisted unchanged up through
the current specifications in RFC 1902. The role of UTCTime in SNMP the current specifications in RFC 1902. The role of UTCTime in SNMP
definitions is to record the history of an SNMP MIB module in the definitions is to record the history of an SNMP MIB module in the
module itself, via two ASN.1 macros: module itself, via two ASN.1 macros:
o LAST-UPDATED o LAST-UPDATED
o REVISION o REVISION
Applications that store and use MIB modules need to be smart about Applications that store and use MIB modules need to be smart about
interpreting these UTCTimes, but with one exception, the times do not interpreting these UTCTimes, but with one exception, the times do not
actually flow in the network. This one exception is the actually flow in the network. This one exception is the
appnNodeMibVersion object in the APPN MIB (currently draft-ietf-snanau- appnNodeMibVersion object in the APPN MIB (currently
appnmib-04.txt, but soon to be published as an RFC), which returns the draft-ietf-snanau- appnmib-04.txt, but soon to be published as an
value of LAST-UPDATED from the version of the APPN MIB that an agent RFC), which returns the value of LAST-UPDATED from the version of the
has implemented. An application that can correctly interpret UTCTimes, APPN MIB that an agent has implemented. An application that can
by prepending a "19" or a "20" as appropriate, in the MIB modules it correctly interpret UTCTimes, by prepending a "19" or a "20" as
has stored locally will be able to interpret the value of this object appropriate, in the MIB modules it has stored locally will be able to
correctly as well. interpret the value of this object correctly as well.
3. Objects in the Printer MIB (RFC 1559) 16.2.3 Objects in the Printer MIB (RFC 1559)
There are two objects in the Printer MIB that allow use of a date as an There are two objects in the Printer MIB that allow use of a date as
object value with no explicit guidance for formatting the value. The an object value with no explicit guidance for formatting the value.
objects are prtInterpreterLangVersion and prtInterpreterVersion. Both The objects are prtInterpreterLangVersion and prtInterpreterVersion.
are defined with a syntax of OCTET STRING. The descriptions for the Both are defined with a syntax of OCTET STRING. The descriptions for
objects allow the object value to contain a date, version code or other the objects allow the object value to contain a date, version code or
product specific information to identify the interpreter or language. other product specific information to identify the interpreter or
The descriptions do not include an explicit statement recommending use language. The descriptions do not include an explicit statement
of a four-digit year when a date is used as the object value. recommending use of a four-digit year when a date is used as the
object value.
4. Dates in Mobile Network Tracing Records (RFC 2041) 16.2.4 Dates in Mobile Network Tracing Records (RFC 2041)
The RFC specifies trace headers and footers with date fields that are The RFC specifies trace headers and footers with date fields that are
character arrays of size 32. While 32 characters certainly provide character arrays of size 32. While 32 characters certainly provide
enough room for a four-digit year, there's no explicit statement that enough room for a four-digit year, there's no explicit statement that
these years must be represented with four digits. these years must be represented with four digits.
12.0 Network News 17 Network News
Summary 17.1 Summary
The RFC's which were categorized into this group were related to the The RFC's which were categorized into this group were related to the
Network News Protocol (NNTP). Network News Protocol (NNTP).
There does exist a problem in both NNTP and the Usenet News Message There does exist a problem in both NNTP, RFC 977, and the Usenet News
Format. They both specify two digit year format. A working group has Message Format, RFC 10336. They both specify two-digit year format.
been formed to update the network news protocols in general, and A working group has been formed to update the network news protocols
addressing this problem is on their list of work items. in general, and addressing this problem is on their list of work
items.
Specifics 17.2 Specifics
<<EDITOR'S NOTE: Still need someone to look over the specifics but The NNTP transfer protocols defined in RFC 977. Sections 3.7.1, the
Paul Hoffman pointed this out in passing.>> definition of the NEWGROUPS command, and 3.8.1, the NEWNEWS command,
that dates must be specified in YYMMDD format.
13.0 Real Time Services The format for USENET news messages is defined in RFC 1036. The Date
line is defined in section 2.1.2 and it is specified in RFC-822
format. It specifically disallows the standard UNIX ctime(3) format,
which would allow for four digit years. Section 2.2.4 on Expires also
mandates the same two-digit year format.
Summary 18. Real Time Services
18.1 Summary
The RFC's which were categorized into this group were related to IP The RFC's which were categorized into this group were related to IP
Multicast, RTP, and Internet Stream Protocol. Multicast, RTP, and Internet Stream Protocol. A Year 2000 problem
does occur in the Simple Network Paging Protocol, versions 2 & 3.
Both define a HOLDuntil option which uses a YYMMDDHHMMSS+/-GMT field.
Version 3 also defines a MSTAtus command, which is required to store,
dates and times as YYMMDDHHMMSS+/-GMT.
<<EDITOR'S NOTE: No input on this section to date.>> 18.2 Specifics
Specifics RFC 2102 discusses Multicast support for NIMROD and has no mention of
dates or time. RFC 2090 on TFTP Multicast options is also free from
any date/time references.
14.0 Routing RFC 2038 on RTP MPEG formats has three references to time: a
Presentation Time Stamp (PTS), a Decoding Time Stamp (DTS), and a
System Clock (SC) reference time. Each RTP packet contains a
timestamp derived from the sender 90 kHz clock reference. Each of the
header fields are defined in section 2.1, 3, and 3.3 are 32 bit
fields. No mention is made of a "zero" start time, so it is presumed
that this format will be valid until at least 2038.
Summary Similarly RFC 2035 on the RTP JPEG format defines the same timestamp
in section 3. RFC 2032 on RTP H.261 video streams uses a calculated
time based on the original frame so once again there is no millenium
issue. RFC 2029 on the RTP format for Sun's CellB video encoding
mentions the RTP timestamp in section 2.1.
RFC 2022 defines support for multicast over UNI 3.0/3.1 based ATM
networks. Section 5. defines a timeout value for connections between
one and twenty minutes. Section 5.1.1 discusses several timers that
are bound between five and ten seconds, while 5.1.3 requires an
inactivity timer, which should also run between one and twenty
minutes. Sections 5.1.5, 5.1.5.1, 5.1.5.2, 5.2.2, 5.4, 5.4.1, 5.4.2,
5.4.3, 6.1.3 and Appendix E all defines numerous timers, none of which
have any millenium issues.
RFC 1890 on RTP profiles for audio and video conferences discusses a
sampling frequency which has no issues. RFC 1889 on RTP discusses
time formats in section 4, as the same 64 bit unsigned integer format
that NTP uses. There is a "period" problem, which will occur in the
year 2106. Section 5.1 is a more formalized discussion of the
timestamp properties, while Section 6.3.1 discusses a variety of
different timers all using the 64 bit field format, or a compressed
32-bit version of the inner octet of bytes. Section 8.2 discusses
loop detection and how the various timers are used to determine if
looping occurs.
RFC 1861 on Version 3 of the Simple Network Paging Protocol does have
a Year 2000 problem. The protocol defines a HOLDuntil command in
section 4.5.6 and a MSTAtus command in section 4.6.10, both of which
require dates/times to be stored as YYMMDDHHMMSS+/-GMT. Clearly this
format will be invalid after the end of 1999.
RFC 1821 has no date/time references. RFC 1819 on Version 2 of the
Internet Stream Protocol defines a HELLO message format in section
6.1.2, which does contain a timer which is updated every millisecond.
No year 2000 problems exist with this protocol.
RFC 1645 on Version 2 of the Simple Network Paging Protocol contains
the same HOLDuntil field problem as version 3. The definition is
contained section 4.4.6.
RFC 1458 on the Requirements of Multicast Protocols discusses a
retransmission timer in section 4.23. and a general discussion of
timer expiration in section 5, neither of which have any millenium
concerns. RFC 1301 on the Multicast Transport Protocol defines a
heartbeat interval of time in section 2.1, as well as retention and
windows. Formal definitions for each are contained in sections 2.2.7,
2.2.8 and 2.2.9. The heartbeat is a 32 bit unsigned field, while the
Window and Retention are both 16 bit unsigned fields. Section 3.4.2
gives examples values for these fields, which indicate no millenium
issues.
RFC 1193 on Client Requirements for Real Time Services talks about
time in section 4.4, but there are no Year 2000 issues. RFC 1190 have
been obsoleted by RFC 1819, but the hello timer issues are similar.
RFCs 1789, 1768, 1703, 1614, 1569, 1568, 1546, 1469, 1453, 1313, 1257,
1197, 1112, 1054, 988, 966, 947, 809, 804, 803, 798, 769, 741, 511,
508, 420, 408 and 251 contain no date or time references.
19. Routing
19.1 Summary
The RFC's which were categorized into this group were Routing The RFC's which were categorized into this group were Routing
Information Protocol (RIP), the Open Shortest Path First (OSPF) Information Protocol (RIP), the Open Shortest Path First (OSPF)
protocol, Classless InterDomain Routing (CIDR),the Border Gateway protocol, Classless InterDomain Routing (CIDR),the Border Gateway
Protocol (BGP), and the InterDomain Routing Protocol (IDRP). Protocol (BGP), and the InterDomain Routing Protocol (IDRP).
After careful examination both BGP and RIP have been found Year 2000 After careful examination both BGP and RIP have been found Year 2000
compliant. compliant.
<<EDITOR'S NOTE: We need more here. The RIP statement is from Robert There is a small Year 2000 issue in RFC 1786 on the Representation of
Elz's statement in Munich.>> IP Routing Policies in the ripe-81++ Routing Registry. In Appendices
C the "changed" object parameter defines a format of <email-address>
Specifics YYMMDD, and similarly in Appendix D "withdrawn" object identifier has
he format of YYMMDD. Since these are only identifiers there should be
BGP4 little operational impact. Some application software may need to be
modified.
The BGP4 protocol or the BGP4 FSM do not have knowledge of absolute IDPR suffers from the classic Year 2038 problem, by having a timestamp
time. There is a notion of relative time inside BGP4, and this is counter which rolls over at that time.
visible in the fact that BGP4 has five timers.
The five timers are not a problem, since they keep relative time, as 19.2 Specifics
stated above. Below excerpts for proof from the RFC can be found:
* Hold timer: RFC 2091 on Extensions to RIP to Support Demand Circuits defines three
required and one optional timers in section 6. The Database Timer
(6.1), the Hold down Timer (6.2), the Retransmission Time (6.3) and
the Over-Subscription Timer (6.4) are all counters, which have no
millenium, issues. RFC 2081 on the applicability of RIPng discusses
deletion of routes for a variety of issues, one of which is the
garbage- collection timer exceeds 120 seconds. There are no Year 2000
issues. RFC 2080 on RIPng for IPv6, discusses various times in
section 2.6, none of which have any millenium problems.
The calculated value indicates the maximum number of seconds that RFC 1987 on Ipsilon's General Switch Management protocol there is a
may elapse between the receipt of successive KEEPALIVE, and/or Duration field defined in section 4, which has no relevant problems.
UPDATE messages by the sender. Section 8.2 defines the procedure for dealing with timers. RFC 1953
[...] on Ipsilon's Flow Management Specification for IPv4 defines the same
procedure in section 3.2, as well as a lifetime field in the Redirect
Message (Section 4.1). There are no millenium issues in either case.
The suggested value for the Hold Time is 90 seconds. There is a small Year 2000 issue in RFC 1786 on the Representation of
IP Routing Policies in the ripe-81++ Routing Registry. In Appendices
C the "changed" object parameter defines a format of <email-address>
YYMMDD, and similarly in Appendix D "withdrawn" object identifier has
he format of YYMMDD. Since these are only identifiers there should be
little operational impact. Some application software may need to be
modified.
* ConnectRetry timer: RFC 1771 defines the Border Gateway Protocol (BGP). BGP does not have
knowledge of absolute time, only relative time. There are five timers
defined: Hold Timer, ConnectRetry Timer, KeepAlive Timer,
MinRoueAdvertisementInterval and MinASOriginationInterval. There are
no known issues regarding BGP and the millenium.
The value of the initial timer shall be 60 seconds. The time shall In RFC 1584, which defines Multicast Extensions to OSPF, three timers
be doubled for each consecutive retry. are defined in section 8.2: IGMPPollingInterval, IGMPTimeout, and IGMP
[...] polling timer. Section 8.4 defines an age parameter for the local
groups database and section 9.3 outlines how to implement that age
parameter. It is not expected that any connections lifetime will be
long enough to cause any issues with these timers.
The suggested value for the ConnectRetry timer is 120 seconds. RFC 1583, OSPF, there are two types of timers defined in section 4.4,
single-shot timers and interval timers. There are a number of timers
defined in Section 9 including: HelloInterval, RouterDeadInterval,
InfTransDelay, Hello Timer, Wait Timer and RxmtInterval. Section 10
also defines the Inactivity Timer. No millenium problem exists for
any of these timers.
* KeepAlive timer: RFC 1582 is an earlier version of RFC 2091. Section 7 documents the
same timers as noted above, with the same lack of a millenium issue.
KeepAlive messages are sent periodically to ensure the liveness of RFC 1504 on Appletalk Update-Based Routing Protocol defines a
the connection. 10-second period in Section 3, and hence has no relevant issues.
[...]
The suggested value for the KeepAlive timer is 30 seconds. RFC 1479 which specifies IDPR Version 1, defines a timestamp field in
section 1.5.1, which is a 32 bit unsigned integer number of seconds
since January 1, 1970. The authors recognize the problem of timestamp
exhaustion in 2038, but feel that the protocol will not be in use for
that period. Sections 1.7, 2.1, and 4.3.1 also discuss the timestamp
field. RFC 1478 on the IDPR Architecture, also discusses the same
timestamp field in section 3.3.4. RFC 1477 again refers to the IDPR
timestamp in section 4.2. Thus IDPR has no Year 2000 issue, but does
have a period problem in the year 2038.
* MinRouteAdvertisementInterval: RFC 1075 on Distance Vector Multicast Routing Protocol devotes section
7 to time values. None of the timers have any millenium issues. RFC
1074, on the NFSNET backbone SPF IGP defines several hardcoded timers
values in section 5.
The parameter MinRouteAdvertisementInterval determines the minimum RFC 1058 on RIP discusses the 30-second timers in section 3.3. There is no millenium
amount of time that must elapse between advertisement of routes to a issues related to RIP.
particular destination from a single BGP speaker.
[...]
The suggested value for the MinRouteAdvertisementInterval is 30 RFC 995 on the Requirements for Internet Gateways has extensive
seconds. discussions of timers in section 7.1 and throughout A.1 and A.2. None
of these timers suffer from the millenium problem.
* MinASOriginationInterval: RFC 911 on EGP on Berkeley Unix recommend timer values of 30 and 120 seconds.
The parameter MinASOriginationInterval determines the minimum amount RFC 904 which defines the Exterior Gateway Protocol (EGP). There are
of time that must elapse between successive advertisements of UPDATE a number of timers discussed in sections 4.1.1 and 4.1.4. None of
messages that report changes within the advertising BGP speaker's these timers suffer from any relevant problems.
own autonomous systems.
[...]
The suggested value for the MinASOriginationInterval is 15 seconds. RFCs 2103, 2092, 2073, 2072, 2042, 2008, 1998, 1997, 1992, 1966, 1955,
1940, 1930, 1925, 1923, 1863, 1817, 1812, 1793, 1787, 1774, 1773,
1772, 1765, 1753, 1745, 1723, 1722, 1721, 1716, 1702, 1701, 1668,
1656, 1655, 1654, 1587, 1586, 1585, 1581, 1520, 1519, 1517, 1482,
1476, 1439, 1403, 1397, 1388, 1387, 1383, 1380, 1371, 1370, 1364,
1338, 1322, 1268, 1267, 1266, 1265, 1264, 1254, 1246, 1245, 1222,
1195, 1164, 1163, 1142, 1136, 1133, 1126, 1125, 1124,1104, 1102, 1092,
1009, 985, 981, 975, 950, 898, 890, 888, 875, and 823 contain no date
or time references.
15.0 Security 20. Security
Summary 20.1 Summary
The RFC's which were categorized into this group were kerberos The RFC's which were categorized into this group were kerberos
authentication protocol, Remote Authentication Dial In User Service authentication protocol, Remote Authentication Dial In User Service
(RADIUS), One Time Password System (OTP), Privacy Enhanced Mail (PEM), (RADIUS), One Time Password System (OTP), Privacy Enhanced Mail (PEM),
security extensions to a variety of protocols including (but not security extensions to a variety of protocols including (but not
limited to) RIPv2, HTTP, MIME, PPP, IP, Telnet and FTP. Encryption and limited to) RIPv2, HTTP, MIME, PPP, IP, Telnet and FTP. Encryption
authentication algorithms are also examined. and authentication algorithms are also examined.
<<EDITOR'S NOTE: We still need input for this section. I can tell you RFC 1507 on Distributed Authentication Security Services (DASS)
that OTP is compliant, but we need more input.>> discusses time and secure time in an expository manner in Sections
1.2.2, 1.4.4 and 2.1. Section 3.6 defines absolute time as an UTC
time with a precision of 1 second, and Section 4.1 discusses ANS.1
encoding of time values. Because of the imprecision of the UTC time
definition there could be problems with this protocol.
Specifics RFCs 1421-1424 specifies that PEM uses UTC time formats which could
have a Millenium issue since the year specification only provides the
last two digits of the year.
16.0 Virtual Terminal 20,2 Specifics
Summary RFC 2082 on RIP-2 MD% Authentication requires storage of security keys
for a specified lifetime in sections 4.1 and 4.2. There are no
millenium issues in this protocol.
RFC 2078 on the GSSAPI Version 2 defines numerous calls that use
timers for inputs and outputs. Sections 2.1.1, 2.1.3, 2.1.4, 2.1.5,
2.2.1, 2.2.2, 2.2.5 and 2.2.6 all use the lifetime_rec field, which is
defined as an integer counter in seconds. There should be no relevant
problems with this protocol.
RFC 2069 on Digest Authentication for HTTP, defines a 'date' and a
'last-modified' field in Section 2.1.2. Both are required to be RFC
1123 formats which is not subject to millenium issues. Section 3.2
discusses dates and times in the context of thwarting replay attacks,
but have no relevant issues.
RFC 2065 on DNS Security extensions first discusses time in section
2.3.3. The SIG RDATA format is defined in Section 4.1 discusses "time
signed" field and defines it to be a 32 bit unsigned integer number of
seconds since January 1, 1970. There will be a period problem in 2038
because of rollover. Section 4.5 on the file representations of SIG
RRs specifies the time field is expressed as YYYYMMDDHHMMSS which is
clearly Year 2000 compliant.
RFC 2059 on RADIUS account formats defines a "time" attribute, which
is optional which is a 32 bit unsigned integer number of seconds since
January 1, 1970. Likewise RFC 2058 on RADIUS also defines this
optional attribute in the same way. There will be a potential period
problem that occurs on 2038.
RFC 2035 on the Simple Public Key GSSAPI Mechanism talks about secure
timestamps in the background and overview sections only in an
expository manner.
RFC 1969 on the PPP DES Encryption Protocol uses time as an example in
Section 4 when discussing how to encrypt the first packet of a stream.
It is suggested that the first 32 bits be used for the number of
seconds since January 1, 1970. There could thus be a potential
operations problem in 2038.
RFC 1898 on the CyberCash Credit Card Protocol provides an example
message in Section 2.7 which uses a date field of the form
YYYYMMDDHHMM that is clearly Y2K compliant.
RFC 1510, which defines Kerberos Version 5, makes extensive use of
times in the security model. There are discussions in the
Introduction, as well as Sections 1.2, and 3.1.3. Kerberos uses ASN.1
definitions to abstract values, and hence defines a base definition
for KerberosTime which is a generalized time format in Section 5.2.
>From the text: "Example: The only valid format for UTC time 6 minutes,
27 seconds after 9 p.m. on 6 November 1985 is 19851106210627Z." A
side note is that the MIT reference implementation of the Kerberos, by
default set the expiration of tickets to December 31, 1999. This is
not protocol related but could have some operational impacts.
RFC 1509 on GSSAPI C-bindings makes a single reference that all
counters are in seconds and assigned as 32 bit unsigned integers.
Hence GSSAPI mechanisms may have problems in 2038.
RFC 1507 on Distributed Authentication Security Services (DASS)
discusses time and secure time in an expository manner in Sections
1.2.2, 1.4.4 and 2.1. Section 3.6 defines absolute time as an UTC
time with a precision of 1 second, and Section 4.1 discusses ANS.1
encoding of time values. Because of the imprecision of the UTC time
definition there could be problems with this protocol.
RFC 1424 on PEM Part IV defines a self-signed certificate request in
Section 3.1. The validity period start and end times are both
suggested to be January 1, 1970. RFC 1422 on PEM Part II defines the
validity period for a certificate in Section 3.3.6. It is recommended
that UTC Time formats are used, and notes the lack of a century so
that comparisons between different centuries must be done with care.
No suggestions on how to do this are included. Sections 3.5.2 also
discusses validity period in PEM CRLs. RFC 1421 on PEM Part I
discusses validity periods in an expository way. PEM as a whole could
have problems after December 31, 1999 based on its use of UTC Time.
RFCs 1113, 1114, and 1115 specify the original version of PEM and have
been obsoleted bye 1421, 1422, 1423, & 1424.
RFCs 2104, 2085, 2084, 2057, 2040, 2015, 1984, 1968, 1964, 1961, 1949,
1948, 1938, 1929, 1928, 1858, 1852, 1851, 1829, 1828, 1827, 1826,
1825, 1824, 1760, 1751, 1750, 1704, 1675, 1579, 1535, 1511, 1492,
1457, 1455, 1423, 1416, 1412, 1411, 1409, 1408, 1321, 1320, 1319,
1281, 1244, 1186, 1170, 1156, 1108, 1004, 972, 931, 927, 912, and 644
contain no date or time references.
21. Virtual Terminal
21.1 Summary
The RFC's which were categorized into this group were Telnet and its The RFC's which were categorized into this group were Telnet and its
many extensions, as well as the Secure SHell (SSH) protocol. The X many extensions, as well as the Secure SHell (SSH) protocol. The X
window systems was not considered since it is not an IETF protocol. window system was not considered since it is not an IETF protocol.
Official acknowledgement by the trustee's of the X window system was Official acknowledgement by the trustee's of the X window system was
given that the protocol will be examined by them. given that they will examine the protocol.
Unencrypted Telnet and TN3270 have both been found to be Year 2000 Unencrypted Telnet and TN3270 have both been found to be Year 2000
Compliant. The SSH protocols are also Year 2000 compliant. Compliant. The SSH protocols are also Year 2000 compliant.
Specifics 21.2 Specifics
17.0 Security Considerations RFC 1013 on the X Windows version 11 alpha protocol defines are 32 bit
unsigned integer timestamp in Section 4.
RFCs 2066, 1647, 1576, 1572, 1571, 1372, 1282, 1258, 1221, 1205, 1184,
1143, 1116, 1097, 1096, 1091, 1080, 1079, 1073, 1053, 1043, 1041,
1005, 946, 933, 930, 929, 907, 885, 884, 878, 861, 860, 859, 858, 857,
856, 855, 854, 851, 818, 802, 782, 779, 764, 749, 748, 747, 746, 736,
735, 734, 732, 731, 729, 728, 727, 726, 721, 719, 718, 701, 698, 658,
657, 656, 655, 654, 653, 652, 651, 647, 636, 431, 399, 393, 386, 365,
352, 340, 339, 328, 311, 297, 231, and 215 contain no date or time
references.
RFCs 703, 702, 688, 679, 669, 659, 600, 596, 595, 587, 563, 562, 560,
559, 513, 495, 470, 466, 461, 447, 435, 377, 364, 318, 296, 216, 206,
205, 177, 158, 139, 137, 110, 97 were unavailable.
22. Other
22.1 Summary
This grouping was a hodge-podge of informational RFCs, April Fool's
Jokes, IANA lists, and experimental RFCs. None were found to have any
millenium issues.
22.2 Specifics
RFCs 2123, 2036, 2014, 2000, 1999, 1958, 1935, 1900, 1879, 1855, 1822,
1814, 1810, 1799, 1776, 1718, 1715, 1700, 1699, 1640, 1627, 1610,
1607, 1601, 1600, 1599, 1594, 1580, 1578, 1574, 1550, 1540, 1539,
1527, 1499, 1463, 1462, 1438, 1410, 1402, 1401, 1391, 1367, 1366,
1360, 1359, 1358, 1349, 1340, 1336, 1325, 1324, 1300, 1291, 1287,
1261, 1250, 1249, 1206, 1200, 1199, 1177, 1175, 1174, 1152, 1149,
1140, 1135, 1127, 1118, 1111, 1100, 1099, 1077, 1060, 1039, 1020,
1019, 999, 997, 992, 990, 980, 960, 945, 944, 943, 939, 909, 902, 900,
899, 873, 869, 846, 845, 844, 843, 842, 840, 839, 838, 837, 836, 835,
834, 833, 832, 831, 820, 817, 800, 776, 774, 770, 766, 762, 758, 755,
750, 745, 717, 637, 603, 602, 590, 581, 578, 529, 527, 526, 523, 519,
518, 496, 491, 432, 404, 403, 401, 372, 363, 356, 345, 330, 329, 327,
317, 316, 313, 295, 282, 263, 242, 239, 234, 232, 225, 223, 213, 209,
204, 198, 195, 173, 170, 169, 167, 154, 149, 148, 147, 140, 138, 132,
131, 130, 129, 126, 121, 112, 109, 107, 100, 95, 90, 68, 64, 57, 52,
51, 46, 43, 37, 27, 25, 21, 15, 10, and 9 were examined and none were
found to have any date or time references, let alone millenium or Year
2000 issues.
23. Security Considerations
Although this document does consider the implications of various Although this document does consider the implications of various
security protocols, there is no need for additional security security protocols, there is no need for additional security
considerations. The effect of a potential year 2000 problem may cause considerations. The effect of a potential year 2000 problem may cause
some security problems, but those problems are more of specific some security problems, but those problems are more of specific
applications rather than protocol deficiencies introduced in this applications rather than protocol deficiencies introduced in this
document. document.
18.0 References 24. References
Because of the exhaustive nature of this investigation, the reader is Because of the exhaustive nature of this investigation, the reader is
referred to the list of published RFC's evailable from the IETF referred to the list of published RFC's available from the IETF
Secretariat or the RFC Editor, rather than republishing them here. Secretariat or the RFC Editor, rather than republishing them here.
19.0 Editors Address 25. Editors Address
Philip J. Nesser II Philip J. Nesser II
Nesser & Nesser Consulting Nesser & Nesser Consulting
13501 100th Ave N.E. 13501 100th Ave N.E.
Suite 5202 Suite 5202
Kirkland, WA 98052 Kirkland, WA 98052
(425)481-4303 (voice) (425)481-4303 (voice)
(425)482-9721 (fax) (425)482-9721 (fax)
pjnesser@nesser.com pjnesser@nesser.com
pjnesser@martigny.ai.mit.edu pjnesser@martigny.ai.mit.edu
20.0 Appendices Appendix A: List of RFC's for each Area
There were several appendices in the first draft of this document, but The following list contains the RFC's grouped by area that were
they have not changed, and it was decided to leave them out of the searched for year 2000 problems.
final version. If the reader wished to see any of the following
information they should obtain the -00 version of this draft: Each line contains three fields are separated by '::'. The first
filed is the RFC number, the second field is the type of RFC (S =
Standard, DS = Draft Standard, PS = Proposed Standard, E =
Experimental, H = Historical, I = Informational, BC = Best Current
Practice, '' = No Type), and the third field is the Title.
A.1 Autoconfiguration
1971:: PS:: IPv6 Stateless Address Autoconfiguration
1970:: PS:: Neighbor Discovery for IP Version 6 (IPv6)
1542:: PS:: Clarifications and Extensions for the Bootstrap Protocol
1541:: PS:: Dynamic Host Configuration Protocol
1534:: PS:: Interoperation Between DHCP and BOOTP
1533:: PS:: DHCP Options and BOOTP Vendor Extensions
1532:: PS:: Clarifications and Extensions for the Bootstrap Protocol
1531:: PS:: Dynamic Host Configuration Protocol
1497:: DS:: BOOTP Vendor Information Extensions
1395:: DS:: BOOTP Vendor Information Extensions
1084:: DS:: BOOTP vendor information extensions
1048:: DS:: BOOTP vendor information extensions
951:: DS:: Bootstrap Protocol
906:: :: Bootstrap loading using TFTP
A.2 Directory Services
2120:: E :: Managing the X.500 Root Naming Context
2079:: PS:: Definition of X.500 Attribute Types and an Object Class
to Hold Uniform Resource Identifiers (URIs)
1943:: I:: Building an X.500 Directory Service in the US
1914:: PS:: How to interact with a Whois++ mesh
1913:: PS:: Architecture of the Whois++ Index Service
1838:: E:: Use of the X.500 Directory to support mapping between
X.400 and RFC 822 Addresses
1837:: E:: Representing Tables and Subtrees in the X.500 Directory
1836:: E:: Representing the O/R Address hierarchy in the X.500
Directory Information Tree
1835:: PS:: Architecture of the WHOIS++ service
1834:: I:: Whois and Network Information Lookup Service Whois++
1781:: PS:: Using the OSI Directory to Achieve User Friendly Naming
1714:: I:: Referral Whois Protocol (RWhois)
1684:: I:: Introduction to White Pages services based on X.500
1637:: E:: DNS NSAP Resource Records
1632:: I:: A Revised Catalog of Available X.500 Implementations
1617:: I:: Naming and Structuring Guidelines for X.500 Directory Pilots
1609:: E:: Charting Networks in the X.500 Directory
1608:: E:: Representing IP Information in the X.500 Directory
1588:: I:: WHITE PAGES MEETING REPORT
1562:: I:: Naming Guidelines for the AARNet X.500 Directory Service
1491:: I:: A Survey of Advanced Usages of X.500
1488:: PS:: The X.500 String Representation of Standard Attribute
Syntaxes
1487:: PS:: X.500 Lightweight Directory Access Protocol
1485:: PS:: A String Representation of Distinguished Names
1484:: E:: Using the OSI Directory to achieve User Friendly Naming
1430:: I:: A Strategic Plan for Deploying an Internet X.500
Directory Service
1400:: I:: Transition and Modernization of the Internet Registration
Service
1384:: I:: Naming Guidelines for Directory Pilots
1355:: I:: Privacy and Accuracy Issues in Network Information
Center Databases
1330:: I:: Recommendations for the Phase I Deployment of OSI
Directory Services (X.500) and OSI Message Handling
Services (X.400) within the ESnet Community
1309:: I:: Technical Overview of Directory Services Using the
X.500 Protocol
1308:: I:: Executive Introduction to Directory Services Using the
X.500 Protocol
1292:: I:: A Catalog of Available X.500 Implementations
1279:: :: X.500 and Domains
1276:: PS:: Replication and Distributed Operations extensions to
provide an Internet Directory using X.500
1275:: I:: Replication Requirements to provide an Internet Directory
using X.500
1274:: PS:: The COSINE and Internet X.500 Schema
1255:: I:: A Naming Scheme for c=US
1218:: :: A Naming Scheme for c=US
1202:: I:: Directory Assistance Service
1107:: :: Plan for Internet directory services
954:: DS:: NICNAME/WHOIS
953:: H:: Hostname Server
812:: :: NICNAME/WHOIS
756:: :: NIC name server - a datagram-based information utility
752:: :: Universal host table
============ ==========================================================
Disk Sharing
1813:: I:: NFS Version 3 Protocol Specification
1094:: H:: NFS: Network File System Protocol specification
============ ==========================================================
Games and Chat
1459:: E:: Internet Relay Chat Protocol
======================================================================
Information Services & File Transfer
2122:: PS:: VEMMI URL Specification
2070:: PS:: Internationalization of the Hypertext Markup Language
2068:: PS:: Hypertext Transfer Protocol -- HTTP/1.1
2056:: PS:: Uniform Resource Locators for Z39.50
2055:: I:: WebNFS Server Specification
2054:: I:: WebNFS Client Specification
2044:: I:: "UTF-8, a transformation format of Unicode and ISO 10646"
2016:: E:: Uniform Resource Agents (URAs)
1986:: E:: Experiments with a Simple File Transfer Protocol for
Radio Links using Enhanced Trivial File Transfer
Protocol (ETFTP)
1980:: I:: A Proposed Extension to HTML: Client-Side Image Maps
1960:: PS:: A String Representation of LDAP Search Filters
1959:: PS:: An LDAP URL Format
1945:: I:: Hypertext Transfer Protocol -- HTTP/1.0
1942:: E:: HTML Tables
1874:: E:: SGML Media Types
1867:: E:: Form-based File Upload in HTML
1866:: PS:: Hypertext Markup Language - 2.0
1865:: I:: EDI Meets the Internet: Frequently Asked Questions
about Electronic Data Interchange (EDI) on the Internet
1862:: I:: "Report of the IAB Workshop on Internet Information
Infrastructure, October 12-14, 1994"
1843:: I:: HZ - A Data Format for Exchanging Files of Arbitrarily
Mixed Chinese and ASCII characters
1842:: I:: ASCII Printable Characters-Based Chinese Character
Encoding for Internet Messages
1823:: I:: The LDAP Application Program Interface
1815:: I:: Character Sets ISO-10646 and ISO-10646-J-1
1808:: PS:: Relative Uniform Resource Locators
1807:: I:: A Format for Bibliographic Records
1798:: PS:: Connection-less Lightweight Directory Access Protocol
1788:: E:: ICMP Domain Name Messages
1785:: I:: TFTP Option Negotiation Analysis
1784:: PS:: TFTP Timeout Interval and Transfer Size Options
1783:: PS:: TFTP Blocksize Option
1782:: PS:: TFTP Option Extension
1779:: DS:: A String Representation of Distinguished Names
1778:: DS:: The String Representation of Standard Attribute Syntaxes
1777:: DS:: Lightweight Directory Access Protocol
1766:: PS:: Tags for the Identification of Languages
1738:: PS:: Uniform Resource Locators (URL)
1737:: I:: Functional Requirements for Uniform Resource Names
1736:: I:: Functional Requirements for Internet Resource Locators
1729:: I:: Using the Z39.50 Information Retrieval Protocol in the
Internet Environment
1728:: I:: Resource Transponders
1727:: I:: A Vision of an Integrated Internet Information Service
1639:: E:: FTP Operation Over Big Address Records (FOOBAR)
1633:: I:: Integrated Services in the Internet Architecture
1630:: I:: Universal Resource Identifiers in WWW
1625:: I:: WAIS over Z39.50-1988
1558:: I:: A String Representation of LDAP Search Filters
1554:: I:: ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP
1545:: E:: FTP Operation Over Big Address Records (FOOBAR)
1530:: I:: Principles of Operation for the TPC.INT Subdomain:
General Principles and Policy
1529:: I:: Principles of Operation for the TPC.INT Subdomain:
Remote Printing -- Administrative Policies
1528:: E:: Principles of Operation for the TPC.INT Subdomain:
Remote Printing -- Technical Procedures
1489:: I:: Registration of a Cyrillic Character Set
1486:: E:: An Experiment in Remote Printing
1440:: E:: SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
1436:: I:: The Internet Gopher Protocol (a distributed document
search and retrieval protocol)
1415:: PS:: FTP-FTAM Gateway Specification
1413:: PS:: Identification Protocol
1350:: S:: THE TFTP PROTOCOL (REVISION 2)
1345:: I:: Character Mnemonics & Character Sets
1312:: E:: Message Send Protocol
1302:: I:: Building a Network Information Services Infrastructure
1288:: DS:: The Finger User Information Protocol
1278:: I:: A String Encoding of Presentation Address
1241:: E:: A Scheme for an Internet Encapsulation Protocol: Version 1
1235:: E:: The Coherent File Distribution Protocol
1196:: DS:: The Finger User Information Protocol
1194:: DS:: The Finger User Information Protocol
1179:: I:: Line Printer Daemon Protocol
1123:: S:: Requirements for Internet hosts - application and support
1068:: :: Background File Transfer Program BFTP
1037:: H:: NFILE - a file access protocol
1003:: :: Issues in defining an equations representation standard
998:: E:: NETBLT: A bulk data transfer protocol
978:: :: Voice File Interchange Protocol VFIP
971:: :: Survey of data representation standards
969:: :: NETBLT: A bulk data transfer protocol
965:: :: Format for a graphical communication protocol
959:: S:: File Transfer Protocol
949:: :: FTP unique-named store command
916:: H:: Reliable Asynchronous Transfer Protocol RATP
913:: H:: Simple File Transfer Protocol
887:: E:: Resource Location Protocol
866:: S:: Active users
865:: S:: Quote of the Day Protocol
864:: S:: Character Generator Protocol
863:: S:: Discard Protocol
862:: S:: Echo Protocol
797:: :: Format for Bitmap files
795:: :: Service mappings
783:: DS:: TFTP Protocol revision 2
775:: :: Directory oriented FTP commands
765:: :: File Transfer Protocol specification
751:: :: Survey of FTP mail and MLFL
743:: :: FTP extension: XRSQ/XRCP
742:: PS:: NAME/FINGER Protocol
740:: H:: NETRJS Protocol
737:: :: FTP extension: XSEN
725:: :: RJE protocol for a resource sharing network
722:: :: Thoughts on interactions in distributed services
712:: :: Distributed Capability Computing System DCCS
707:: :: High-level framework for network-based resource sharing
697:: :: CWD command of FTP
691:: :: One more try on the FTP
683:: :: FTPSRV - Tenex extension for paged files
662:: :: Performance improvement in ARPANET file transfers
from Multics
640:: :: Revised FTP reply codes
633:: :: IMP/TIP preventive maintenance schedule
630:: :: FTP error code usage for more reliable mail service
624:: :: Comments on the File Transfer Protocol
622:: :: Scheduling IMP/TIP down time
614:: :: "Response to RFC 607: ""Comments on the File Transfer
Protocol"""
610:: :: Further datalanguage design concepts
607:: :: Comments on the File Transfer Protocol
599:: :: Update on NETRJS
593:: :: Telnet and FTP implementation schedule change
592:: :: Some thoughts on system design to facilitate resource
sharing
589:: :: CCN NETRJS server messages to remote user
573:: :: Data and file transfer: Some measurement results
571:: :: Tenex FTP problem
570:: :: Experimental input mapping between NVT ASCII and UCSB
On Line System
553:: :: Draft design for a text/graphics protocol
551:: :: "[Letter from Feinroth re: NYU, ANL, and LBL entering
the net, and FTP protocol]"
549:: :: "Minutes of Network Graphics Group meeting, 15-17
July 1973"
543:: :: Network journal submission and delivery
542:: :: File Transfer Protocol
535:: :: Comments on File Access Protocol
532:: :: UCSD-CC Server-FTP facility
525:: :: MIT-MATHLAB meets UCSB-OLS -an example of resource sharing
520:: :: Memo to FTP group: Proposal for File Access Protocol
514:: :: Network make-work
506:: :: FTP command naming problem
505:: :: Two solutions to a file transfer access problem
504:: :: Distributed resources workshop announcement
501:: :: "Un-muddling ""free file transfer"""
499:: :: Harvard's network RJE
493:: :: "E.W., Jr Graphics Protocol"
490:: :: Surrogate RJS for UCLA-CCN
487:: :: Free file transfer
486:: :: Data transfer revisited
485:: :: MIX and MIXAL at UCSB
480:: :: Host-dependent FTP parameters
479:: :: Use of FTP by the NIC Journal
478:: :: FTP server-server interaction - II
477:: :: Remote Job Service at UCSB
472:: :: Illinois' reply to Maxwell's request for graphics
information NIC 14925
468:: :: FTP data compression
467:: :: Proposed change to Host-Host Protocol:Resynchronization
of connection status
463:: :: FTP comments and response to RFC 430
454:: :: File Transfer Protocol - meeting announcement and a new
proposed document
451:: :: Tentative proposal for a Unified User Level Protocol
448:: :: Print files in FTP
446:: :: Proposal to consider a network program resource notebook
438:: :: FTP server-server interaction
437:: :: Data Reconfiguration Service at UCSB
436:: :: Announcement of RJS at UCSB
430:: :: Comments on File Transfer Protocol
429:: :: Character generator process
418:: :: Server file transfer under TSS/360 at NASA Ames
414:: :: File Transfer Protocol FTP status and further comments
412:: :: User FTP documentation
411:: :: New MULTICS network software features
410:: :: Removal of the 30-second delay when hosts come up
409:: :: Tenex interface to UCSB's Simple-Minded File System
407:: H:: Remote Job Entry Protocol
406:: :: Scheduled IMP software releases
396:: :: Network Graphics Working Group meeting - second iteration
387:: :: Some experiences in implementing Network Graphics
Protocol Level 0
385:: :: Comments on the File Transfer Protocol
382:: :: Mathematical software on the ARPA Network
374:: :: IMP system announcement
373:: :: Arbitrary character sets
368:: :: "Comments on ""Proposed Remote Job Entry Protocol"""
367:: :: Network host status
366:: :: Network host status
361:: :: Deamon processes on host 106
360:: :: Proposed Remote Job Entry Protocol
354:: :: File Transfer Protocol
351:: :: Graphics information form for the ARPANET graphics
resources notebook
342:: :: Network host status
338:: :: EBCDIC/ASCII mapping for network RJE
336:: :: Level 0 Graphic Input Protocol
335:: :: New interface - IMP/360
332:: :: Network host status
325:: :: Network Remote Job Entry program - NETRJS
324:: :: RJE Protocol meeting
314:: :: Network Graphics Working Group meeting
310:: :: Another look at Data and File Transfer Protocols
309:: :: Data and File Transfer workshop announcement
307:: :: Using network Remote Job Entry
306:: :: Network host status
299:: :: Information management system
298:: :: Network host status
294:: :: "On the use of ""set data type"" transaction in
File Transfer Protocol"
293:: :: Network host status
292:: :: "E.W., Jr Graphics Protocol: Level 0 only"
288:: :: Network host status
287:: :: Status of network hosts
286:: :: Network library information system
285:: :: Network graphics
283:: :: NETRJT: Remote Job Service Protocol for TIPS
281:: :: Suggested addition to File Transfer Protocol
268:: :: Graphics facilities information
267:: :: Network host status
266:: :: Network host status
265:: :: "File Transfer Protocol"
264:: :: "Data Transfer Protocol"
255:: :: Status of network hosts
252:: :: Network host status
250:: :: Some thoughts on file transfer
238:: :: Comments on DTP and FTP proposals
217:: :: "Specifications changes for OLS, RJE/RJOR, and SMFS"
199:: :: Suggestions for a network data-tablet graphics protocol
192:: :: Some factors which a Network Graphics Protocol must
consider
191:: :: Graphics implementation and conceptualization at
Augmentation Research Center
189:: :: Interim NETRJS specifications
184:: :: Proposed graphic display modes
183:: :: EBCDIC codes and their mapping to ASCII
181:: :: Modifications to RFC 177
174:: :: UCLA - computer science graphics overview
172:: :: File Transfer Protocol
163:: :: Data transfer protocols
141:: :: Comments on RFC 114: A File Transfer Protocol
134:: :: Network Graphics meeting
133:: :: File transfer and recovery
125:: :: Response to RFC 86: Proposal for network standard format
for a graphics data stream
114:: :: File Transfer Protocol
105:: :: Network specifications for Remote Job Entry and Remote
Job Output Retrieval at UCSB
98:: :: Logger Protocol proposal
94:: :: Some thoughts on network graphics
88:: :: NETRJS: A third level protocol for Remote JobEntry
86:: :: Proposal for a network standard format for a data stream
to control graphics display
83:: :: Language-machine for data reconfiguration
========== ============================================================
Internet & Network Layer
2126:: PS:: ISO Transport Service on top of TCP (ITOT)
2125:: PS:: The PPP Bandwidth Allocation Protocol (BAP) The PPP
Bandwidth Allocation Control Protocol (BACP)
2118:: I:: Microsoft Point-To-Point Compression (MPPC) Protocol
2114:: I:: Data Link Switching Client Access Protocol
2113:: PS:: IP Router Alert Option
2107:: I:: Ascend Tunnel Management Protocol - ATMP
2106:: I:: Data Link Switching Remote Access Protocol
2105:: I:: Cisco Systems' Tag Switching Architecture Overview
2098:: I:: Toshiba's Router Architecture Extensions for ATM:Overview
2097:: PS:: The PPP NetBIOS Frames Control Protocol (NBFCP)
2075:: I:: IP Echo Host Service
2067:: DS:: IP over HIPPI
2043:: PS:: The PPP SNA Control Protocol (SNACP)
2023:: PS:: IP Version 6 over PPP
2019:: PS:: Transmission of IPv6 Packets Over FDDI
2018:: PS:: TCP Selective Acknowledgment Options
2009:: E:: GPS-Based Addressing and Routing
2005:: PS:: Applicability Statement for IP Mobility Support
2004:: PS:: Minimal Encapsulation within IP
2003:: PS:: IP Encapsulation within IP
2002:: PS:: IP Mobility Support
2001:: PS:: "TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms"
1994:: DS:: PPP Challenge Handshake Authentication Protocol (CHAP)
1993:: I:: PPP Gandalf FZA Compression Protocol
1990:: DS:: The PPP Multilink Protocol (MP)
1989:: DS:: PPP Link Quality Monitoring
1981:: PS:: Path MTU Discovery for IP version 6
1979:: I:: PPP Deflate Protocol
1978:: I:: PPP Predictor Compression Protocol
1977:: I:: PPP BSD Compression Protocol
1976:: I:: PPP for Data Compression in Data Circuit-Terminating
Equipment (DCE)
1975:: I:: PPP Magnalink Variable Resource Compression
1974:: I:: PPP Stac LZS Compression Protocol
1973:: PS:: PPP in Frame Relay
1972:: PS:: A Method for the Transmission of IPv6 Packets over
Ethernet Networks
1967:: I:: PPP LZS-DCP Compression Protocol (LZS-DCP)
1963:: I:: PPP Serial Data Transport Protocol (SDTP)
1962:: PS:: The PPP Compression Control Protocol (CCP)
1954:: I:: Transmission of Flow Labelled IPv4 on ATM Data Links
Ipsilon Version 1.0
1946:: I:: Native ATM Support for ST2+
1937:: I:: Local/Remote Forwarding Decision in Switched Data
Link Subnetworks
1936:: I:: Implementing the Internet Checksum in Hardware
1934:: I:: Ascend's Multilink Protocol Plus (MP+)
1933:: PS:: Transition Mechanisms for IPv6 Hosts and Routers
1932:: I:: IP over ATM: A Framework Document
1931:: I:: Dynamic RARP Extensions and Administrative Support for
Automatic Network Address Allocation
1926:: I:: An Experimental Encapsulation of IP Datagrams on
Top of ATM
1924:: I:: A Compact Representation of IPv6 Addresses
1919:: I:: Classical versus Transparent IP Proxies
1918:: BC:: Address Allocation for Private Internets
1917:: BC:: An Appeal to the Internet Community to Return Unused
IP Networks (Prefixes) to the IANA
1916:: I:: Enterprise Renumbering
1915:: BC:: Variance for The PPP Connection Control Protocol and
The PPP Encryption Control Protocol
1897:: E:: IPv6 Testing Address Allocation
1888:: E:: OSI NSAPs and IPv6
1887:: I:: An Architecture for IPv6 Unicast Address Allocation
1885:: PS:: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
1884:: PS:: IP Version 6 Addressing Architecture
1883:: PS:: "Internet Protocol, Version 6 (IPv6) Specification"
1881:: I:: IPv6 Address Allocation Management
1878:: I:: Variable Length Subnet Table For IPv4
1877:: I:: PPP Internet Protocol Control Protocol Extensions for
Name Server Addresses
1868:: E:: ARP Extension - UNARP
1860:: I:: Variable Length Subnet Table For IPv4
1859:: I:: ISO Transport Class 2 Non-use of Explicit Flow Control
over TCP RFC1006 extension
1853:: I:: IP in IP Tunneling
1841:: I:: PPP Network Control Protocol for LAN Extension
1833:: PS:: Binding Protocols for ONC RPC Version 2
1832:: PS:: XDR
1831:: PS:: RPC
1809:: I:: Using the Flow Label Field in IPv6
1795:: I:: "Data Link Switching
1791:: E:: TCP And UDP Over IPX Networks With Fixed Path MTU
1770:: I:: IPv4 Option for Sender Directed Multi-Destination Delivery
1764:: PS:: The PPP XNS IDP Control Protocol (XNSCP)
1763:: PS:: The PPP Banyan Vines Control Protocol (BVCP)
1762:: DS:: The PPP DECnet Phase IV Control Protocol (DNCP)
1761:: I:: Snoop Version 2 Packet Capture File Format
1756:: E:: REMOTE WRITE PROTOCOL - VERSION 1.0
1755:: PS:: ATM Signaling Support for IP over ATM
1754:: I:: IP over ATM Working Group's Recommendations for the
ATM Forum's Multiprotocol BOF Version 1
1752:: PS:: The Recommendation for the IP Next Generation Protocol
1744:: I:: Observations on the Management of the Internet Address
Space
1735:: E:: NBMA Address Resolution Protocol (NARP)
1726:: I:: Technical Criteria for Choosing IP
1719:: I:: A Direction for IPng
1717:: PS:: The PPP Multilink Protocol (MP)
1710:: I:: Simple Internet Protocol Plus White Paper
1707:: I:: CATNIP
1705:: I:: Six Virtual Inches to the Left
1698:: I:: Octet Sequences for Upper-Layer OSI to Support Basic
Communications Applications
1693:: E:: An Extension to TCP
1692:: PS:: Transport Multiplexing Protocol (TMux)
1688:: I:: IPng Mobility Considerations
1687:: I:: A Large Corporate User's View of IPng
1686:: I:: IPng Requirements
1683:: I:: Multiprotocol Interoperability In IPng
1682:: I:: IPng BSD Host Implementation Analysis
1681:: I:: On Many Addresses per Host
1680:: I:: IPng Support for ATM Services
1679:: I:: HPN Working Group Input to the IPng Requirements
Solicitation
1678:: I:: IPng Requirements of Large Corporate Networks
1677:: I:: Tactical Radio Frequency Communication Requirements
for IPng
1676:: I:: INFN Requirements for an IPng
1674:: I:: A Cellular Industry View of IPng
1673:: I:: Electric Power Research Institute Comments on IPng
1672:: I:: Accounting Requirements for IPng
1671:: I:: IPng White Paper on Transition and Other Considerations
1670:: I:: Input to IPng Engineering Considerations
1669:: I:: Market Viability as a IPng Criteria
1667:: I:: Modeling and Simulation Requirements for IPng
1663:: PS:: PPP Reliable Transmission
1662:: S:: PPP in HDLC-like Framing
1661:: S:: The Point-to-Point Protocol (PPP)
1644:: E:: T/TCP -- TCP Extensions for Transactions Functional
Specification
1638:: PS:: PPP Bridging Control Protocol (BCP)
1634:: I:: Novell IPX Over Various WAN Media (IPXWAN)
1631:: I:: The IP Network Address Translator (Nat)
1629:: DS:: Guidelines for OSI NSAP Allocation in the Internet
1626:: PS:: Default IP MTU for use over ATM AAL5
1624:: I:: Computation of the Internet Checksum via Incremental
Update
1622:: I:: Pip Header Processing
1621:: I:: Pip Near-term Architecture
1620:: I:: Internet Architecture Extensions for Shared Media
1619:: PS:: PPP over SONET/SDH
1618:: PS:: PPP over ISDN
1613:: I:: cisco Systems X.25 over TCP (XOT)
1605:: I:: SONET to Sonnet Translation
1604:: PS:: Definitions of Managed Objects for Frame Relay Service
1598:: PS:: PPP in X.25
1590:: I:: Media Type Registration Procedure
1577:: PS:: Classical IP and ARP over ATM
1575:: DS:: An Echo Function for CLNP (ISO 8473)
1570:: PS:: PPP LCP Extensions
1561:: E:: Use of ISO CLNP in TUBA Environments
1560:: I:: The MultiProtocol Internet
1553:: PS:: Compressing IPX Headers Over WAN Media (CIPX)
1552:: PS:: The PPP Internetwork Packet Exchange Control
Protocol (IPXCP)
1551:: I:: Novell IPX Over Various WAN Media (IPXWAN)
1549:: DS:: PPP in HDLC Framing
1548:: DS:: The Point-to-Point Protocol (PPP)
1547:: I:: Requirements for an Internet Standard
Point-to-Point Protocol
1538:: I:: Advanced SNA/IP
1526:: I:: Assignment of System Identifiers for TUBA/CLNP Hosts
1518:: PS:: An Architecture for IP Address Allocation with CIDR
1498:: I:: On the Naming and Binding of Network Destinations
1490:: DS:: Multiprotocol Interconnect over Frame Relay
1483:: PS:: Multiprotocol Encapsulation over ATM Adaptation Layer 5
1475:: E:: TP/IX
1466:: I:: Guidelines for Management of IP Address Space
1454:: I:: Comparison of Proposals for Next Version of IP
1435:: I:: IESG Advice from Experience with Path MTU Discovery
1434:: I:: Data Link Switching
1433:: E:: Directed ARP
1393:: E:: Traceroute Using an IP Option
1390:: S:: Transmission of IP and ARP over FDDI Networks
1385:: I:: EIP
1379:: I:: Extending TCP for Transactions -- Concepts
1378:: PS:: The PPP AppleTalk Control Protocol (ATCP)
1377:: PS:: The PPP OSI Network Layer Control Protocol (OSINLCP)
1376:: PS:: The PPP DECnet Phase IV Control Protocol (DNCP)
1375:: I:: Suggestion for New Classes of IP Addresses
1374:: PS:: IP and ARP on HIPPI
1365:: I:: An IP Address Extension Proposal
1363:: E:: A Proposed Flow Specification
1362:: I:: Novell IPX Over Various WAN Media (IPXWAN)
1356:: PS:: Multiprotocol Interconnect on X.25 and ISDN in the
Packet Mode
1347:: I:: "TCP and UDP with Bigger Addresses (TUBA), A Simple
Proposal for Internet Addressing and Routing"
1337:: I:: TIME-WAIT Assassination Hazards in TCP
1335:: :: A Two-Tier Address Structure for the Internet
1334:: PS:: PPP Authentication Protocols
1333:: PS:: PPP Link Quality Monitoring
1332:: PS:: The PPP Internet Protocol Control Protocol (IPCP)
1331:: PS:: The Point-to-Point Protocol (PPP) for the Transmission
of Multi-protocol Datagrams over Point-to-Point Links
1329:: I:: Thoughts on Address Resolution for Dual MAC FDDI Networks
1326:: I:: Mutual Encapsulation Considered Dangerous
1323:: PS:: TCP Extensions for High Performance
1314:: PS:: A File Format for the Exchange of Images in the Internet
1307:: E:: Dynamically Switched Link Control Protocol
1306:: I:: Experiences Supporting By-Request Circuit-Switched T3
Networks
1294:: PS:: Multiprotocol Interconnect over Frame Relay
1293:: PS:: Inverse Address Resolution Protocol
1277:: PS:: Encoding Network Addresses to Support Operation Over
Non-OSI Lower Layers
1263:: I:: TCP Extensions Considered Harmful
1256:: PS:: ICMP Router Discovery Messages
1240:: PS:: OSI Connectionless Transport Services on top of UDP
1237:: PS:: Guidelines for OSI NSAP Allocation in the Internet
1236:: :: IP to X.121 Address Mapping for DDN
1234:: PS:: Tunneling IPX Traffic through IP Networks
1226:: E:: Internet Protocol Encapsulation of AX.25 Frames
1223:: :: OSI CLNS and LLC1 Protocols on Network Systems HYPERchannel
1220:: PS:: Point-to-Point Protocol Extensions for Bridging
1219:: :: On the Assignment of Subnet Numbers
1210:: :: "Network and Infrastructure User Requirements for
Transatlantic Research Collaboration - Brussels,
July 16-18, and Washington July 24-25, 1990"
1209:: DS:: The Transmission of IP Datagrams over the SMDS Service
1201:: H:: Transmitting IP Traffic over ARCNET Networks
1191:: DS:: Path MTU Discovery
1188:: DS:: A Proposed Standard for the Transmission of IP Datagrams
over FDDI Networks
1185:: E:: TCP Extension for High-Speed Paths
1172:: PS:: The Point-to-Point Protocol (PPP) Initial Configuration
Options
1171:: DS:: The Point-to-Point Protocol for the Transmission of
Multi-Protocol Datagrams Over Point-to-Point Links
1166:: :: Internet Numbers
1162:: :: Connectionless Network Protocol (ISO 8473) and End
System to Intermediate System (ISO 9542) Management
Information Base
1151:: E:: Version 2 of the Reliable Data Protocol (RDP)
1146:: E:: TCP Alternate Checksum Options
1145:: E:: TCP Alternate Checksum Options
1144:: PS:: Compressing TCP/IP headers for low-speed serial links
1141:: :: Incremental Updating of the Internet Checksum
1139:: PS:: Echo function for ISO 8473
1134:: PS:: Point-to-Point Protocol
1132:: S:: Standard for the transmission of 802.2 packets over
IPX networks
1122:: S:: Requirements for Internet hosts - communication layers
1110:: :: Problem with the TCP big window option
1106:: :: TCP big window and NAK options
1103:: PS:: Proposed standard for the transmission of IP datagrams
over FDDI Networks
1088:: S:: Standard for the transmission of IP datagrams over
NetBIOS networks
1086:: :: ISO-TP0 bridge between TCP and X.25
1085:: :: ISO presentation services on top of TCP/IP based internets
1078:: :: TCP port service Multiplexer TCPMUX
1072:: E:: TCP extensions for long-delay paths
1071:: :: Computing the Internet checksum
1070:: :: Use of the Internet as a subnetwork for experimentation
with the OSI network layer
1069:: :: Guidelines for the use of Internet-IP addressesin the
ISO Connectionless-Mode Network Protocol
1063:: :: IP MTU Discovery options
1062:: :: Internet numbers
1057:: I:: RPC
1055:: S:: Nonstandard for transmission of IP datagrams over serial
lines
1051:: S:: Standard for the transmission of IP datagrams and ARP
packets over ARCNET networks
1050:: H:: RPC
1046:: :: Queuing algorithm to provide type-of-service for IP links
1045:: E:: VMTP
1044:: S:: Internet Protocol on Network System's HYPERchannel
1042:: S:: Standard for the transmission of IP datagrams over
IEEE 802 networks
1030:: :: On testing the NETBLT Protocol over divers networks
1029:: :: More fault tolerant approach to address resolution for
a Multi-LAN system of Ethernets
1027:: :: Using ARP to implement transparent subnet gateways
1025:: :: TCP and IP bake off
1016:: :: Something a host could do with source quench
1008:: :: Implementation guide for the ISO Transport Protocol
1007:: :: Military supplement to the ISO Transport Protocol
1006:: S:: ISO transport services on top of the TCP
1002:: S:: Protocol standard for a NetBIOS service on a TCP/UDP
transport
1001:: S:: Protocol standard for a NetBIOS service on a TCP/UDP
transport
994:: :: "Final text of DIS 8473,Protocol for Providing the
Connectionless-mode Network Service"
986:: :: Guidelines for the use of Internet-IP addressesin the
ISO Connectionless-Mode Network Protocol [Working draft]
983:: :: ISO transport arrives on top of the TCP
982:: :: Guidelines for the specification of the structure of the
Domain Specific Part DSP of the ISO standard NSAP address
970:: :: On packet switches with infinite storage
964:: :: Some problems with the specification of the Military
Standard Transmission Control Protocol
963:: :: Some problems with the specification of the Military
Standard Internet Protocol
962:: :: TCP-4 prime
955:: :: Towards a transport service for transaction processing
applications
948:: :: Two methods for the transmission of IP datagrams over
IEEE 802.3 networks
942:: :: Transport protocols for Department of Defense data
networks
941:: :: Addendum to the networkservice definition covering
network layer addressing
940:: :: Toward an Internet standard scheme for subnetting
936:: :: Another Internet subnet addressing scheme
935:: :: Reliable link layer protocols
932:: :: Subnetwork addressing scheme
926:: :: Protocol for providing the connectionless mode network
services
925:: :: Multi-LAN address resolution
924:: :: Official ARPA-Internet protocols for connecting
personal computers to the Internet
922:: S:: Broadcasting Internet datagrams in the presence of subnets
919:: S:: Broadcasting Internet datagrams
917:: :: Internet subnets
914:: H:: Thinwire protocol for connecting personal computers to
the Internet
905:: :: ISO Transport Protocol specification ISO DP 8073
903:: S:: Reverse Address Resolution Protocol
896:: :: Congestion control in IP/TCP internetworks
895:: S:: Standard for the transmission of IP datagrams over
experimental Ethernet networks
894:: S:: Standard for the transmission of IP datagrams over
Ethernet networks
893:: :: Trailer encapsulations
892:: :: ISO Transport Protocol specification [Draft]
891:: S:: DCN local-network protocols
889:: :: Internet delay experiments
879:: :: TCP maximum segment size and related topics
877:: S:: Standard for the transmission of IP datagrams over
public data networks
874:: :: Critique of X.25
872:: :: TCP-on-a-LAN
871:: :: Perspective on the ARPANET reference model
848:: :: "Who provides the ""little"" TCP services?"
829:: :: Packet satellite technology reference sources
826:: S:: Ethernet Address Resolution Protocol
824:: :: CRONUS Virtual Local Network
815:: :: IP datagram reassembly algorithms
814:: :: "Name, addresses, ports, and routes"
813:: :: Window and acknowlegement strategy in TCP
801:: :: NCP/TCP transition plan
793:: S:: Transmission Control Protocol
792:: S:: Internet Control Message Protocol
791:: S:: Internet Protocol
789:: :: Vulnerabilities of network control protocols
787:: :: Connectionless data transmission survey/tutorial
781:: :: Specification of the Internet Protocol IP timestamp option
777:: :: Internet Control Message Protocol
768:: S:: User Datagram Protocol
761:: :: DOD Standard Transmission Control Protocol
760:: :: DoD standard Internet Protocol
759:: H:: Internet Message Protocol
730:: :: Extensible field addressing
704:: :: IMP/Host and Host/IMP Protocol change
696:: :: Comments on the IMP/Host and Host/IMP Protocol changes
695:: :: Official change in Host-Host Protocol
692:: :: Comments on IMP/Host Protocol changes RFCs 687 and 690
690:: :: Comments on the proposed Host/IMP Protocol changes
689:: :: Tenex NCP finite state machine for connections
687:: :: IMP/Host and Host/IMP Protocol changes
685:: :: Response time in cross network debugging
680:: :: Message Transmission Protocol
675:: :: Specification of Internet Transmission Control Program
674:: :: Procedure call documents - version 2
660:: :: Some changes to the IMP and the IMP/Host interface
632:: :: Throughput degradations for single packet messages
626:: :: On a possible lockup condition in IMP subnet due to
message sequencing
613:: :: Network connectivity
611:: :: Two changes to the IMP/Host Protocol to improve
user/network communications
594:: :: Speedup of Host-IMP interface
591:: :: Addition to the Very Distant Host specifications
576:: :: Proposal for modifying linking
550:: :: NIC NCP experiment
548:: :: Hosts using the IMP Going Down message
528:: :: Software checksumming in the IMP and network reliability
521:: :: Restricted use of IMP DDT
489:: :: Comment on resynchronization of connection status proposal
488:: :: NLS classes at network sites
476:: :: IMP/TIP memory retrofit schedule rev. 2
473:: :: MIX and MIXAL?
460:: :: NCP survey
459:: :: Network questionnaires
450:: :: MULTICS sampling timeout change
449:: :: Current flow-control scheme for IMPSYS
445:: :: IMP/TIP preventive maintenance schedule
442:: :: Current flow-control scheme for IMPSYS
434:: :: IMP/TIP memory retrofit schedule
426:: :: Reconnection Protocol
417:: :: Link usage violation
398:: :: ICP sockets
395:: :: Switch settings on IMPs and TIPs
394:: :: Two proposed changes to the IMP-Host Protocol
359:: :: Status of the release of the new IMP System
357:: :: Echoing strategy for satellite links
348:: :: Discard process
347:: :: Echo process
346:: :: Satellite considerations
343:: :: IMP System change notification
312:: :: Proposed change in IMP-to-Host Protocol
301:: :: "BBN IMP #5 and NCC schedule March 4, 1971"
300:: :: ARPA Network mailing lists
271:: :: IMP System change notifications
241:: :: Connecting computers to MLC ports
210:: :: Improvement of flow control
203:: :: Achieving reliable communication
202:: :: Possible deadlock in ICP
197:: :: Initial Connection Protocol - Reviewed
190:: :: DEC PDP-10-IMLAC communications system
178:: :: Network graphic attention handling
176:: :: "Comments on ""Byte size for connections"""
175:: :: "Comments on ""Socket conventions reconsidered"""
166:: :: Data Reconfiguration Service
165:: :: Proffered official Initial Connection Protocol
161:: :: Solution to the race condition in the ICP
151:: :: "Comments on a proffered official ICP
150:: :: Use of IPC facilities
146:: :: Views on issues relevant to data sharing on computer
networks
145:: :: Initial Connection Protocol control commands
143:: :: Regarding proffered official ICP
142:: :: Time-out mechanism in the Host-Host Protocol
128:: :: Bytes
127:: :: Comments on RFC 123
123:: :: Proffered official ICP
122:: :: Network specifications for UCSB's Simple-Minded File
System
93:: :: Initial Connection Protocol
91:: :: Proposed User-User Protocol
80:: :: Protocols and data formats
79:: :: Logger Protocol error
70:: :: Note on padding
67:: :: Proposed change to Host/IMP spec to eliminate marking
65:: :: Comments on Host/Host Protocol document #1
62:: :: Systems for interprocess communication in a resource
sharing computer network
60:: :: Simplified NCP Protocol
59:: :: Flow control - fixed versus demand allocation
56:: :: Third level protocol
55:: :: Prototypical implementation of the NCP
54:: :: Official protocol proffering
53:: :: Official protocol mechanism
41:: :: IMP-IMP teletype communication
38:: :: Comments on network protocol from NWG/RFC #36
33:: :: New Host-Host Protocol
23:: :: Transmission of multiple control messages
22:: :: Host-host control message formats
20:: :: ASCII format for network interchange
19:: :: Two protocol suggestions to reduce congestion at
swap bound nodes
17:: :: Some questions re
12:: :: IMP-Host interface flow diagrams
=====================================================================
Mail
2112:: PS:: The MIME Multipart/Related Content-type
2111:: PS:: Content-ID and Message-ID Uniform Resource Locators
2110:: PS:: "MIME E-mail Encapsulation of Aggregate Documents, such
as HTML (MHTML)"
2109:: PS:: HTTP State Management Mechanism
2095:: PS:: IMAP/POP AUTHorize Extension for Simple Challenge/Response
2088:: PS:: IMAP4 non-synchroniziong literals
2087:: PS:: IMAP4 QUOTA extension
2086:: PS:: IMAP4 ACL extension
2077:: PS:: The Model Primary Content Type for Multipurpose
Internet Mail Extensions
2076:: I:: Common Internet Message Headers
2062:: I:: Internet Message Access Protocol - Obsolete Syntax
2061:: I:: IMAP4 COMPATIBILITY WITH IMAP2BIS
2060:: PS:: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
2049:: DS:: Multipurpose Internet Mail Extensions (MIME) Part Five
2048:: BC:: Multipurpose Internet Mail Extensions (MIME) Part Four
2047:: DS:: MIME (Multipurpose Internet Mail Extensions) Part Three
2046:: DS:: Multipurpose Internet Mail Extensions (MIME) Part Two
2045:: DS:: Multipurpose Internet Mail Extensions (MIME) Part One
2034:: PS:: SMTP Service Extension for Returning Enhanced Error Codes
2033:: I:: Local Mail Transfer Protocol
2017:: PS:: Definition of the URL MIME External-Body Access-Type
1991:: I:: PGP Message Exchange Formats
1985:: PS:: SMTP Service Extension for Remote Message Queue Starting
1957:: I:: Some Observations on Implementations of the Post Office
Protocol (POP3)
1947:: I:: Greek Character Encoding for Electronic Mail Messages
1939:: S:: Post Office Protocol - Version 3
1927:: I:: Suggested Additional MIME Types for Associating Documents
1922:: I:: Chinese Character Encoding for Internet Messages
1911:: E:: Voice Profile for Internet Mail
1896:: I:: The text/enriched MIME Content-type
1895:: I:: The Application/CALS-1840 Content-type
1894:: PS:: An Extensible Message Format for Delivery Status
Notifications
1893:: PS:: Enhanced Mail System Status Codes
1892:: PS:: The Multipart/Report Content Type for the Reporting
of Mail System Administrative Messages
1891:: PS:: SMTP Service Extension for Delivery Status Notifications
1873:: E:: Message/External-Body Content-ID Access Type
1872:: E:: The MIME Multipart/Related Content-type
1870:: S:: SMTP Service Extension for Message Size Declaration
1869:: S:: SMTP Service Extensions
1864:: DS:: The Content-MD5 Header Field
1854:: PS:: SMTP Service Extension for Command Pipelining
1848:: PS:: MIME Object Security Services
1847:: PS:: Security Multiparts for MIME
1846:: E:: SMTP 521 reply code
1845:: E:: SMTP Service Extension for Checkpoint/Restart
1844:: I:: Multimedia E-mail (MIME) User Agent checklist
1830:: E:: SMTP Service Extensions for Transmission of Large
and Binary MIME Messages
1820:: I:: Multimedia E-mail (MIME) User Agent Checklist
1806:: E:: Communicating Presentation Information in Internet
Messages
1804:: E:: Schema Publishing in X.500 Directory
1803:: I:: Recommendations for an X.500 Production Directory Service
1801:: E:: MHS use of the X.500 Directory to support MHS Routing
1767:: PS:: MIME Encapsulation of EDI Objects
1741:: I:: MIME Content Type for BinHex Encoded Files
1740:: PS:: MIME Encapsulation of Macintosh files - MacMIME
1734:: PS:: POP3 AUTHentication command
1733:: I:: DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
1732:: I:: IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS
1731:: PS:: IMAP4 Authentication mechanisms
1730:: PS:: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
1725:: DS:: Post Office Protocol - Version 3
1711:: I:: Classifications in E-mail Routing
1685:: I:: Writing X.400 O/R Names
1653:: DS:: SMTP Service Extension for Message Size Declaration
1652:: DS:: SMTP Service Extension for 8bit-MIMEtransport
1651:: DS:: SMTP Service Extensions
1649:: I:: Operational Requirements for X.400 Management Domains
in the GO-MHS Community
1648:: PS:: Postmaster Convention for X.400 Operations
1642:: E:: UTF-7 - A Mail-Safe Transformation Format of Unicode
1641:: E:: Using Unicode with MIME
1616:: I:: X.400(1988) for the Academic and Research Community
in Europe
1615:: I:: Migrating from X.400(84) to X.400(88)
1563:: I:: The text/enriched MIME Content-type
1557:: I:: Korean Character Encoding for Internet Messages
1556:: I:: Handling of Bi-directional Texts in MIME
1555:: I:: Hebrew Character Encoding for Internet Messages
1544:: PS:: The Content-MD5 Header Field
1524:: I:: A User Agent Configuration Mechanism For Multimedia
Mail Format Information
1523:: I:: The text/enriched MIME Content-type
1522:: DS:: MIME (Multipurpose Internet Mail Extensions) Part Two
1521:: DS:: MIME (Multipurpose Internet Mail Extensions) Part One
1506:: I:: A tutorial on gatewaying between X.400 and Internet mail
1505:: E:: Encoding Header Field for Internet Messages
1502:: PS:: X.400 Use of Extended Character Sets
1496:: PS:: Rules for downgrading messages from X.400/88 to X.400/84
when MIME content-types are present in the messages
1495:: PS:: Mapping between X.400 and RFC-822 Message Bodies
1494:: PS:: Equivalences between 1988 X.400 and RFC-822 Message Bodies
1468:: I:: Japanese Character Encoding for Internet Messages
1465:: E:: Routing coordination for X.400 MHS services within a
multi protocol / multi network environment Table Format
V3 for static routing
1460:: DS:: Post Office Protocol - Version 3
1456:: I:: Conventions for Encoding the Vietnamese Language VISCII
1437:: I:: The Extension of MIME Content-Types to a New Medium
1429:: I:: Listserv Distribute Protocol
1428:: I:: Transition of Internet Mail from Just-Send-8 to
8Bit-SMTP/MIME
1427:: PS:: SMTP Service Extension for Message Size Declaration
1426:: PS:: SMTP Service Extension for 8bit-MIMEtransport
1425:: PS:: SMTP Service Extensions
1405:: E:: Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
1357:: I:: A Format for E-mailing Bibliographic Records
1344:: I:: Implications of MIME for Internet Mail Gateways
1343:: I:: A User Agent Configuration Mechanism For Multimedia
Mail Format Information
1342:: PS:: Representation of Non-ASCII Text in Internet Message
Headers
1341:: PS:: MIME (Multipurpose Internet Mail Extensions)
1339:: E:: Remote Mail Checking Protocol
1328:: PS:: X.400 1988 to 1984 downgrading
1327:: PS:: Mapping between X.400(1988) / ISO 10021 and RFC 822
1225:: DS:: Post Office Protocol - Version 3
1211:: :: Problems with the Maintenance of Large Mailing Lists
1204:: E:: Message Posting Protocol (MPP)
1203:: H:: Interactive Mail Access Protocol - Version 3
1176:: E:: Interactive Mail Access Protocol - Version 2
1168:: :: Intermail and Commercial Mail Relay Services
1159:: E:: Message Send Protocol
1154:: E:: Encoding Header Field for Internet Messages
1153:: E:: Digest Message Format
1148:: E:: Mapping between X.400 (1988) / ISO 10021 and RFC 822
1138:: I:: Mapping between X.400(1988) / ISO 10021 and RFC 822
1137:: E:: Mapping between full RFC 822 and RFC 822 with restricted
encoding
1090:: :: SMTP on X.25
1082:: H:: Post Office Protocol - version 3
1081:: PS:: Post Office Protocol - version 3
1064:: H:: Interactive Mail Access Protocol
1056:: I:: PCMAIL
1049:: S:: Content-type header field for Internet messages
1047:: :: Duplicate messages and SMTP
1026:: PS:: Addendum to RFC 987
993:: :: PCMAIL
987:: PS:: Mapping between X.400 and RFC 822
984:: :: PCMAIL
976:: :: UUCP mail interchange format standard
974:: S:: Mail routing and the domain system
937:: H:: Post Office Protocol - version 2
934:: :: Proposed standard for message encapsulation
918:: :: Post Office Protocol
915:: :: Network mail path service
910:: :: Multimedia mail meeting notes
886:: :: Proposed standard for message header munging
876:: :: Survey of SMTP implementations
841:: :: Specification for message format for Computer Based
Message Systems
822:: S:: Standard for the format of ARPA Internet text messages
821:: S:: Simple Mail Transfer Protocol
808:: :: Summary of computer mail services meeting held at BBN
on 10 January 1979
807:: :: Multimedia mail meeting notes
805:: :: Computer mail meeting notes
788:: :: Simple Mail Transfer Protocol
786:: :: Mail Transfer Protocol
785:: :: Mail Transfer Protocol
784:: :: Mail Transfer Protocol
780:: :: Mail Transfer Protocol
773:: :: Comments on NCP/TCP mail service transition strategy
772:: :: Mail Transfer Protocol
771:: :: Mail transition plan
767:: :: Structured format for transmission of multi-media
documents
763:: :: Role mailboxes
757:: :: "Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems"
754:: :: Out-of-net host addresses for mail
753:: :: Internet Message Protocol
744:: :: MARS - a Message Archiving and Retrieval Service
733:: :: Standard for theformat of ARPA network text messages
724:: :: Proposed official standard for the format of ARPA
Network messages
720:: :: Address specification syntax for network mail
714:: :: Host-Host Protocol for an ARPANET-type network
713:: :: MSDTP-Message Services Data Transmission Protocol
706:: :: On the junk mail problem
577:: :: Mail priority
574:: :: Announcement of a mail facility at UCSB
561:: :: Standardizingnetwork mail headers
555:: :: Responses to critiques of the proposed mail protocol
539:: :: Thoughts on the mail protocol proposed in RFC524
534:: :: Lost message detection
533:: :: Message-ID numbers
524:: :: Proposed Mail Protocol
516:: :: Lost message detection
512:: :: More on lost message detection
510:: :: Request for network mailbox addresses
498:: :: On mail service to CCN
475:: :: FTP and network mail system
469:: :: Network mail meeting summary
458:: :: Mail retrieval via FTP
453:: :: Meeting announcement to discuss a network mail system
333:: :: Proposed experiment with a Message Switching Protocol
278:: :: Revision of theMail Box Protocol
224:: :: Comments on Mailbox Protocol
221:: :: Mail Box Protocol
196:: :: Mail Box Protocol
58:: :: Logical message synchronization
42:: :: Message data types
=====================================================================
NTP
2030:: I:: "Simple Network Time Protocol (SNTP) Version 4 for IPv4,
IPv6 and OSI"
1769:: I:: Simple Network Time Protocol (SNTP)
1708:: I:: NTP PICS PROFORMA For the Network Time Protocol Version 3
1589:: I:: A Kernel Model for Precision Timekeeping
1361:: I:: Simple Network Time Protocol (SNTP)
1305:: PS:: Network Time Protocol (v3)
1165:: E:: Network Time Protocol (NTP) over the OSI Remote Operations
Service
1129:: :: Internet time synchronization
1128:: :: Measured performance of the Network Time Protocol in the
Internet system
1119:: S:: Network Time Protocol version 2 specification and
implementation
1059:: :: Network Time Protocol version 1 specification and
implementation
958:: :: Network Time Protocol NTP
957:: :: Experiments in network clock synchronization
956:: :: Algorithms for synchronizing network clocks
868:: S:: Time Protocol
867:: S:: Daytime Protocol
778:: H:: DCNET Internet Clock Service
738:: :: Time server
29:: :: Response to RFC 28
28:: :: Time standards
=====================================================================
Name Serving
2053:: I:: The AM (Armenia) Domain
2052:: E:: A DNS RR for specifying the location of services (DNS SRV)
2010:: I:: Operational Criteria for Root Name Servers
1996:: PS:: A Mechanism for Prompt Notification of Zone Changes
(DNS NOTIFY)
1995:: PS:: Incremental Zone Transfer in DNS
1982:: PS:: Serial Number Arithmetic
1956:: I:: Registration in the MIL Domain
1912:: I:: Common DNS Operational and Configuration Errors
1886:: PS:: DNS Extensions to support IP version 6
1876:: E:: A Means for Expressing Location Information in the
Domain Name System
1794:: I:: DNS Support for Load Balancing
1713:: I:: Tools for DNS debugging
1712:: E:: DNS Encoding of Geographical Location
1706:: I:: DNS NSAP Resource Records
1664:: E:: Using the Internet DNS to Distribute RFC1327 Mail
Address Mapping Tables
1591:: I:: Domain Name System Structure and Delegation
1537:: I:: Common DNS Data File Configuration Error
1536:: I:: Common DNS Implementation Errors and Suggested Fixes.
1480:: I:: The US Domain
1464:: E:: Using the Domain Name System To Store Arbitrary
String Attributes
1394:: I:: Relationship of Telex Answerback Codes to Internet Domains
1386:: I:: The US Domain
1348:: E:: DNS NSAP RRs
1183:: E:: New DNS RR Definitions
1101:: :: DNS encoding of network names and other types
1035:: S:: Domain names - implementation and specification
1034:: S:: Domain names - concepts and facilities
1033:: :: Domain administrators operations guide
1032:: :: Domain administrators guide
1031:: :: MILNET name domain transition
973:: :: Domain system changes and observations
952:: :: DoD Internet host table specification
921:: :: Domain name system implementation schedule - revised
920:: :: Domain requirements
897:: :: Domain name system implementation schedule
883:: :: Domain names
882:: :: Domain names
881:: :: Domain names plan and schedule
849:: :: Suggestions for improved host table distribution
830:: :: Distributed system for Internet name service
819:: :: Domain naming convention for Internet user applications
811:: :: Hostnames Server
810:: :: DoD Internet host table specification
799:: :: Internet name domains
796:: :: Address mappings
627:: :: ASCII text file of hostnames
625:: :: On-line hostnames service
623:: :: Comments on on-line host name service
620:: :: Request for monitor host table updates
608:: :: Host names on-line
606:: :: Host names on-line
289:: :: What we hope is an official list of host names
280:: :: Draft of host names
273:: :: More on standard host names
247:: :: Proffered set of standard host names
237:: :: NIC view of standard host names
236:: :: Standard host names
233:: :: Standardization of host call letters
229:: :: Standard host names
226:: :: Standardization of host mnemonics
=====================================================================
Network Management
2128:: PS:: Dial Control Management Information Base using SMIv2
2127:: PS:: ISDN Management Information Base
2124:: I:: Light-weight Flow Admission Protocol Specification
Version 1.0
2108:: PS:: Definitions of Managed Objects for IEEE 802.3 Repeater
Devices using SMIv2
2096:: PS:: IP Forwarding Table MIB
2089:: I:: V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual
SNMP agent
2074:: PS:: Remote Network Monitoring MIB Protocol Identifiers
2064:: E:: Traffic Flow Measurement
2063:: E:: Traffic Flow Measurement
2051:: PS:: Definitions of Managed Objects for APPC
2041:: I:: Mobile Network Tracing
2039:: I:: Applicability of Standards Track MIBs to Management
of World Wide Web Servers
2037:: PS:: Entity MIB
2024:: PS:: Definitions of Managed Objects for Data Link Switching
using SNMPv2
2021:: PS:: Remote Network Monitoring Management Information
Base Version 2 using SMIv2
2020:: PS:: Definitions of Managed Objects for IEEE 802.12 Interfaces
2013:: PS:: SNMPv2 Management Information Base for the User
Datagram Protocol using SMIv2
2012:: PS:: SNMPv2 Management Information Base for the
Transmission Control Protocol
2011:: PS:: SNMPv2 Management Information Base for the Internet
Protocol using SMIv2
2006:: PS:: The Definitions of Managed Objects for IP Mobility
Support using SMIv2
1944:: I:: Benchmarking Methodology for Network Interconnect Devices
1910:: E:: User-based Security Model for SNMPv2
1909:: E:: An Administrative Infrastructure for SNMPv2
1908:: DS:: Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework
1907:: DS:: Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)
1906:: DS:: Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)
1905:: DS:: Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)
1904:: DS:: Conformance Statements for Version 2 of the Simple
Network Management Protocol (SNMPv2)
1903:: DS:: Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)
1902:: DS:: Structure of Management Information for Version 2 of
the Simple Network Management Protocol (SNMPv2)
1901:: E:: Introduction to Community-based SNMPv2
1857:: I:: A Model for Common Operational Statistics
1856:: I:: The Opstat Client-Server Model for Statistics Retrieval
1850:: DS:: OSPF Version 2 Management Information Base
1792:: E:: TCP/IPX Connection Mib Specification
1759:: PS:: Printer MIB
1757:: DS:: Remote Network Monitoring Management Information Base
1749:: PS:: IEEE 802.5 Station Source Routing MIB using SMIv2
1748:: DS:: IEEE 802.5 MIB using SMIv2
1747:: PS:: Definitions of Managed Objects for SNA Data Link Control
1743:: DS:: IEEE 802.5 MIB using SMIv2
1742:: PS:: AppleTalk Management Information Base II
1724:: DS:: RIP Version 2 MIB Extension
1697:: PS:: Relational Database Management System (RDBMS)
Management Information Base (MIB) using SMIv2
1696:: PS:: Modem Management Information Base (MIB) using SMIv2
1695:: PS:: Definitions of Managed Objects for ATM Management
Version 8.0 using SMIv2
1694:: DS:: Definitions of Managed Objects for SMDS Interfaces
using SMIv2
1666:: PS:: Definitions of Managed Objects for SNA NAUs using SMIv2
1665:: PS:: Definitions of Managed Objects for SNA NAUs using SMIv2
1660:: DS:: Definitions of Managed Objects for Parallel-printer-like
Hardware Devices using SMIv2
1659:: DS:: Definitions of Managed Objects for RS-232-like
Hardware Devices using SMIv2
1658:: DS:: Definitions of Managed Objects for Character Stream
Devices using SMIv2
1657:: PS:: Definitions of Managed Objects for the Fourth Version
of the Border Gateway Protocol (BGP-4) using SMIv2
1650:: PS:: Definitions of Managed Objects for the Ethernet-like
Interface Types using SMIv2
1643:: PS:: Definitions of Managed Objects for the Ethernet-like
Interface Types
1628:: PS:: UPS Management Information Base
1623:: S:: Definitions of Managed Objects for the Ethernet-like
Interface Types
1612:: PS:: DNS Resolver MIB Extensions
1611:: PS:: DNS Server MIB Extensions
1596:: PS:: Definitions of Managed Objects for Frame Relay Service
1595:: PS:: Definitions of Managed Objects for the SONET/SDH
Interface Type
1593:: I:: SNA APPN Node MIB
1592:: E:: Simple Network Management Protocol Distributed Protocol
Interface Version 2.0
1573:: PS:: Evolution of the Interfaces Group of MIB-II
1567:: PS:: X.500 Directory Monitoring MIB
1566:: PS:: Mail Monitoring MIB
1565:: PS:: Network Services Monitoring MIB
1564:: I:: DSA Metrics (OSI-DS 34 (v3))
1559:: DS:: DECnet Phase IV MIB Extensions
1525:: PS:: Definitions of Managed Objects for Source Routing Bridges
1516:: DS:: Definitions of Managed Objects for IEEE 802.3
Repeater Devices
1515:: PS:: Definitions of Managed Objects for IEEE 802.3
Medium Attachment Units (MAUs)
1514:: PS:: Host Resources MIB
1513:: PS:: Token Ring Extensions to the Remote Network Monitoring MIB
1512:: PS:: FDDI Management Information Base
1503:: I:: Algorithms for Automating Administration in SNMPv2
Managers
1493:: DS:: Definitions of Managed Objects for Bridges
1474:: PS:: The Definitions of Managed Objects for the Bridge
Network Control Protocol of the Point-to-Point Protocol
1473:: PS:: The Definitions of Managed Objects for the IP Network
Control Protocol of the Point-to-Point Protocol
1472:: PS:: The Definitions of Managed Objects for the Security
Protocols of the Point-to-Point Protocol
1471:: PS:: The Definitions of Managed Objects for the Link Control
Protocol of the Point-to-Point Protocol
1470:: I:: FYI on a Network Management Tool Catalog
1461:: PS:: SNMP MIB extension for MultiProtocol Interconnect over
X.25
1452:: PS:: Coexistence between version 1 and version 2 of the
Internet-standard Network Management Framework
1451:: PS:: Manager to Manager Management Information Base
1450:: PS:: Management Information Base for version 2 of the Simple
Network Management Protocol (SNMPv2)
1449:: PS:: Transport Mappings for version 2 of the Simple Network
Management Protocol (SNMPv2)
1448:: PS:: Protocol Operations for version 2 of the Simple Network
Management Protocol (SNMPv2)
1447:: PS:: Party MIB for version 2 of the Simple Network Management
Protocol (SNMPv2)
1446:: PS:: Security Protocols for version 2 of the Simple Network
Management Protocol (SNMPv2)
1445:: PS:: Administrative Model for version 2 of the Simple Network
Management Protocol (SNMPv2)
1444:: PS:: Conformance Statements for version 2 of the Simple
Network Management Protocol (SNMPv2)
1443:: PS:: Textual Conventions for version 2 of the Simple Network
Management Protocol (SNMPv2)
1442:: PS:: Structure of Management Information for version 2 of the
Simple Network Management Protocol (SNMPv2)
1441:: PS:: Introduction to version 2 of the Internet-standard
Network Management Framework
1431:: I:: DUA Metrics
1420:: PS:: SNMP over IPX
1419:: PS:: SNMP over AppleTalk
1418:: PS:: SNMP over OSI
1414:: PS:: Ident MIB
1407:: PS:: Definitions of Managed Objects for the DS3/E3 Interface
Type
1406:: PS:: Definitions of Managed Objects for the DS1 and E1
Interface Types
1404:: I:: A Model for Common Operational Statistics
1398:: DS:: Definitions of Managed Objects for the Ethernet-like
Interface Types
1389:: PS:: RIP Version 2 MIB Extension
1382:: PS:: SNMP MIB Extension for the X.25 Packet Layer
1381:: PS:: SNMP MIB Extension for X.25 LAPB
1369:: I:: Implementation Notes and Experience for The Internet
Ethernet MIB
1368:: PS:: Definitions of Managed Objects for IEEE 802.3 Repeater
Devices
1354:: PS:: IP Forwarding Table MIB
1353:: H:: Definitions of Managed Objects for Administration of
SNMP Parties
1352:: H:: SNMP Security Protocols
1351:: H:: SNMP Administrative Model
1346:: I:: "Resource Allocation, Control, and Accounting for the
Use of Network Resources"
1318:: PS:: Definitions of Managed Objects for Parallel-printer-like
Hardware Devices
1317:: PS:: Definitions of Managed Objects for RS-232-like
Hardware Devices
1316:: PS:: Definitions of Managed Objects for Character Stream
Devices
1315:: PS:: Management Information Base for Frame Relay DTEs
1304:: PS:: Definitions of Managed Objects for the SIP Interface Type
1303:: I:: A Convention for Describing SNMP-based Agents
1298:: I:: SNMP over IPX
1289:: PS:: DECnet Phase IV MIB Extensions
1286:: PS:: Definitions of Managed Objects for Bridges
1285:: PS:: FDDI Management Information Base
1284:: PS:: Definitions of Managed Objects for the Ethernet-like
Interface Types
1283:: E:: SNMP over OSI
1273:: I:: "A Measurement Study of Changes in Service-Level
Reachability in the Global TCP/IP Internet
1272:: I:: Internet Accounting
1271:: PS:: Remote Network Monitoring Management Information Base
1270:: I:: SNMP Communications Services
1269:: PS:: Definitions of Managed Objects for the Border Gateway
Protocol (Version 3)
1262:: :: Guidelines for Internet Measurement Activities
1253:: PS:: OSPF Version 2 Management Information Base
1252:: PS:: OSPF Version 2 Management Information Base
1248:: PS:: OSPF Version 2 Management Information Base
1247:: DS:: OSPF Version 2
1243:: PS:: AppleTalk Management Information Base
1242:: I:: Benchmarking Terminology for Network Interconnection
Devices
1239:: PS:: Reassignment of Experimental MIBs to Standard MIBs
1238:: E:: CLNS MIB - for use with Connectionless Network
Protocol (ISO 8473) and End System to Intermediate
System (ISO 9542)
1233:: H:: Definitions of Managed Objects for the DS3 Interface Type
1232:: H:: Definitions of Managed Objects for the DS1 Interface Type
1231:: DS:: IEEE 802.5 Token Ring MIB
1230:: H:: IEEE 802.4 Token Bus MIB
1229:: DS:: Extensions to the Generic-Interface MIB
1228:: E:: SNMP-DPI - Simple Network Management Protocol
Distributed Program Interface
1227:: E:: SNMP MUX Protocol and MIB
1224:: E:: Techniques for Managing Asynchronously Generated Alerts
1215:: I:: A Convention for Defining Traps for use with the SNMP
1214:: H:: OSI Internet Management
1213:: S:: Management Information Base for Network Management of
TCP/IP-based internets
1212:: S:: Concise MIB Definitions
1189:: H:: The Common Management Information Services and Protocols
for the Internet
1187:: E:: Bulk Table Retrieval with the SNMP
1161:: E:: SNMP over OSI
1158:: PS:: Management Information Base for Network Management of
TCP/IP-based internets
1157:: S:: A Simple Network Management Protocol (SNMP)
1155:: S:: Structure and Identification of Management Information
for TCP/IP-based Internets
1109:: :: Report of the second Ad Hoc Network Management Review
Group
1098:: :: Simple Network Management Protocol SNMP
1095:: DS:: Common Management Information Services and Protocol
over TCP/IP CMOT
1089:: :: SNMP over Ethernet
1067:: :: Simple Network Management Protocol
1066:: H:: Management Information Base for network management of
TCP/IP-based internets
1065:: H:: Structure and identification of management information
for TCP/IP-based internets
1052:: :: IAB recommendations for the development of Internet
network management standards
1028:: H:: Simple Gateway Monitoring Protocol
1024:: :: HEMS variable definitions
1023:: :: HEMS monitoring and control language
1022:: :: High-level Entity Management Protocol HEMP
1021:: H:: High-level Entity Management System HEMS
1012:: :: Bibliography of Request For Comments 1 through 999
1011:: S:: Official Internet protocols
1010:: S:: Assigned numbers
996:: H:: Statistics server
619:: :: Mean round-trip times in the ARPANET
618:: :: Few observations on NCP statistics
616:: :: Latest network maps
615:: :: Proposed Network Standard Data Pathname Syntax
612:: :: Traffic statistics December 1973
601:: :: Traffic statistics November 1973
586:: :: Traffic statistics October 1973
579:: :: Traffic statistics September 1973
568:: :: Response to RFC 567 - cross country network bandwidth
567:: :: Cross country network bandwidth
566:: :: Traffic statistics August 1973
565:: :: Storing network survey data at the datacomputer
557:: :: Revelations in network host measurements
546:: :: Tenex load averages for July 1973
545:: :: Of what quality be the UCSB resources evaluators?
538:: :: Traffic statistics June 1973
531:: :: Feast or famine? A response to two recent RFC's about
network information
522:: :: Traffic statistics May 1973
509:: :: Traffic statistics April 1973
500:: :: Integration of data management systems on a computer
network
482:: :: Traffic statistics February 1973
455:: :: Traffic statistics January 1973
443:: :: Traffic statistics December 1972
423:: :: UCLA Campus Computing Network liaison staff for ARPANET
422:: :: Traffic statistics November 1972
421:: :: Software consulting service for network users
416:: :: ARC system will be unavailable for use during
Thanksgivingweek 
415:: :: Tenex bandwidth
413:: :: Traffic statistics October 1972
400:: :: Traffic statistics September 1972
392:: :: Measurement of host costs for transmitting network data
391:: :: Traffic statistics August 1972
389:: :: UCLA Campus Computing Network liaison staff for ARPA
Network
388:: :: NCP statistics
384:: :: Official site idents for organizations in the ARPA
Network
381:: :: Three aids to improved network operation
378:: :: Traffic statistics July 1972
369:: :: "Evaluation of ARPANET services January-March, 1972"
362:: :: Network host status
353:: :: Network host status
344:: :: Network host status
326:: :: Network host status
323:: :: Formation of Network Measurement Group NMG
308:: :: ARPANET host availability data
304:: :: Data management system proposal for the ARPA network
302:: :: Exercising the ARPANET
274:: :: Establishing a local guide for network usage
227:: :: Data transfer rates Rand/UCLA
212:: :: NWG meeting on network usage
193:: :: Network checkout
188:: :: Data management meeting announcement
156:: :: Status of the Illinois site
153:: :: SRI ARC-NIC status
96:: :: Interactive network experiment to study modes of
access tothe Network Information Center
32:: :: Connecting M.I.T. computers to the
ARPA Computer-to-computer communication network
18:: :: [Link assignments]
======================================================================
Network News
1036:: :: Standard for interchange of USENET messages
977:: PS:: Network News Transfer Protocol
850:: :: Standard for interchange of USENET messages
===================================================================
Real Time Services
:: ::
2102:: I:: Multicast Support for Nimrod
2090:: E:: TFTP Multicast Option
2038:: PS:: RTP Payload Format for MPEG1/MPEG2 Video
2035:: PS:: RTP Payload Format for JPEG-compressed Video
2032:: PS:: RTP payload format for H.261 video streams
2029:: PS:: RTP Payload Format of Sun's CellB Video Encoding
2022:: PS:: Support for Multicast over UNI 3.0/3.1 based ATM
Networks
1890:: PS:: RTP Profile for Audio and Video Conferences with Minimal
Control
1889:: PS:: RTP
1861:: I:: Simple Network Paging Protocol - Version 3 - Two-Way
Enhanced
1821:: I:: Integration of Real-time Services in an IP-ATM Network
Architecture
1819:: E:: Internet Stream Protocol Version 2 (ST2) Protocol
Specification - Version ST2+
1789:: I:: INETPhone
1768:: E:: Host Group Extensions for CLNP Multicasting
1703:: I:: Principles of Operation for the TPC.INT Subdomain
1645:: I:: Simple Network Paging Protocol - Version 2
1614:: I:: Network Access to Multimedia Information
1569:: I:: Principles of Operation for the TPC.INT Subdomain
1568:: I:: Simple Network Paging Protocol - Version 1(b)
1546:: I:: Host Anycasting Service
1469:: PS:: IP Multicast over Token-Ring Local Area Networks
1458:: I:: Requirements for Multicast Protocols
1453:: I:: A Comment on Packet Video Remote Conferencing and the
Transport/Network Layers
1313:: I:: Today's Programming for KRFC AM 1313 Internet Talk Radio
1301:: I:: Multicast Transport Protocol
1257:: I:: Isochronous Applications Do Not Require
Jitter-Controlled Networks
1197:: I:: Using ODA for Translating Multimedia Information
1193:: :: Client Requirements for Real-Time Communication Services
1190:: E:: "Experimental Internet Stream Protocol, Version 2 (ST-II)"
1112:: S:: Host extensions for IP multicasting
1054:: :: Host extensions for IP multicasting
988:: :: Host extensions for IP multicasting
966:: :: Host groups
947:: :: Multi-network broadcasting within the Internet
809:: :: UCL facsimile system
804:: :: CCITT draft recommendation T.4 [Standardization of
Group 3 facsimile apparatus for document transmission]
803:: :: Dacom 450/500 facsimile data transcoding
798:: :: Decoding facsimile data from the Rapicom 450
769:: :: Rapicom 450 facsimile file format
741:: :: Specifications for the Network Voice Protocol NVP
511:: :: Enterprise phone service to NIC from ARPANET sites
508:: :: Real-time data transmission on the ARPANET
420:: :: CCA ICCC weather demo
408:: :: NETBANK
251:: :: Weather data
=====================================================================
Routing
2103:: I:: Mobility Support for Nimrod
2092:: I:: Protocol Analysis for Triggered RIP
2091:: PS:: Triggered Extensions to RIP to Support Demand Circuits
2081:: I:: RIPng Protocol Applicability Statement
2080:: PS:: RIPng for IPv6
2073:: PS:: An IPv6 Provider-Based Unicast Address Format
2072:: I:: Router Renumbering Guide
2042:: I:: Registering New BGP Attribute Types
2008:: BC:: Implications of Various Address Allocation Policies for
Internet Routing
1998:: I:: An Application of the BGP Community Attribute in
Multi-home Routing
1997:: PS:: BGP Communities Attribute
1992:: I:: The Nimrod Routing Architecture
1987:: I:: Ipsilon's General Switch Management Protocol
Specification Version 1.1
1966:: E:: BGP Route Reflection An alternative to full mesh IBGP
1965:: E:: Autonomous System Confederations for BGP
1955:: I:: New Scheme for Internet Routing and Addressing (ENCAPS)
for IPN
1953:: I:: Ipsilon Flow Management Protocol Specification for
IPv4 Version 1.0
1940:: I:: Source Demand Routing
1930:: BC:: "Guidelines for creation, selection, and registration
of an Autonomous System (AS)"
1925:: I:: The Twelve Networking Truths
1923:: I:: RIPv1 Applicability Statement for Historic Status
1863:: E:: A BGP/IDRP Route Server alternative to a full mesh routing
1817:: I:: CIDR and Classful Routing
1812:: PS:: Requirements for IP Version 4 Routers
1793:: PS:: Extending OSPF to Support Demand Circuits
1787:: I:: Routing in a Multi-provider Internet
1786:: I:: Representation of IP Routing Policies in a Routing Registry (ripe-81++)
1774:: I:: BGP-4 Protocol Analysis
1773:: I:: Experience with the BGP-4 protocol
1772:: DS:: Application of the Border Gateway Protocol in the Internet
1771:: DS:: A Border Gateway Protocol 4 (BGP-4)
1765:: E:: OSPF Database Overflow
1753:: I:: IPng Technical Requirements Of the Nimrod Routing and
Addressing Architecture
1745:: PS:: BGP4/IDRP for IP---OSPF Interaction
1723:: DS:: RIP Version 2 Carrying Additional Information
1722:: DS:: RIP Version 2 Protocol Applicability Statement
1721:: I:: RIP Version 2 Protocol Analysis
1716:: I:: Towards Requirements for IP Routers
1702:: I:: Generic Routing Encapsulation over IPv4 networks
1701:: I:: Generic Routing Encapsulation (GRE)
1668:: I:: Unified Routing Requirements for IPng
1656:: I:: BGP-4 Protocol Document Roadmap and Implementation
Experience
1655:: PS:: Application of the Border Gateway Protocol in the
Internet
1654:: PS:: A Border Gateway Protocol 4 (BGP-4)
1587:: PS:: The OSPF NSSA Option
1586:: I:: Guidelines for Running OSPF Over Frame Relay Networks
1585:: I:: MOSPF
1584:: PS:: Multicast Extensions to OSPF
1583:: DS:: OSPF Version 2
1582:: PS:: Extensions to RIP to Support Demand Circuits
1581:: I:: Protocol Analysis for Extensions to RIP to Support
Demand Circuits
1520:: I:: Exchanging Routing Information Across Provider Boundaries
in the CIDR Environment
1519:: PS:: Classless Inter-Domain Routing (CIDR)
1517:: PS:: Applicability Statement for the Implementation of
Classless Inter-Domain Routing (CIDR)
1504:: I:: Appletalk Update-Based Routing Protocol
1482:: I:: Aggregation Support in the NSFNET Policy Routing Database
1479:: PS:: Inter-Domain Policy Routing Protocol Specification
1478:: PS:: An Architecture for Inter-Domain Policy Routing
1477:: I:: IDPR as a Proposed Standard
1476:: E:: RAP
1439:: I:: The Uniqueness of Unique Identifiers
1403:: PS:: BGP OSPF Interaction
1397:: PS:: Default Route Advertisement In BGP2 And BGP3 Versions Of
The Border Gateway Protocol
1388:: PS:: RIP Version 2 Carrying Additional Information
1387:: I:: RIP Version 2 Protocol Analysis
1383:: I:: An Experiment in DNS Based IP Routing
1380:: I:: IESG Deliberations on Routing and Addressing
1371:: I:: "Choosing a ""Common IGP"" for the IP Internet (The
IESG's Recommendation to the IAB)"
1370:: PS:: Applicability Statement for OSPF
1364:: PS:: BGP OSPF Interaction
1338:: I:: Supernetting
1322:: I:: A Unified Approach to Inter-Domain Routing
1268:: DS:: Application of the Border Gateway Protocol in the Internet
1267:: DS:: A Border Gateway Protocol 3 (BGP-3)
1266:: I:: Experience with the BGP Protocol
1265:: I:: BGP Protocol Analysis
1264:: I:: Internet Routing Protocol Standardization Criteria
1254:: I:: Gateway Congestion Control Survey
1246:: I:: Experience with the OSPF Protocol
1245:: I:: OSPF Protocol Analysis
1222:: :: Advancing the NSFNET Routing Architecture
1195:: PS:: Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments
1164:: PS:: Application of the Border Gateway Protocol in the Internet
1163:: PS:: A Border Gateway Protocol (BGP)
1142:: I:: OSI IS-IS Intra-domain Routing Protocol
1136:: :: Administrative Domains and Routing Domains
1133:: :: Routing between the NSFNET and the DDN
1131:: PS:: OSPF specification
1126:: :: Goals and functional requirements for inter-autonomous
system routing
1125:: :: Policy requirements for inter Administrative Domain
routing
1124:: :: Policy issues in interconnecting networks
1105:: E:: Border Gateway Protocol BGP
1104:: :: Models of policy based routing
1102:: :: Policy routing in Internet protocols
1092:: :: EGP and policy based routing in the new NSFNET backbone
1075:: E:: Distance Vector Multicast Routing Protocol
1074:: :: NSFNET backbone SPF based Interior Gateway Protocol
1058:: S:: Routing Information Protocol
1009:: H:: Requirements for Internet gateways
995:: :: End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473
985:: :: Requirements for Internet gateways - draft
981:: :: Experimental multiple-path routing algorithm
975:: :: Autonomous confederations
950:: S:: Internet standard subnetting procedure
911:: :: EGP Gateway under Berkeley UNIX 4.2
904:: H:: Exterior Gateway Protocol formal specification
898:: :: Gateway special interest group meeting notes
890:: :: Exterior Gateway Protocol implementation schedule
888:: :: STUB Exterior Gateway Protocol
875:: :: "Gateways, architectures, and heffalumps"
827:: :: Exterior Gateway Protocol EGP
823:: H:: DARPA Internet gateway
=====================================================================
Security
2104:: I:: HMAC
2085:: PS:: HMAC-MD5 IP Authentication with Replay Prevention
2084:: I:: Considerations for Web Transaction Security
2082:: PS:: RIP-2 MD5 Authentication
2078:: PS:: "Generic Security Service Application Program Interface,
Version 2"
2069:: PS:: An Extension to HTTP
2065:: PS:: Domain Name System Security Extensions
2059:: I:: RADIUS Accounting
2058:: PS:: Remote Authentication Dial In User Service (RADIUS)
2057:: I:: Source directed access control on the Internet.
2040:: I:: "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms"
2025:: PS:: The Simple Public-Key GSS-API Mechanism (SPKM)
2015:: :: MIME Security with Pretty Good Privacy (PGP)
1984:: I:: IAB and IESG Statement on Cryptographic Technology and
the Internet
1969:: I:: The PPP DES Encryption Protocol (DESE)
1968:: PS:: The PPP Encryption Control Protocol (ECP)
1964:: PS:: The Kerberos Version 5 GSS-API Mechanism
1961:: PS:: GSS-API Authentication Method for SOCKS Version 5
1949:: E:: Scalable Multicast Key Distribution
1948:: I:: Defending Against Sequence Number Attacks
1938:: PS:: A One-Time Password System
1929:: PS:: Username/Password Authentication for SOCKS V5
1928:: PS:: SOCKS Protocol Version 5
1898:: I:: CyberCash Credit Card Protocol Version 0.8
1858:: I:: Security Considerations for IP Fragment Filtering
1852:: E:: IP Authentication using Keyed SHA
1851:: E:: The ESP Triple DES-CBC Transform
1829:: PS:: The ESP DES-CBC Transform
1828:: PS:: IP Authentication using Keyed MD5
1827:: PS:: IP Encapsulating Security Payload (ESP)
1826:: PS:: IP Authentication Header
1825:: PS:: Security Architecture for the Internet Protocol
1824:: I:: The Exponential Security System TESS
1760:: I:: The S/KEY One-Time Password System
1751:: I:: A Convention for Human-Readable 128-bit Keys
1750:: I:: Randomness Recommendations for Security
1704:: I:: On Internet Authentication
1675:: I:: Security Concerns for IPng
1579:: I:: Firewall-Friendly FTP
1535:: I:: A Security Problem and Proposed Correction With Widely
Deployed DNS Software
1511:: I:: Common Authentication Technology Overview
1510:: PS:: The Kerberos Network Authentication Service (V5)
1509:: PS:: Generic Security Service API
1508:: PS:: Generic Security Service Application Program Interface
1507:: E:: DASS - Distributed Authentication Security Service
1492:: I:: "An Access Control Protocol, Sometimes Called TACACS"
1457:: I:: Security Label Framework for the Internet
1455:: E:: Physical Link Security Type of Service
1424:: PS:: Privacy Enhancement for Internet Electronic Mail
1423:: PS:: "Privacy Enhancement for Internet Electronic Mail
1422:: PS:: Privacy Enhancement for Internet Electronic Mail
1421:: PS:: Privacy Enhancement for Internet Electronic Mail
1416:: E:: Telnet Authentication Option
1412:: E:: Telnet Authentication
1411:: E:: Telnet Authentication
1409:: E:: Telnet Authentication Option
1408:: H:: Telnet Environment Option
1321:: I:: The MD5 Message-Digest Algorithm
1320:: I:: The MD4 Message-Digest Algorithm
1319:: I:: The MD2 Message-Digest Algorithm
1281:: I:: Guidelines for the Secure Operation of the Internet
1244:: I:: Site Security Handbook
1186:: I:: The MD4 Message Digest Algorithm
1170:: I:: Public Key Standards and Licenses
1156:: S:: Management Information Base for Network Management of
TCP/IP-based internets
1115:: H:: "Privacy enhancement for Internet electronic mail
1114:: H:: Privacy enhancement for Internet electronic mail
1113:: H:: Privacy enhancement for Internet electronic mail
1108:: PS:: U.S. Department of Defense Security Options for the
Internet Protocol
1040:: :: Privacy enhancement for Internet electronic mail
1038:: :: Draft revised IP security option
1004:: E:: Distributed-protocol authentication scheme
989:: :: Privacy enhancement for Internet electronic mail
972:: :: Password Generator Protocol
931:: E:: Authentication server
927:: :: TACACS user identification Telnet option
912:: :: Authentication service
644:: :: On the problem of signature authentication for
network mail
=====================================================================
Virtual Terminal
2066:: E:: TELNET CHARSET Option
1647:: PS:: TN3270 Enhancements
1646:: I:: TN3270 Extensions for LUname and Printer Selection
1576:: I:: TN3270 Current Practices
1572:: PS:: Telnet Environment Option
1571:: I:: Telnet Environment Option Interoperability Issues
1372:: PS:: Telnet Remote Flow Control Option
1282:: I:: BSD Rlogin
1258:: I:: BSD Rlogin
1221:: :: Host Access Protocol (HAP) Specification - Version 2
1205:: :: 5250 Telnet Interface
1184:: DS:: Telnet Linemode Option
1143:: :: The Q Method of Implementing TELNET Option Negotiation
1116:: PS:: Telnet Linemode option
1097:: :: Telnet subliminal-message option
1096:: :: Telnet X display location option
1091:: :: Telnet terminal-type option
1080:: :: Telnet remote flow control option
1079:: :: Telnet terminal speed option
1073:: :: Telnet window size option
1053:: :: Telnet X.3 PAD option
1043:: :: Telnet Data Entry Terminal option
1041:: :: Telnet 3270 regime option
1013:: :: "X Window System Protocol, version 11
1005:: :: ARPANET AHIP-E Host Access Protocol enhanced AHIP
946:: :: Telnet terminal location number option
933:: :: Output marking Telnet option
930:: :: Telnet terminal type option
929:: :: Proposed Host-Front End Protocol
907:: S:: Host Access Protocol specification
885:: :: Telnet end of record option
884:: :: Telnet terminal type option
878:: :: ARPANET 1822L Host Access Protocol
861:: :: Telnet extended options
860:: S:: Telnet timing mark option
859:: S:: Telnet status option
858:: S:: Telnet Suppress Go Ahead option
857:: S:: Telnet echo option
856:: S:: Telnet binary transmission
855:: S:: Telnet option specifications
854:: S:: Telnet Protocol specification
851:: :: ARPANET 1822L Host Access Protocol
818:: H:: Remote User Telnet service
802:: :: ARPANET 1822L Host Access Protocol
782:: :: Virtual Terminal management model
779:: :: Telnet send-location option
764:: :: Telnet Protocol specification
749:: :: Telnet SUPDUP-Output option
748:: :: Telnet randomly-lose option
747:: :: Recent extensions to the SUPDUP Protocol
746:: :: SUPDUP graphics extension
736:: :: Telnet SUPDUP option
735:: :: Revised Telnet byte macro option
734:: H:: SUPDUP Protocol
732:: :: Telnet Data Entry Terminal option
731:: :: Telnet Data Entry Terminal option
729:: :: Telnet byte macro option
728:: :: Minor pitfall in the Telnet Protocol
727:: :: Telnet logout option
726:: :: Remote Controlled Transmission and Echoing Telnet option
721:: :: Out-of-band control signals in a Host-to-Host Protocol
719:: :: Discussion on RCTE
718:: :: Comments on RCTE from the Tenex implementation experience
703:: :: "July, 1975, survey of New-Protocol Telnet Servers"
702:: :: "September, 1974, survey of New-Protocol Telnet servers"
701:: :: "August, 1974, survey of New-Protocol Telnet servers"
698:: :: Telnet extended ASCII option
688:: :: Tentative schedule for the new Telnet implementation for
the TIP
679:: :: "February, 1975, survey of New-Protocol Telnet servers"
669:: :: "November, 1974, survey of New-Protocol Telnet servers"
659:: :: Announcing additional Telnet options
658:: :: Telnet output linefeed disposition
657:: :: Telnet output vertical tab disposition option
656:: :: Telnet output vertical tabstops option
655:: :: Telnet output formfeed disposition option
654:: :: Telnet output horizontal tab disposition option
653:: :: Telnet output horizontal tabstops option
652:: :: Telnet output carriage-return disposition option
651:: :: Revised Telnet status option
647:: :: Proposed protocol for connecting host computers to
ARPA-like networks via front end processors
636:: :: TIP/Tenex reliability improvements
600:: :: Interfacing an Illinois plasma terminal to the ARPANET
596:: :: Second thoughts on Telnet Go-Ahead
595:: :: Second thoughts in defense of the Telnet Go-Ahead
587:: :: Announcing new Telnet options
563:: :: Comments on the RCTE Telnet option
562:: :: Modifications to the Telnet specification
560:: :: Remote Controlled Transmission and Echoing Telnet option
559:: :: Comments on the new Telnet Protocol and its implementation
513:: :: Comments on the new Telnet specifications
495:: :: Telnet Protocol specifications
470:: :: Change in socket for TIP news facility
466:: :: Telnet logger/server for host LL-67
461:: :: Telnet Protocol meeting announcement
447:: :: IMP/TIP memory retrofit schedule
435:: :: Telnet issues
431:: :: Update on SMFS login and logout
399:: :: SMFS login and logout
393:: :: Comments on Telnet Protocol changes
386:: :: Letter to TIP users-2
377:: :: Using TSO via ARPA Network Virtual Terminal
365:: :: Letter to all TIP users
364:: :: Serving remote users on the ARPANET
352:: :: TIP site information form
340:: :: Proposed Telnet changes
339:: :: "MLTNET
328:: :: Suggested Telnet Protocol changes
318:: :: [Ad hoc Telnet Protocol]
311:: :: New console attachments to the USCB host
297:: :: TIP message buffers
296:: :: DS-1 display system
231:: :: Service center standards for remote usage
230:: :: Toward reliable operation of minicomputer-based
terminals on a TIP
216:: :: Telnet access to UCSB's On-Line System
215:: :: "NCP, ICP, and Telnet
206:: :: User Telnet - description of an initial implementation
205:: :: NETCRT - a character display protocol
177:: :: Device independent graphical display description
158:: :: Telnet Protocol
139:: :: Discussion of Telnet Protocol
137:: :: Telnet Protocol - a proposed document
110:: :: Conventions for using an IBM 2741 terminal as a
user console for access to network server hosts
97:: :: First cut at a proposed Telnet Protocol
=====================================================================
Other
2123:: I:: Traffic Flow Measurement
2121:: I:: Issues affecting MARS Cluster Size
2119:: BC:: Key words for use in RFCs to Indicate Requirement Levels
2101:: I:: IPv4 Address Behaviour Today
2100:: I:: The Naming of Hosts
2099:: I:: Request for Comments Summary RFC Numbers 2000-2099
2083:: I:: PNG (Portable Network Graphics) Specification Version 1.0
2071:: I:: Network Renumbering Overview
2050:: BC:: INTERNET REGISTRY IP ALLOCATION GUIDELINES
2036:: I:: Observations on the use of Components of the Class
A Address Space within the Internet
2031:: I:: IETF-ISOC relationship
2028:: BC:: The Organizations Involved in the IETF Standards Process
2027:: BC:: "IAB and IESG Selection, Confirmation, and Recall Process
2026:: BC:: The Internet Standards Process -- Revision 3
2014:: BC:: IRTF Research Group Guidelines and Procedures
2007:: I:: Catalogue of Network Training Materials
2000:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1999:: I:: Request for Comments Summary RFC Numbers 1900-1999
1988:: I:: Conditional Grant of Rights to Specific Hewlett-Packard
Patents In Conjunction With the Internet Engineering
Task Force's Internet-Standard Network Management
Framework
1983:: I:: Internet Users' Glossary
1958:: I:: Architectural Principles of the Internet
1952:: I:: GZIP file format specification version 4.3
1951:: I:: DEFLATE Compressed Data Format Specification version 1.3
1950:: I:: ZLIB Compressed Data Format Specification version 3.3
1941:: I:: Frequently Asked Questions for Schools
1935:: I:: "What is the Internet, Anyway?"
1920:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1900:: I:: Renumbering Needs Work
1899:: I:: Request for Comments Summary RFC Numbers 1800-1899
1882:: I:: The 12-Days of Technology Before Christmas
1880:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1879:: I:: Class A Subnet Experiment Results and Recommendations
1875:: I:: UNINETT PCA Policy Statements
1871:: BC:: Addendum to RFC 1602 -- Variance Procedure
1855:: I:: Netiquette Guidelines
1822:: I:: A Grant of Rights to Use a Specific IBM patent with
Photuris
1818:: S:: Best Current Practices
1816:: I:: U.S. Government Internet Domain Names
1814:: I:: Unique Addresses are Good
1811:: I:: U.S. Government Internet Domain Names
1810:: I:: Report on MD5 Performance
1805:: I:: Location-Independent Data/Software Integrity Protocol
1802:: I:: Introducing Project Long Bud
1800:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1799:: I:: Request for Comments Summary RFC Numbers 1700-1799
1797:: E:: Class A Subnet Experiment
1796:: I:: Not All RFCs are Standards
1790:: I:: "An Agreement between the Internet Society and Sun
Microsystems, Inc. in the Matter of ONC RPC and
XDR Protocols"
1780:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1776:: I:: The Address is the Message
1775:: I:: "To Be ""On"" the Internet"
1758:: I:: NADF Standing Documents
1746:: I:: Ways to Define User Expectations
1739:: I:: A Primer On Internet and TCP/IP Tools
1720:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1718:: I:: The Tao of IETF - A Guide for New Attendees of the
Internet Engineering Task Force
1715:: I:: The H Ratio for Address Assignment Efficiency
1709:: I:: K-12 Internetworking Guidelines
1700:: S:: ASSIGNED NUMBERS
1699:: I:: Request for Comments Summary RFC Numbers 1600-1699
1691:: I:: The Document Architecture for the Cornell Digital Library
1690:: I:: Introducing the Internet Engineering and Planning
Group (IEPG)
1689:: I:: A Status Report on Networked Information Retrieval
1640:: I:: The Process for Organization of Internet Standards
Working Group (POISED)
1636:: I:: "Report of IAB Workshop on Security in the Internet
Architecture - February 8-10, 1994"
1635:: I:: How to Use Anonymous FTP
1627:: I:: Network 10 Considered Harmful (Some Practices
Shouldn't be Codified)
1610:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1607:: I:: A VIEW FROM THE 21ST CENTURY
1606:: I:: A Historical Perspective On The Usage Of IP Version 9
1603:: I:: IETF Working Group Guidelines and Procedures
1602:: I:: The Internet Standards Process -- Revision 2
1601:: I:: Charter of the Internet Architecture Board (IAB)
1600:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1599:: I:: Request for Comments Summary RFC Numbers 1500 - 1599
1597:: I:: Address Allocation for Private Internets
1594:: I:: FYI on Questions and Answer Answers to Commonly
asked ``New Internet User'' Questions
1580:: I:: Guide to Network Resource Tools
1578:: I:: FYI on Questions and Answers
1574:: I:: Essential Tools for the OSI Internet
1550:: I:: IP
1543:: I:: Instructions to RFC Authors
1540:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1539:: I:: The Tao of IETF - A Guide for New Attendees of the
Internet Engineering Task Force
1527:: I:: What Should We Plan Given the Dilemma of the Network?
1501:: I:: OS/2 User Group
1500:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1499:: I:: Request for Comments Summary RFC Numbers 1400-1499
1481:: I:: IAB Recommendation for an Intermediate Strategy to
Address the Issue of Scaling
1467:: I:: Status of CIDR Deployment in the Internet
1463:: I:: FYI on Introducing the Internet--A Short Bibliography
of Introductory Internetworking Readings for the
Network Novice
1462:: I:: FYI on ``What is the Internet?''
1438:: I:: Internet Engineering Task Force Statements Of
Boredom (SOBs)
1432:: I:: Recent Internet Books
1417:: I:: NADF Standing Documents
1410:: S:: IAB OFFICIAL PROTOCOL STANDARDS
1402:: I:: There's Gold in them thar Networks! Searching for
Treasure in all the Wrong Places
1401:: I:: Correspondence between the IAB and DISA on the use
of DNS throughout the Internet
1399:: I:: Request for Comments Summary RFC Numbers 1300-1399
1396:: I:: The Process for Organization of Internet Standards
Working Group (POISED)
1392:: I:: Internet Users' Glossary
1391:: I:: The Tao of IETF
1367:: I:: Schedule for IP Address Space Management Guidelines
1366:: I:: Guidelines for Management of IP Address Space
1360:: S:: IAB OFFICIAL PROTOCOL STANDARDS
1359:: I:: Connecting to the Internet What Connecting
Institutions Should Anticipate
1358:: I:: Charter of the Internet Architecture Board (IAB)
1349:: PS:: Type of Service in the Internet Protocol Suite
1340:: S:: ASSIGNED NUMBERS
1336:: I:: "Who's Who in the Internet Biographies of IAB,
IESG and IRSG Members"
1325:: I:: FYI on Questions and Answers Answers to Commonly
asked ``New Internet User'' Questions
1324:: I:: A Discussion on Computer Network Conferencing
1311:: I:: Introduction to the STD Notes
1310:: I:: The Internet Standards Process
1300:: I:: Remembrances of Things Past
1299:: I:: Request for Comments Summary RFC Numbers 1200-1299
1297:: I:: NOC Internal Integrated Trouble Ticket System
Functional Specification Wishlist
(``NOC TT REQUIREMENTS'')
1296:: I:: Internet Growth (1981-1991)
1295:: I:: User Bill of Rights for entries and listings in the
Public Directory
1291:: I:: Mid-Level Networks
1290:: I:: There's Gold in them thar Networks! or Searching for
Treasure in all the Wrong Places
1287:: I:: Towards the Future Internet Architecture
1280:: S:: IAB OFFICIAL PROTOCOL STANDARDS
1261:: I:: Transition of NIC Services
1259:: I:: Building The Open Road
1251:: :: "Who's Who in the Internet
1250:: S:: IAB Official Protocol Standards
1249:: I:: DIXIE Protocol Specification
1217:: :: Memo from the Consortium for Slow Commotion Research (CSCR)
1216:: :: Gigabit Network Economics and Paradigm Shifts
1208:: :: A Glossary of Networking Terms
1207:: :: Answers to Commonly asked ``Experienced Internet User''
Questions
1206:: :: FYI on Questions and Answers - Answers to Commonly
asked ``New Internet User'' Questions
1200:: S:: IAB Official Protocol Standards
1199:: I:: Request for Comments Summary RFC Numbers 1100-1199
1198:: I:: FYI on the X Window System
1192:: :: Commercialization of the Internet Summary Report
1181:: :: RIPE Terms of Reference
1180:: :: A TCP/IP Tutorial
1178:: :: Choosing a Name for Your Computer
1177:: :: FYI on Questions and Answers - Answers to Commonly
Asked ``New Internet User'' Questions
1175:: :: FYI on Where to Start - A Bibliography of
Internetworking Information
1174:: I:: "IAB Recommended Policy on Distributing Internet
Identifier Assignment and IAB Recommended Policy Change
to Internet ""Connected"" Status"
1173:: :: "Responsibilities of Host and Network Managers
Summary of the ""Oral Tradition"" of the Internet"
1169:: :: Explaining the Role of GOSIP
1167:: :: Thoughts on the National Research and Education Network
1160:: :: The Internet Activities Board
1152:: :: Workshop Report
1150:: I:: F.Y.I. on F.Y.I.
1149:: :: A Standard for the Transmission of IP Datagrams
on Avian Carriers
1147:: I:: FYI on a Network Management Tool Catalog
1140:: S:: IAB Official Protocol Standards
1135:: :: Helminthiasis of the Internet
1130:: S:: IAB official protocol standards
1127:: :: Perspective on the Host Requirements RFCs
1121:: :: Act one - the poems
1120:: :: Internet Activities Board
1118:: :: Hitchhikers guide to the Internet
1117:: :: Internet numbers
1111:: :: Request for comments on Request for Comments
1100:: S:: IAB official protocol standards
1099:: I:: Request for Comments Summary RFC Numbers 1000-1099
1093:: :: NSFNET routing architecture
1087:: :: Ethics and the Internet
1083:: S:: IAB official protocol standards
1077:: :: Critical issues in high bandwidth networking
1076:: :: HEMS monitoring and control language
1060:: S:: ASSIGNED NUMBERS
1039:: :: DoD statement on Open Systems Interconnection protocols
1020:: :: Internet numbers
1019:: :: Report of the Workshop on Environments for
Computational Mathematics
1018:: :: Some comments on SQuID
1017:: :: Network requirements for scientific research
1015:: :: Implementation plan for interagency research Internet
1014:: :: XDR
1000:: :: Request For Comments reference guide
999:: :: Requests For Comments summary notes
997:: :: Internet numbers
992:: :: On communication support for fault tolerant process groups
991:: S:: Official ARPA-Internet protocols
990:: :: Assigned numbers
980:: :: Protocol document order information
979:: :: PSN End-to-End functional specification
968:: :: Twas the night before start-up
967:: :: All victims together
961:: S:: Official ARPA-Internet protocols
960:: :: Assigned numbers
945:: :: DoD statement on the NRC report
944:: S:: Official ARPA-Internet protocols
943:: :: Assigned numbers
939:: :: Executive summary of the NRC report on transport
protocols for Department of Defense data networks
938:: E:: Internet Reliable Transaction Protocol functional
and interface specification
928:: :: Introduction to proposed DoD standard H-FP
923:: :: Assigned numbers
909:: E:: Loader Debugger Protocol
908:: E:: Reliable Data Protocol
902:: :: ARPA Internet Protocol policy
901:: S:: Official ARPA-Internet protocols
900:: :: Assigned Numbers
899:: :: Request For Comments summary notes
880:: S:: Official protocols
873:: :: Illusion of vendor support
870:: :: Assigned numbers
869:: H:: Host Monitoring Protocol
852:: :: ARPANET short blocking feature
847:: :: Summary of Smallberg surveys
846:: :: Who talks TCP? - survey of 22 February 1983
845:: :: Who talks TCP? - survey of 15 February 1983
844:: :: "Who talks ICMP, too? - Survey of 18 February 1983"
843:: :: Who talks TCP? - survey of 8 February 83
842:: :: Who talks TCP? - survey of 1 February 83
840:: S:: Official protocols
839:: :: Who talks TCP?
838:: :: Who talks TCP?
837:: :: Who talks TCP?
836:: :: Who talks TCP?
835:: :: Who talks TCP?
834:: :: Who talks TCP?
833:: :: Who talks TCP?
832:: :: Who talks TCP?
831:: :: Backup access to the European side of SATNET
828:: :: "Data communications
825:: :: Request for comments on Requests For Comments
820:: :: Assigned numbers
817:: :: Modularity and efficiency in protocol implementation
816:: :: Fault isolation and recovery
806:: :: Proposed Federal Information Processing Standard
800:: :: Request For Comments summary notes
794:: :: Pre-emption
790:: :: Assigned numbers
776:: :: Assigned numbers
774:: :: Internet Protocol Handbook
770:: :: Assigned numbers
766:: :: Internet Protocol Handbook
762:: :: Assigned numbers
758:: :: Assigned numbers
755:: :: Assigned numbers
750:: :: Assigned numbers
745:: :: JANUS interface specifications
739:: :: Assigned numbers
717:: :: Assigned network numbers
716:: :: Interim revision to Appendix F of BBN 1822
708:: :: Elements of a distributed programming system
705:: :: Front-end Protocol B6700 version
700:: :: Protocol experiment
699:: :: Request For Comments summary notes
694:: :: Protocol information
686:: :: Leaving well enough alone
684:: :: Commentary on procedure calling as a network protocol
681:: :: Network UNIX
678:: :: Standard file formats
677:: :: Maintenance of duplicate databases
672:: :: Multi-site data collection facility
671:: :: Note on Reconnection Protocol
667:: :: BBN host ports
666:: :: Specification of the Unified User-Level Protocol
663:: :: Lost message detection and recovery protocol
661:: :: Protocol information
645:: :: Network Standard Data Specification syntax
643:: :: Network Debugging Protocol
642:: :: Ready line philosophy and implementation
638:: :: IMP/TIP preventive maintenance schedule
637:: :: Change of network address for SU-DSL
635:: :: Assessment of ARPANET protocols
634:: :: Change in network address for Haskins Lab
631:: :: International meeting on minicomputers and data
communication
629:: :: Scenario for using the Network Journal
628:: :: Status of RFC numbers and a note on pre-assigned
journal numbers
621:: :: NIC user directories at SRI ARC
617:: :: Note on socket number assignment
609:: :: Statement of upcoming move of NIC/NLS service
604:: :: Assigned link numbers
603:: :: Response to RFC 597
602:: :: The stockings were hung by the chimney with care
598:: :: "RFC index - December 5, 1973"
597:: :: Host status
590:: :: MULTICS address change
588:: :: London node is now up
585:: :: ARPANET users interest working group meeting
584:: :: Charter for ARPANET Users Interest Working Group
582:: :: Comments on RFC 580
581:: :: Corrections to RFC 560
580:: :: Note to protocol designers and implementers
578:: :: Using MIT-Mathlab MACSYMA from MIT-DMS Muddle
569:: H:: NETED
552:: :: Single access to standard protocols
547:: :: Change to the Very Distant Host specification
544:: :: Locating on-line documentation at SRI-ARC
537:: :: Announcement of NGG meeting July 16-17
530:: :: Report on the Survey project
529:: :: Note on protocol synch sequences
527:: :: ARPAWOCKY
526:: :: Technical meeting
523:: :: SURVEY is in operation again
519:: :: Resource evaluation
518:: :: ARPANET accounts
515:: :: Specifications for datalanguage
503:: :: Socket number list
496:: :: TNLS quick reference card is available
494:: :: Availability of MIX and MIXAL in the Network
492:: :: Response to RFC 467
491:: :: "What is ""Free""?"
483:: :: Cancellation of the resource notebook framework meeting
474:: :: Announcement of NGWG meeting
464:: :: Resource notebook framework
462:: :: Responding to user needs
457:: :: TIPUG
456:: :: Memorandum
441:: :: Inter-Entity Communication - an experiment
440:: :: Scheduled network software maintenance
439:: :: PARRY encounters the DOCTOR
433:: :: Socket number list
432:: :: Network logical map
425:: :: But my NCP costs $500 a day
419:: :: To
405:: :: Correction to RFC 404
404:: :: Host address changes involving Rand and ISI
403:: :: Desirability of a network 1108 service
402:: :: ARPA Network mailing lists
401:: :: Conversion of NGP-0 coordinates to device specific
coordinates
390:: :: TSO scenario
379:: :: Using TSO at CCN
376:: :: Network host status
372:: :: Notes on a conversation with Bob Kahn on the ICCC
371:: :: Demonstration at International Computer Communications
Conference
370:: :: Network host status
363:: :: ARPA Network mailing lists
356:: :: ARPA Network Control Center
355:: :: Response to NWG/RFC 346
350:: :: User accounts for UCSB On-Line System
349:: :: Proposed standard socket numbers
345:: :: Interest in mixed integer programming MPSX on NIC
360/91 at CCN
334:: :: Network use on May 8
331:: :: IMP System change notification
330:: :: Network host status
329:: :: ARPA Network mailing lists
327:: :: Data and File Transfer workshop notes
322:: :: Well known socket numbers
321:: :: CBI networking activity at MITRE
320:: :: Workshop on hard copy line printers
319:: :: Network host status
317:: :: Official Host-Host Protocol modification
316:: :: ARPA Network Data Management Working Group
315:: :: Network host status
313:: :: Computer based instruction
305:: :: Unknown host numbers
303:: :: ARPA Network mailing lists
295:: :: "Report of the Protocol Workshop, 12 October 1971"
291:: :: Data management meeting announcement
290:: :: Computer networks and data sharing
282:: :: Graphics meeting report
276:: :: NIC course
270:: :: Correction to BBN Report No. 1822 NIC NO 7958
269:: :: Some experience with file transfer
263:: :: Very Distant Host interface
256:: :: IMPSYS change notification
254:: :: Scenarios for using ARPANET computers
253:: :: Second Network Graphics meeting details
249:: :: Coordination of equipment and supplies purchase
246:: :: Network Graphics meeting
245:: :: Reservations for Network Group meeting
243:: :: Network and data sharing bibliography
242:: :: Data descriptive language for shared data
240:: :: Site status
239:: :: Host mnemonics proposed in RFC 226 NIC 7625
235:: :: Site status
234:: :: Network Working Group meeting schedule
232:: :: Postponement of network graphics meeting
228:: :: Clarification
225:: :: Rand/UCSB network graphics experiment
223:: :: Network Information Center schedule for network users
219:: :: User's view of the datacomputer
218:: :: Changing the IMP status reporting facility
214:: :: Network checkpoint
213:: :: IMP System change notification
211:: :: ARPA Network mailing lists
209:: :: Host/IMP interface documentation
208:: :: Address tables
207:: :: September Network Working Group meeting
204:: :: Sockets in use
200:: :: RFC list by number
198:: :: Site certification - Lincoln Labs 360/67
195:: :: Data computers-data descriptions and access language
194:: :: Data Reconfiguration Service - compiler/interpreter
implementation notes
187:: :: Network/440 protocol concept
186:: :: Network graphics loader
185:: :: NIC distribution of manuals and handbooks
182:: :: Compilation of list of relevant site reports
180:: :: File system questionnaire
179:: :: Link number assignments
173:: :: Network data management committee meeting announcement
171:: :: Data Transfer Protocol
170:: :: RFC list by number
169:: :: Computer networks
168:: :: ARPA Network mailing lists
167:: :: Socket conventions reconsidered
164:: :: "Minutes of Network Working Group meeting, 5/16
through 5/19/71 "
162:: :: NETBUGGER3
160:: :: RFC brief list
157:: :: Invitation to the Second Symposium on Problems in the
Optimization of Data Communications Systems
155:: :: ARPA Network mailing lists
154:: :: Exposition style
149:: :: Best laid plans
148:: :: Comments on RFC 123
147:: :: Definition of a socket
140:: :: Agenda for the May NWG meeting
138:: :: Status report on proposed Data Reconfiguration Service
136:: :: Host accounting and administrative procedures
135:: :: Response to NWG/RFC 110
132:: :: Typographical error in RFC 107
131:: :: Response to RFC 116
130:: :: Response to RFC 111
129:: :: Request for comments on socket name structure
126:: :: Graphics facilities at Ames Research Center
124:: :: Typographical error in RFC 107
121:: :: Network on-line operators
120:: :: Network PL1 subprograms
119:: :: Network Fortran subprograms
118:: :: Recommendations for facility documentation
117:: :: Some comments on the official protocol
116:: :: Structure of the May NWG meeting
115:: :: Some Network Information Center policies on handling
documents
113:: :: Network activity report
112:: :: User/Server Site Protocol
111:: :: Pressure from the chairman
109:: :: Level III Server Protocol for the Lincoln Laboratory
NIC 360/67 Host
108:: :: "Attendance list at the Urbana NWG meeting, February
17-19,1971 "
107:: :: Output of the Host-Host Protocol glitch cleaning committee
106:: :: User/Server Site Protocol network host questionnaire
104:: :: Link 191
103:: :: Implementation of interrupt keys
102:: :: Output of the Host-Host Protocol glitch cleaning committee
101:: :: "Notes on the Network Working Group meeting,
Urbana, Illinois, February 17, 1971"
100:: :: Categorization and guide to NWG/RFCs
99:: :: Network meeting
95:: :: Distribution of NWG/RFC's through the NIC
90:: :: CCN as a network service center
89:: :: Some historic moments in networking
87:: :: Topic for discussion at the next Network Working Group
meeting
85:: :: Network Working Group meeting
84:: :: List of NWG/RFC's 1-80
82:: :: Network meeting notes
81:: :: Request for reference information
78:: :: NCP status report
77:: :: Network meeting report
76:: :: Connection by name
75:: :: Network meeting
74:: :: Specifications for network use of the UCSB On-Line System
73:: :: Response to NWG/RFC 67
72:: :: Proposed moratorium on changes to network protocol
71:: :: Reallocation in case of input error
69:: :: Distribution list change for MIT
68:: :: "Comments on memory allocation control commands
66:: :: NIC - third level ideas and other noise
64:: :: Getting rid of marking
63:: :: Belated network meeting report
61:: :: Note on interprocess communication in a resource
sharing computer network
57:: :: Thoughts and reflections on NWG/RFC 54
52:: :: Updated distribution list
51:: :: Proposal for a Network Interchange Language
50:: :: Comments on the Meyer proposal
49:: :: Conversations with S. Crocker UCLA
48:: :: Possible protocol plateau
47:: :: BBN's comments on NWG/RFC #33
46:: :: ARPA Network protocol notes
45:: :: New protocol is coming
44:: :: Comments on NWG/RFC 33 and 36
43:: :: Proposed meeting [LIL]
40:: :: More comments on the forthcoming protocol
39:: :: Comments on protocol re
37:: :: "Network meeting epilogue, etc"
36:: :: Protocol notes
35:: :: Network meeting
34:: :: Some brief preliminary notes on the Augmentation
Research Center clock
31:: :: Binary message forms in computer
30:: :: Documentation conventions
27:: :: Documentation conventions
25:: :: No high link numbers
24:: :: Documentation conventions
21:: :: Network meeting
16:: :: M.I.T
15:: :: Network subsystem for time sharing hosts
13:: :: [Referring to NWG/RFC 11]
11:: :: Implementation of the Host-Host software procedures
in GORDO
10:: :: Documentation conventions
9:: :: Host software
8:: :: Functional specifications for the ARPA Network
7:: :: Host-IMP interface
6:: :: Conversation with Bob Kahn
5:: :: Decode Encode Language
4:: :: Network timetable
3:: :: Documentation conventions
2:: :: Host software
1:: :: Host software
Appendix A: List of RFC's divided by Area
Appendix B: Automatic Script to Implement Methodology Appendix B: Automatic Script to Implement Methodology
#!/usr/bin/perl5
# Program to read text files (such as RFCs and Internet Drafts) and
# output items that might relate to year 2000 issues, particularly
# 2-digit years.
#
# Version 1.0. By Paul Hoffman (paulh@imc.org). You may distribute and
# use this program freely. I welcome comments and criticisms on the
# program.
#
# Note: In the spirit of quick and dirty, this code is by no means
# optimized for speed or memory usage. Instead, it is written to
# be as easy to read(and therefore debug) as possible.
# Some people like using disk files, others like STDIN and STDOUT.
# This program accomodates both types. 'file' means input comes
# from the first argument on the command line, output goes to that
# filename with a ".out" extension; 'std' means STDIN and STDOUT.
$UsageType = 'file'; # Should be 'file' or 'std'
@CheckWords = qw(UTCTime two-digit 2-digit 2digit century 1900 2000);
# You might want to add "year yyyy" to this list, but then a
# large proportion of the RFCs and drafts get selected
if($UsageType eq 'file') {
if($ARGV[0] eq '')
{ die "You must specify the name of the file to open.\n" }
$InName = $ARGV[0];
unless(-r $InName) { die "Could not read $InName.\n" }
open(IN, $InName) or die "Could not open $InName.\n";
$OutName = "$InName.out";
open(OUT, ">$OutName") or die "Could not write to $OutName.\n";
$OutStuff = ''; # Holder for what we're going to print out
} else { # Do STDIN and STDOUT
open(IN, "-"); open(OUT, ">-");
}
# Read the whole file into an array. This is a tad wasteful of memory
# but makes the output easier.
@All = ();
while(<IN>) { push(@All, $_) }
$LastLine = $#All;
# Process the instance of "yy" not followed by "yy"
for($i = 0; $i <= $LastLine; $i += 1 ) {
next unless(grep(/yy/i, $All[$i]));
next if(grep(/yyyy/i, $All[$i]));
&PrintFive($i, "'yy' on a line without 'yyyy'");
}
# Next do the words that should cause extra concern
foreach $Word (@CheckWords) {
for($i = 0; $i <= $LastLine; $i += 1 ) {
next unless(grep(/$Word/i, $All[$i]));
&PrintFive($i, "$Word");
}
}
# All done. If writing to a file, and nothing got written, delete the
# file so that you can quickly scan for the ".out" files.
if($UsageType eq 'file') {
if(length($OutStuff) > 0) {
$OutStuff = "+=+=+=+=+= File $InName +=+=+=+=+= \n
$OutStuff\n";
print OUT $OutStuff; close(OUT);
} else { # Nothing to put in the .out
close(OUT);
unlink($OutName) or die "Couldn't unlink $OutName\n";
}
}
exit;
sub PrintFive {
my $Where = shift(@_); my $Msg = shift(@_);
my ($WhereRealLine, $Start, $End, $j);
$WhereRealLine = $Where + 1;
$OutStuff .= "$Msg found at line $WhereRealLine:\n";
$Start = $Where - 2; $End = $Where + 2;
if($Where < 2) { $Start = 0 }
if($Where > $LastLine - 2) { $End = $LastLine }
for($j = $Start; $j <= $End; $j += 1) { $OutStuff .= "$j: "
. @All[$j] }
$OutStuff .= "\n";
}
Appendix C: Output of the script in Appendix B on all RFC's from 1 Appendix C: Output of the script in Appendix B on all RFC's from 1
through 2134 through 2134
+=+=+=+=+= File rfc90.txt +=+=+=+=+=
2000 found at line 71:
68: consoles);
69:
70: j) Six data communication ports (3 dial @ 2000 baud,
71: 1 dedicated @ 4800 baud, and 2 dedicated @ 50,000
72: baud) for remote batch entry terminals;
+=+=+=+=+= File rfc230.txt +=+=+=+=+=
2000 found at line 92:
89: as for conventional synchronous block communication, since start and
90: stop bits for each character would need to be transmitted. This loss
91: is not substantial and does occur now for 2000 bps TIP-terminal
92: communication.
93:
2000 found at line 134:
131: 92 transmitting sites in the U.S. and Canada were used with standard
132: Bell System Dataphone datasets used at both ends. At both 1200 and
133: 2000 bps, approximately 82% of the calls had error rates of 1 error in
134: 10^5 bits or better, assuming an equal number of short, medium, and
135: long hauls.
+=+=+=+=+= File rfc241.txt +=+=+=+=+=
2000 found at line 32:
29: justifiable on the basis that the IMP and Host computers were
30: expected to be either in the same room (up to 30 feet of cable) or,
31: via the Distant Host option, within 2000 feet on well- controlled,
32: shielded cables. A connection through common carrier facilities is
33: not comparably free of errors. Usage of common- carrier lines for
+=+=+=+=+= File rfc263.txt +=+=+=+=+=
2000 found at line 22:
19: of the occasional desire to interface a Host to some IMP via a
20: long-distance connection (where long-distance, in this context,
21: is any cable run longer than 2000 feet but may typically be tens
22: of miles) via either a hard-wire or telephone circuit. We believe
23: that any good solution to the general problem of interfacing Hosts
+=+=+=+=+= File rfc662.txt +=+=+=+=+=
2000 found at line 143:
140: by a rather short cable (approximately 100 feet long.) The CISL Multics is
141: connected to the IMP number 6 (port 0) by an approximately l5OO feet long cable.
142: 8oth IMPs are in close physical proximity (approximately 2000 feet,) and are
143: connected to each other by a 5O kilobits per second line. The results given
144: above show considerable improvement in the performance with the new IMP DIM.
+=+=+=+=+= File rfc713.txt +=+=+=+=+=
2000 found at line 830:
827: succeeding bytes in the stream used to encode the object.
828:
829: A data object requiring 20000 (47040 octal) bytes would
830: appear in the stream as follows.
831:
2000 found at line 837:
834: 10000010 -- specifying that the next 2 bytes
835: contain the stream length
836: 01001110 -- first byte of number 20000
837: 00100000 -- second byte
838: .
2000 found at line 845:
842: .
843:
844: Interpretation of the contents of the 20000 bytes in
845: the stream can be performed by a module which knows the
846: specific format of the non-atomic type specified by DEFGH in
+=+=+=+=+= File rfc724.txt +=+=+=+=+=
2-digit found at line 1046:
1043: <4-digit-year>
1044: <slash-date> ::= <numeric-month> "/" <date-of-month>
1045: "/" <2-digit-year>
1046: <numeric-month> ::= <one or two decimal digits>
1047: <day-of-month> ::= <one or two decimal digits>
2-digit found at line 1062:
1059: | "December" | "Dec"
1060: <4-digit-year> ::= <four decimal digits>
1061: <2-digit-year> ::= <two decimal digits>
1062: <time> ::= <24-hour-time> "-" <time-zone>
1063: <24-hour-time> ::= <hour> <minute>
2-digit found at line 1675:
1672: A. ALPHABETICAL LISTING OF SYNTAX RULES
1673:
1674: <2-digit-year> ::= <two decimal digits>
1675: <4-digit-year> ::= <four decimal digits>
1676: <24-hour-time> ::= <hour> <minute>
2-digit found at line 1829:
1826:
1827: <slash-date> ::= <numeric-month> "/" <date-of-month>
1828: "/" <2-digit-year>
1829: <space> ::= <TELNET ASCII space (decimal 32)>
1830:
+=+=+=+=+= File rfc731.txt +=+=+=+=+=
2000 found at line 1571:
1568: RFC 728, 1977.
1569:
1570: 9. Hazeltine 2000 Desk Top Display Operating Instructions.
1571: Hazeltine IB-1866A, 1870.
1572:
+=+=+=+=+= File rfc732.txt +=+=+=+=+=
2000 found at line 1681:
1678: 1977.
1679:
1680: 9. Hazeltine 2000 Desk Top Display Operating Instructions. Hazeltine
1681: IB-1866A, 1870.
1682:
+=+=+=+=+= File rfc733.txt +=+=+=+=+=
2-digit found at line 333:
330:
331: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
332: exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit
333: number, and 3ALPHA is a string of three alphabetic characters.
334:
2digit found at line 333:
330:
331: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
332: exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit
333: number, and 3ALPHA is a string of three alphabetic characters.
334:
2digit found at line 947:
944: / "Sunday" / "Sun"
945:
946: date = 1*2DIGIT ["-"] month ; day month year
947: ["-"] (2DIGIT /4DIGIT) ; e.g. 20 Aug [19]77
948:
2digit found at line 948:
945:
946: date = 1*2DIGIT ["-"] month ; day month year
947: ["-"] (2DIGIT /4DIGIT) ; e.g. 20 Aug [19]77
948:
949: month = "January" / "Jan" / "February" / "Feb"
2digit found at line 967:
964: ; (seconds optional)
965:
966: hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
967: ; 0000[00] - 2359[59]
968:
2digit found at line 1718:
1715: CTL = <any TELNET ASCII control character and DEL>
1716:
1717: date = 1*2DIGIT ["-"] month ["-"] (2DIGIT /4DIGIT)
1718: date-field = "Date" ":" date-time
1719: date-time = [ day-of-week "," ] date time
2digit found at line 1754:
1751: host-indicator = 1*( ("at" / "@") node )
1752: host-phrase = phrase host-indicator
1753: hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
1754: HTAB = <TELNET ASCII horizontal-tab>
1755:
+=+=+=+=+= File rfc734.txt +=+=+=+=+=
2000 found at line 184:
181: Bit name Value Meaning
182:
183: %TOALT 200000,,0 characters 175 and 176 are converted to
184: altmode (033) on input.
185:
2000 found at line 264:
261: NORMALLY OFF.
262:
263: %TOSA1 2000,,0 characters 001-037 should be displayed
264: using the Stanford/ITS extended ASCII
265: graphics character set instead of uparrow
2000 found at line 354:
351: %TXTOP 4000 This character has the [TOP] key depressed.
352:
353: %TXSFL 2000 Reserved, must be zero.
354:
355: %TXSFT 1000 Reserved, must be zero.
2000 found at line 634:
631: Value Key
632:
633: 2000 Reserved
634: 1000 Reserved
635: 0400 <META>
+=+=+=+=+= File rfc738.txt +=+=+=+=+=
1900 found at line 41:
38: without sending anything.
39:
40: The time is the number of seconds since 0000 (midnight) 1 January 1900
41: GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this
42: base will serve until the year 2036. As a further example, the most
1900 found at line 42:
39:
40: The time is the number of seconds since 0000 (midnight) 1 January 1900
41: GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this
42: base will serve until the year 2036. As a further example, the most
43: recent leap year as of this writing began from the time 2,398,291,200
+=+=+=+=+= File rfc745.txt +=+=+=+=+=
2000 found at line 562:
559: Circuits, EIA standard RS-422," April 1975; Engineering Dept.,
560: Electronic Industries Assn., 2001 Eye St., N.W., Washington, D.C.,
561: 20006.
562:
563: REA bulletin 345-67, Rural Electrification Admin., U.S. Dept. of
+=+=+=+=+= File rfc746.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 341:
338: %TDGRF ;Enter graphics.
339: %GOCLR ;Clear the screen.
340: %GOMVA xx yy ;Set cursor.
341: %GODLA xx yy ;Draw line from there.
342: << repeat last two commands for each line >>
'yy' on a line without 'yyyy' found at line 342:
339: %GOCLR ;Clear the screen.
340: %GOMVA xx yy ;Set cursor.
341: %GODLA xx yy ;Draw line from there.
342: << repeat last two commands for each line >>
343: %TDNOP ;Exit graphics.
2000 found at line 859:
856: %TRGIN 0,,400000 terminal can provide graphics input.
857:
858: %TRGHC 0,,200000 terminal has a hard-copy device to which output can
859: be diverted.
860:
+=+=+=+=+= File rfc752.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 218:
215: word 4 The name of the site in SIXBIT.
216: word 5 The user name who compiled the file, usually in SIXBIT.
217: word 6 Date of compilation as SIXBIT YYMMDD.
218: word 7 Time of compilation as SIXBIT HHMMSS.
219: word 8 Address in file of NAME table.
+=+=+=+=+= File rfc754.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 76:
73:
74: Messages are transmitted as a character string to an address which is
75: specified "outside" the message. The destination host ("YYY") is
76: specified to the sending (or user) FTP as the argument of the "open
77: connection" command, and the destination user ("XXX") is specified to
'yy' on a line without 'yyyy' found at line 81:
78: the receiving (or server) FTP as the argument of the "MAIL" (or "MLFL")
79: command. In Tenex, when mail is queued this outside information is
80: saved in the file name ("[---].XXX@YYY").
81:
82: The proposed solutions are briefly characterized.
'yy' on a line without 'yyyy' found at line 239:
236:
237:
238: "[---].XXX@YYY", not anything from the header. Only the string "XXX"
239: is passed to the FTP server.
240:
+=+=+=+=+= File rfc759.txt +=+=+=+=+=
two-digit found at line 1414:
1411: yyyy-mm-dd-hh:mm:ss,fff+hh:mm
1412:
1413: Where yyyy is the four-digit year, mm is the two-digit month, dd is
1414: the two-digit day, hh is the two-digit hour in 24 hour time, mm is
1415: the two-digit minute, ss is the two-digit second, and fff is the
two-digit found at line 1415:
1412:
1413: Where yyyy is the four-digit year, mm is the two-digit month, dd is
1414: the two-digit day, hh is the two-digit hour in 24 hour time, mm is
1415: the two-digit minute, ss is the two-digit second, and fff is the
1416: decimal fraction of the second. To this basic date and time is
two-digit found at line 1416:
1413: Where yyyy is the four-digit year, mm is the two-digit month, dd is
1414: the two-digit day, hh is the two-digit hour in 24 hour time, mm is
1415: the two-digit minute, ss is the two-digit second, and fff is the
1416: decimal fraction of the second. To this basic date and time is
1417: appended the offset from Greenwich as plus or minus hh hours and mm
+=+=+=+=+= File rfc767.txt +=+=+=+=+=
two-digit found at line 710:
707: yyyy-mm-dd-hh:mm:ss,fff+hh:mm
708:
709: Where yyyy is the four-digit year, mm is the two-digit month, dd is
710: the two-digit day, hh is the two-digit hour in 24 hour time, mm is
711: the two-digit minute, ss is the two-digit second, and fff is the
two-digit found at line 711:
708:
709: Where yyyy is the four-digit year, mm is the two-digit month, dd is
710: the two-digit day, hh is the two-digit hour in 24 hour time, mm is
711: the two-digit minute, ss is the two-digit second, and fff is the
712: decimal fraction of the second. To this basic date and time is
two-digit found at line 712:
709: Where yyyy is the four-digit year, mm is the two-digit month, dd is
710: the two-digit day, hh is the two-digit hour in 24 hour time, mm is
711: the two-digit minute, ss is the two-digit second, and fff is the
712: decimal fraction of the second. To this basic date and time is
713: appended the offset from Greenwich as plus or minus hh hours and mm
+=+=+=+=+= File rfc786.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 71:
68:
69: The date-time will be in the default TOPS20 ODTIM format
70: "dd-mmm-yy hh:mm:ss" (24 hour time).
71:
72: The files will named "arbitrary.NIMAIL.-1", where "arbitrary" will
+=+=+=+=+= File rfc788.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 1592:
1589: <daytime> ::= "at" <SP> <date> <SP> <time>
1590:
1591: <date> ::= <dd> "-" <mon> "-" <yy>
1592:
1593: <time> ::= <hh> ":" <mm> ":" <ss> "-" <zone>
'yy' on a line without 'yyyy' found at line 1602:
1599: "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
1600:
1601: <yy> ::= the two decimal integer year of the century in the
1602: range 01 to 99.
1603:
century found at line 1602:
1599: "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
1600:
1601: <yy> ::= the two decimal integer year of the century in the
1602: range 01 to 99.
1603:
+=+=+=+=+= File rfc809.txt +=+=+=+=+=
2000 found at line 3349:
3346:
3347: #define WID 0000000 /* Write Image Data */
3348: #define WGD 0020000 /* Write Graphic Data */
3349: #define WAC 0022000 /* Write AlphanumCh */
3350:
2000 found at line 3350:
3347: #define WID 0000000 /* Write Image Data */
3348: #define WGD 0020000 /* Write Graphic Data */
3349: #define WAC 0022000 /* Write AlphanumCh */
3350:
3351: #define LWM 0024000 /* Load Write Mode */
2000 found at line 3379:
3376:
3377: #define ERS 0030000 /* Erase */
3378: #define ERL 0032000 /* Erase Line */
3379: #define SLU 0034000 /* Special Location Update */
3380: #define SCRL_ZAP 0100 /* unlimited scroll speed */
2000 found at line 3392:
3389: #define LLB 0070000 /* Load Lb */
3390: #define LLC 0074000 /* Load Lc */
3391: #define LGW 02000 /* perform write */
3392:
3393: #define NOP 0110000 /* No-Operation */
2000 found at line 3396:
3393: #define NOP 0110000 /* No-Operation */
3394:
3395: #define SPD 0120000 /* Select Special Device */
3396: #define LPA 0130000 /* Load Peripheral Address */
3397: #define LPR 0140000 /* Load Peripheral Register */
2000 found at line 3405:
3402: #define ALPHA 06000 /* LPR - Alphanumeric data */
3403: #define GRAPH 04000 /* LPR - Graphic data */
3404: #define IMAGE 02000 /* LPR - Image data */
3405: #define LTHENH 01000 /* take lo byte then hi byte */
3406: #define DROPBYTE 0400 /* drop last byte */
2000 found at line 3408:
3405: #define LTHENH 01000 /* take lo byte then hi byte */
3406: #define DROPBYTE 0400 /* drop last byte */
3407: #define INTERR 02000 /* SPD - Interrupt Enable */
3408: #define TEST 04000 /* SPD - Diagnostic Test */
3409:
+=+=+=+=+= File rfc810.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 146:
143: , (comma) is used as a data element delimiter
144:
145: XXX/YYY indicates protocol information of the type
146: TRANSPORT/SERVICE.
147:
+=+=+=+=+= File rfc820.txt +=+=+=+=+=
2000 found at line 674:
671: 014.000.000.001 311031700035 00 PURDUE-TN [CXK]
672: 014.000.000.002 311060800027 00 UWISC-TN [CXK]
673: 014.000.000.003 311030200024 00 UDEL-TN [CXK]
674: 014.000.000.004 234219200149 23 UCL-VTEST [PK]
675: 014.000.000.005 234219200300 23 UCL-TG [PK]
+=+=+=+=+= File rfc821.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 1944:
1941: <daytime> ::= <SP> <date> <SP> <time>
1942:
1943: <date> ::= <dd> <SP> <mon> <SP> <yy>
1944:
1945: <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
'yy' on a line without 'yyyy' found at line 1954:
1951: "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
1952:
1953: <yy> ::= the two decimal integer year of the century in the
1954: range 00 to 99.
1955:
century found at line 1954:
1951: "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
1952:
1953: <yy> ::= the two decimal integer year of the century in the
1954: range 00 to 99.
1955:
+=+=+=+=+= File rfc822.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 1635:
1632: 5.1. SYNTAX
1633:
1634: date-time = [ day "," ] date time ; dd mm yy
1635: ; hh:mm:ss zzz
1636:
'yy' on a line without 'yyyy' found at line 2701:
2698: dates = orig-date ; Original
2699: [ resent-date ] ; Forwarded
2700: date-time = [ day "," ] date time ; dd mm yy
2701: ; hh:mm:ss zzz
2702: day = "Mon" / "Tue" / "Wed" / "Thu"
2-digit found at line 344:
341:
342: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
343: exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit
344: number, and 3ALPHA is a string of three alphabetic characters.
345:
2digit found at line 344:
341:
342: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
343: exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit
344: number, and 3ALPHA is a string of three alphabetic characters.
345:
2digit found at line 1641:
1638: / "Fri" / "Sat" / "Sun"
1639:
1640: date = 1*2DIGIT month 2DIGIT ; day month year
1641: ; e.g. 20 Jun 82
1642:
2digit found at line 1650:
1647: time = hour zone ; ANSI and Military
1648:
1649: hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
1650: ; 00:00:00 - 23:59:59
1651:
2digit found at line 2697:
2694: CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
2695: character and DEL> ; ( 177, 127.)
2696: date = 1*2DIGIT month 2DIGIT ; day month year
2697: ; e.g. 20 Jun 82
2698: dates = orig-date ; Original
2digit found at line 2747:
2744: field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
2745: group = phrase ":" [#mailbox] ";"
2746: hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
2747: ; 00:00:00 - 23:59:59
2748: HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
+=+=+=+=+= File rfc850.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 227:
224: network. One format that is acceptable to both is
225:
226: Weekday, DD-Mon-YY HH:MM:SS TIMEZONE
227:
228: Several examples of valid dates appear in the sample
+=+=+=+=+= File rfc867.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 67:
64: Another popular syntax is that used in SMTP:
65:
66: dd mmm yy hh:mm:ss zzz
67:
68: Example:
+=+=+=+=+= File rfc868.txt +=+=+=+=+=
1900 found at line 19:
16: This protocol provides a site-independent, machine readable date and
17: time. The Time service sends back to the originating source the time in
18: seconds since midnight on January first 1900.
19:
20: One motivation arises from the fact that not all systems have a
1900 found at line 83:
80: The Time
81:
82: The time is the number of seconds since 00:00 (midnight) 1 January 1900
83: GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this
84: base will serve until the year 2036.
1900 found at line 84:
81:
82: The time is the number of seconds since 00:00 (midnight) 1 January 1900
83: GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this
84: base will serve until the year 2036.
85:
+=+=+=+=+= File rfc869.txt +=+=+=+=+=
2000 found at line 1639:
1636: 400 HDH
1637: 1000 Cassette Writer
1638: 2000 Propagation Delay Measurement
1639: 4000 X25
1640: 10000 Profile Measurements
2000 found at line 1642:
1639: 4000 X25
1640: 10000 Profile Measurements
1641: 20000 Self Authenticating Password
1642: 40000 Host traffic Matrix
1643: 100000 Experimental/Special
2000 found at line 1669:
1666: 200 Trace ON
1667: 1000 Statistics ON
1668: 2000 Message Generator ON
1669: 4000 Packet Trace ON
1670: 10000 Host Data Checksum is BAD
2000 found at line 1672:
1669: 4000 Packet Trace ON
1670: 10000 Host Data Checksum is BAD
1671: 20000 Reload Location SET
1672:
1673:
+=+=+=+=+= File rfc884.txt +=+=+=+=+=
2000 found at line 236:
233: GENERAL-TERMINAL-100A
234: HAZELTINE-1500
235: HAZELTINE-2000
236: HP-2621
237: HP-2640A
+=+=+=+=+= File rfc899.txt +=+=+=+=+=
1900 found at line 337:
334: provides a site-independent, machine readable date and time. The
335: Time service sends back to the originating source the time in seconds
336: since midnight on January first 1900.
337:
338: 867 Postel May 83 Daytime Protocol
+=+=+=+=+= File rfc900.txt +=+=+=+=+=
2000 found at line 1595:
1592: HAZELTINE-1510
1593: HAZELTINE-1520
1594: HAZELTINE-2000
1595: HP-2621
1596: HP-2621A
+=+=+=+=+= File rfc909.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 859:
856: responses from the target. A session begins when a host opens a
857: transport connection to a target listening on a well known port.
858: LDP uses RDP port number zzz or TCP port number yyy. When the
859: connection has been established, the host sends a HELLO command,
860: and the target replies with a HELLO_REPLY. The HELLO_REPLY
+=+=+=+=+= File rfc923.txt +=+=+=+=+=
2000 found at line 1769:
1766: HAZELTINE-1510
1767: HAZELTINE-1520
1768: HAZELTINE-2000
1769: HP-2621
1770: HP-2621A
+=+=+=+=+= File rfc937.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 327:
324: FOLD mailbox - Error
325: READ [n] #xxx
326: RETR =yyy
327: ACKS
328: ACKD
+=+=+=+=+= File rfc943.txt +=+=+=+=+=
2000 found at line 1829:
1826: HAZELTINE-1510
1827: HAZELTINE-1520
1828: HAZELTINE-2000
1829: HP-2621
1830: HP-2621A
+=+=+=+=+= File rfc952.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 159:
156: ,(comma) is used as a data element delimiter
157:
158: XXX/YYY indicates protocol information of the type
159: TRANSPORT/SERVICE.
160:
+=+=+=+=+= File rfc956.txt +=+=+=+=+=
1900 found at line 748:
745:
746: 3. The data format should be based on the UDP Time format, which
747: specifies 32-bit time in seconds since 1 January 1900, but
748: extended additional bits for the fractional part of a second.
749:
1900 found at line 826:
823: experiment the results indicated by UDP and ICMP are compared. In
824: the UDP Time protocol time is indicated as a 32-bit field in seconds
825: past 0000 UT on 1 January 1900, while in the ICMP Timestamp message
826: time is indicated as a 32-bit field in milliseconds past 0000 UT of
827: each day.
2000 found at line 1392:
1389: CU-ARPA.CS.CORNELL.EDU -1 -514
1390: UCI-ICSE.ARPA -1 -1896
1391: UCI-ICSC.ARPA 1 2000
1392: DCN9.ARPA -7 -6610
1393: TRANTOR.ARPA 10 10232
+=+=+=+=+= File rfc958.txt +=+=+=+=+=
century found at line 41:
38: NTP provides the protocol mechanisms to synchronize time in principle
39: to precisions in the order of nanoseconds while preserving a
40: non-ambiguous date, at least for this century. The protocol includes
41: provisions to specify the precision and estimated error of the local
42: clock and the characteristics of the reference clock to which it may
1900 found at line 143:
140:
141: NTP timestamps are represented as a 64-bit fixed-point number, in
142: seconds relative to 0000 UT on 1 January 1900. The integer part is
143: in the first 32 bits and the fraction part in the last 32 bits, as
144: shown in the following diagram.
+=+=+=+=+= File rfc960.txt +=+=+=+=+=
2000 found at line 1659:
1656: 014.000.000.018 2624-522-80900 52 DFVLR5-X25 [HDC1]
1657: 014.000.000.019 2041-170-10000 00 SHAPE-X25 [JFW]
1658: 014.000.000.020 5052-737-20000 50 UQNET [AXH]
1659: 014.000.000.021 3020-801-00057 50 DMC-CRC1 [JR17]
1660: 014.000.000.022-014.255.255.254 Unassigned [JBP]
2000 found at line 1984:
1981: AEGIS
1982: APOLLO
1983: BS-2000
1984: CEDAR
1985: CGW
2000 found at line 2350:
2347: HAZELTINE-1510
2348: HAZELTINE-1520
2349: HAZELTINE-2000
2350: HP-2621
2351: HP-2621A
+=+=+=+=+= File rfc973.txt +=+=+=+=+=
2000 found at line 377:
374: We might add the following to the parent zone:
375:
376: 99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU.
377: 2000 NS XX.MIT.EDU.
378: Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.>
2000 found at line 378:
375:
376: 99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU.
377: 2000 NS XX.MIT.EDU.
378: Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.>
379: XX.MIT.EDU. 2000 A <address of XX.MIT.EDU.>
2000 found at line 379:
376: 99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU.
377: 2000 NS XX.MIT.EDU.
378: Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.>
379: XX.MIT.EDU. 2000 A <address of XX.MIT.EDU.>
380:
2000 found at line 380:
377: 2000 NS XX.MIT.EDU.
378: Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.>
379: XX.MIT.EDU. 2000 A <address of XX.MIT.EDU.>
380:
381: and the following to the child zone:
2000 found at line 384:
381: and the following to the child zone:
382:
383: 99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU.
384: 2000 NS XX.MIT.EDU.
385: 5000 SOA <SOA information>
2000 found at line 385:
382:
383: 99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU.
384: 2000 NS XX.MIT.EDU.
385: 5000 SOA <SOA information>
386: Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.>
2000 found at line 387:
384: 2000 NS XX.MIT.EDU.
385: 5000 SOA <SOA information>
386: Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.>
387: XX.MIT.EDU. 2000 A <address of XX.MIT.EDU.>
388:
2000 found at line 388:
385: 5000 SOA <SOA information>
386: Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.>
387: XX.MIT.EDU. 2000 A <address of XX.MIT.EDU.>
388:
389: SOA serials
+=+=+=+=+= File rfc977.txt +=+=+=+=+=
'yy' on a line without 'yyyy' found at line 814:
811: the same format as the LIST command.
812:
813: The date is sent as 6 digits in the format YYMMDD, where YY is the
814: last two digits of the year, MM is the two digits of the month (with
815: leading zero, if appropriate), and DD is the day of the month (with
century found at line 817:
814: last two digits of the year, MM is the two digits of the month (with
815: leading zero, if appropriate), and DD is the day of the month (with
816: leading zero, if appropriate). The closest century is assumed as
817: part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
818: 1999, 00 is 2000).
2000 found at line 819:
816: leading zero, if appropriate). The closest century is assumed as
817: part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
818: 1999, 00 is 2000).
819:
820: Time must also be specified. It must be as 6 digits HHMMSS with HH
2000 found at line 1190:
1187:
1188: (client asks for new newsgroups since April 3, 1985)
1189: C: NEWGROUPS 850403 020000
1190:
<