2.3 INTERNET STANDARDIZATION

Team-Fly

2.3 INTERNET STANDARDIZATION

In this section, we focus on Internet standardization. More specifically, we overview the technical bodies that are engaged in Internet standardization, elaborate on the documentation series that are officially published by these bodies, and discuss the standardization process. You may refer to the indicated URLs or [5] for a more complete discussion of Internet standardization and governance.

2.3.1 Technical Bodies

There are many organizations and technical bodies engaged in Internet standardization. The most important ones are overviewed in Figure 2.1 and further explained next.

click to expand
Figure 2.1: The organizations and technical bodies that are engaged in Internet standardization.

ISOC

On the top level of Figure 2.1, the Internet Society (ISOC) is an organization whose task is to promote the use of the Internet for research and scholarly communication and collaboration. According to the ISOC's home page,[6] the mission is "to assure the open development, evolution, and use of the Internet for the benefit of all people throughout the world." As such, the ISOC is the organizational home of all technical bodies illustrated in Figure 2.1 and further addressed next. Also, an ever-increasing number of issues, such as censorship and freedom of expression, taxation, governance, and intellectual property protection, are discussed within the ISOC.

The ISOC was formed in 1992 as an international nonprofit membership organization. ISOC members can either be individuals (i.e., individual members) or organizations (i.e., organizational members). The ISOC holds an annual meeting, hosts several conferences,[7] and periodically publishes a newsletter. Also, a newsletter entitled OnTheInternet is available in electronic form.[8]

IAB

The Internet Architecture Board (IAB) is an appointed group that assists in the management of the Internet standards process operating under the auspices of the ISOC.[9] As such, the IAB is the technical advisory group of the ISOC and acts as a source of advice and guidance to the board of trustees and officers of the ISOC concerning technical, architectural, procedural, and (where appropriate) policy matters pertaining to the Internet and its enabling technologies. Also, the IAB is responsible for editorial management and publication of the Request for Comments (RFC) series of documents, and for the administration of the various Internet assigned numbers. More information about the IAB is available at its home page.[10] The IAB has two task forces:

  • The Internet Engineering Task Force (IETF);

  • The Internet Research Task Force (IRTF).

Both the IETF and the IRTF have steering groups associated with them. They are called Internet Engineering Steering Group (IESG) and Internet Research Steering Group (IRSG), respectively. The task forces and their appropriate steering groups are addressed next.

IETF and IESG

The IETF is the task force of the IAB that elaborates on engineering and operational issues related to TCP/IP networking in general, and the Internet in particular. According to the IETF home page,[11] the IETF "is a large, open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual." The IETF organizes and holds a meeting three times a year in various places throughout the world.[12]

The technical work of the IETF is done in working groups (WGs) that are organized by topic into several areas. Table 2.1 overviews the IETF technical areas as of March 2001 (in alphabetical order). Every technical area has a director who is ultimatively responsible for coordinating the activities in this area. Note that this book addresses Internet and intranet security, and as such it primarily focuses on the work that is done within the IETF Security Area.[13] Further information about the IETF Security Area is available from a special home page hosted at Massachusetts Institute of Technology (MIT).[14]

Table 2.1: IETF Technical Areas (March 2001)

Application Area

General Area

Internet Area

Operational Requirements Area

Routing Area

Security Area

Transport Area

User Services Area

Each IETF technical area has WGs that handle specific design and specification projects according to its charter, which includes, for example, projected milestones. In theory, participation in these WGs is by individuals and not by representatives of organizations and companies. In practice, however, the WGs are populated mostly by individuals representing organizations and companies that are interested in having specific technologies and protocols be submitted to and forwarded on the Internet standards track. Participants of IETF WGs can either meet during the IETF meetings or outside these meetings. In addition, they regularly discuss draft documents and other issues using mailing lists.

Table 2.2 overviews the IETF Security Area WGs as of March 2001 (again in alphabetical order). Note that new WGs are dynamically created and old ones become obsolete. Consequently, the current set of active IETF Security Area WGs may look different by the time you read this book. Refer to the IETF home page to get a more accurate and up-to-date picture. Also note that uppercase letters are used to refer to the WGs' acronyms in this book (in contrast to the acronyms used on the relevant IETF Web pages).

Table 2.2: Active IETF Security Area WGs (as of March 2001)

Name

Acronym


An Open Specification for Pretty Good Privacy

OPENPGP

Authenticated Firewall Traversal

AFT

Common Authentication Technology

CAT

IP Security Policy

IPSP

IP Security Protocol

IPSEC

IP Security Remote Access

IPSRA

Intrusion Detection Exchange Format

IDWG

Kerberized Internet Negotiation of Keys

KINK

Kerberos WG

KRB-WG

Multicast Security

MSEC

One Time Password Authentication

OTP

Public-Key Infrastructure (X.509)

PKIX

S/MIME Mail Security

SMIME

Secure Network Time Protocol

STIME

Secure Shell

SECSH

Securely Available Credentials

SACRED

Security Issues in Network Event Logging

SYSLOG

Transport Layer Security

TLS

Web Transaction Security

WTS

XML Digital Signatures

XMLDSIG

In the remaining parts of this book, we summarize and briefly discuss some of the major results that have been achieved in some of the IETF Security Area WGs mentioned in Table 2.2:

  • The OPENPGP WG and the SMIME WG specify open standards for secure messaging on the Internet (i.e., OpenPGP and S/MIME). We briefly introduce and elaborate on these evolving standards in Chapter 17 when we talk about message security protocols.

  • The AFT WG specifies a protocol that can be used to securely traverse a firewall system (i.e., the SOCKS protocol). We address the SOCKS protocol in Chapter 9 about circuit-level gateway.

  • The CAT WG specifies a common generic security services application programming interface (GSS-API) for authentication and key distribution systems, such as the Kerberos systems. This book does not primarily address software developers, so we do not delve into the technical details of the GSS-API in this book. Nevertheless, we address the Kerberos authentication system and some extensions thereof in Chapter 16 which focuses on application layer security protocols.

  • The IPSP, IPSEC, and IPSRA WGs all address aspects related to Internet layer security protocols (i.e., the IPsec protocols). As such, we address the results and the current status of these WGs in Chapter 14.

  • The IDWG WG specifies a standardized exchange format for data collected by intrusion detection systems (IDS). This book mainly focuses on security technologies to provide access control and communication security services. As such, it only briefly addresses IDS at the end of the book.

  • The KINK and KRB-WG WGs both address aspects of using the Kerberos authentication system on the global Internet. As mentioned, we address the Kerberos system and some extensions thereof in Chapter 16 when we talk about application layer security protocols.

  • The MSEC WG addresses issues related to multicast security. Multicast security is a relatively new topic and field of study. It is only briefly addressed in Chapter 14, when we discuss Internet layer security protocols.

  • The OTP WG specifies and standardizes a one-time password authentication scheme for the Internet. We elaborate on one-time passwords in Chapter 6 about authentication and key distribution.

  • The PKIX WG focuses on X.509 certificates and their use to establish a public key infrastructure (PKI) for the global Internet. We address the results of this WG in Chapter 19 when we examine PKIs.

  • The STIME WG specifies a protocol that can be used to securely determine the time on the Internet. As this book will demonstrate, many security technologies depend on accurate time settings and synchronized clocks (e.g., the Kerberos system). Consequently, having a protocol to securely determine the time on the Internet is very important. However, we do not address the protocol in this book.

  • The SECSH WG provides an open specification for the Secure Shell (SSH) protocol that is widely deployed on the Internet. We address the results of this WG in Chapter 16 about application layer security protocols.

  • The SACRED WG elaborates on possibilities to use and secure credentials (e.g., public key certificates) on the Internet. This WG was chartered only recently and has not provided any results thus far.

  • The SYSLOG WG documents and tries to improve the security of the syslog mechanism used in the UNIX operating system. Similar to the SACRED WG, this WG was chartered only recently and has not provided any results yet.

  • The TLS WG specifies a standardized transport layer security protocol for the Internet. We address the results of this WG in Chapter 15 when we examine transport layer security protocols for the Internet.

  • The WTS WG focuses on the requirements for secure transactions on the Web. As such, we briefly address some results of this WG in Chapter 16 about application layer security protocols.

  • The XMLDSIG elaborates on using XML to digitally sign documents. The results of this WG are not addressed in this book (they are only briefly mentioned in Chapter 17 when we discuss message security and message security protocols).

The IESG is the steering group of the IETF. It recommends actions on standardization to the IAB (most actions are recommended by the IESG and approved by the IAB). The IESG consists of a group of people that basically includes all directors of the IETF technical areas. As of this writing, the director of the General Area serves as chair of the IESG (and also chairs the IETF and is a member of the IAB). The IAB appoints a new IETF chair and all IESG candidates from a list provided by the IETF nominating committee.

IRTF and IRSG

As its name suggests, the IRTF is the task force of the IAB that is responsible for topics that are oriented toward research (rather than operational engineering). According to its home page,[15] the mission of the IRTF is "to promote research of importance to the evolution of the future Internet by creating focused, long-term, and small research groups working on topics related to Internet protocols, applications, architecture and technology." As such, the IRTF has chartered a number of research groups that are enumerated in Table 2.3. Furthermore, both a privacy and security research group, and an information infrastructure architecture research group were chartered almost two decades ago, but have ceased operation. As such, they are of historical interest only.

Table 2.3: IRTF Research Groups (as of March 2001)

Authentication Authorisation Accounting Architecture

Building Differentiated Services

End-to-End

Internet Resource Discovery

Interplanetary Internet

Network Management

NameSpace

Reliable Multicast

Routing

Secure Multicast

Services Management

The IRTF research groups guidelines and procedures are described and fully explained in RFC 2014 [6]. The IRTF is managed by the IRTF chair in consultation with the IRSG. The IRSG, in turn, is the steering group of the IRTF. Its membership includes the IRTF chair, the chairs of the various research groups, and other individuals from the research community. Furthermore, the IRTF chair is appointed by the IAB, the research group chairs are appointed as part of the formation of research groups, and all other IRSG members are chosen by the IRTF chair in consultation with the rest of the IRSG and on approval of the IAB. In addition to managing the research groups, the IRSG may hold topical workshops focusing on research areas of importance to the evolution of the Internet, or more general workshops, for example, to discuss research priorities from an Internet perspective.

ICANN

The Internet Corporation for Assigned Names and Numbers (ICANN) is the non-profit corporation that was formed to assume responsibility for the IP address space allocation, protocol parameter assignment, domain name system management, and root server system management functions previously performed under U.S. government contract by the Internet Assigned Numbers Authority (IANA) and some other entities.

Further information about ICANN and its mission is available from its home page.[16] Furthermore, the numbers assigned by the IANA are available at ftp://ftp.isi.edu/in-notes/iana/assignments/.

RFC Editor

The RFC Editor is responsible for the final editorial review of the documentation series described in Section 2.3.2. The ISOC funds the RFC Editor function. More information is available from the RFC Editor home page.[17]

2.3.2 Documentation Series

A key to the rapid growth of the Internet has been the free and open access to basic documents, especially the specifications of the protocols that collectively constitute the TCP/IP communications protocol suite. There are two major series of documents related to Internet standardization: Internet-Drafts and RFC documents.

Internet-Drafts

Internet-Drafts are working documents of the IETF and its technical areas' WGs. During the development of a protocol specification, Internet-Drafts are made publicly available for informal review and comment by placing them in a specific IETF Internet-Drafts' directory.[18] The directory is replicated on a number of mirror sites to make the evolving Internet-Drafts readily available to a wide audience, facilitating the process of public review and revision considerably.[19]

Internet-Drafts are valid for a maximum of 6 months and may be updated, replaced, and made obsolete by other documents at any time. An Internet-Draft that is published as an RFC, or that has remained unchanged in the Internet-Drafts directory for more than 6 months without being recommended by the IESG for publication as an RFC, is silently discarded and removed from the IETF Internet-Drafts' directory. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt.

Because of their transient nature, it is inappropriate to use Internet-Drafts as reference material or to cite them as anything other than "work in progress." Following this commonly agreed convention, Internet-Drafts are not referenced in this book. Where necessary and appropriate, Internet-Drafts are appended as footnotes to the text.

RFC Documents

The beginnings of the ARPANET and the Internet were characterized by a university research community that promoted and celebrated the academic tradition of open publication of ideas and results. The normal cycle of academic publication, however, turned out to be too formal and slow for the dynamic exchange of ideas essential for the design and implementation of computer networks and distributed systems. Consequently, a new series of documents was established in 1969. The documents were called RFCs and were intended to be an informal fast-distribution way to share ideas with other researchers. As such, the series of RFC documents steadily increased its importance in the research community. Today, it is the official publication channel for the IETF. In addition to protocol specifications that are submitted to the Internet standards track, the RFC documents cover a wide range of topics, such as early discussion of new research topics, concepts, and status memos about the Internet as a whole.

RFC publication is the direct responsibility of the RFC Editor, under the general direction of the IAB. RFC documents are numbered and usually referred to by their appropriate numbers. They can be obtained from the IETF RFC home page[20] or any other Internet site that serves as an RFC archive.[21]

The rules for formatting and submitting RFC documents are defined in RFC 1543 [7]. In short, every RFC must be available in ASCII text format and may additionally be available in other formats. In this case, the other versions of the RFC may contain additional material such as diagrams, figures, and illustrations not present in the ASCII text version, and it may be formatted differently. For protocol specifications that are submitted to the Internet standards track, however, the ASCII text version is considered as the definitive reference. As such, it must be a complete and accurate specification of the standard, including all necessary diagrams, figures, and illustrations.

There are several subseries within the series of RFC documents. These subseries are briefly overviewed next. A good archive for RFC documents and its various subseries is available at http://www.faqs.org/rfcs/.

STD Subseries Some RFC documents specify protocols that are submitted to the Internet standards track, and some of these protocol specifications also reach the status of an Internet Standard. These RFC documents form the STD subseries. Each document within the STD subseries is labeled with an STD number (in addition to the RFC document number). For example, when the Post Office Protocol version 3 (POP3) specified in RFC 1939 [8] became an Internet Standard, it was officially assigned the STD number 53. Consequently, RFC 1939 and STD 53 refer to the same protocol specification (i.e., POP3). Note that the STD number of a protocol always refers to the latest specification of the protocol, and that there may be several RFC documents specifying various versions of a protocol. For example, RFC 1725 specifies an elder version of POP3 and RFC 1939 has made this version obsolete. Nevertheless, STD 53 still refers to both RFC 1725 and RFC 1939. Because of the incremental nature of the RFC document numbering scheme, this ambiguity does not pose any problem. STD 1 (currently RFC document 2700) [9] describes the state of standardization of protocols used in the Internet. This document is the authoritative source for references on Internet Standards. In addition, an STD document index is available at http://www.faqs.org/rfcs/std/std-index.html.

BCP Subseries In the past, Internet Standards were mainly concerned with the technical specifications for the protocols that collectively form the TCP/IP communications protocol stack. Because the Internet itself is composed of networks operated by a great variety of companies and organizations with diverse goals and rules, good user service also requires that the operators and administrators of these networks follow some common guidelines for policy and operation. While these guidelines are usually different in scope and style from protocol standards, their establishment needs a similar process for consensus building. Therefore, some RFC documents elaborate on the results of community deliberations about statements of principle or conclusions about what is the best way to perform some specific operations or IETF process function. These RFC documents form the best current practice (BCP) subseries. Similar to the STD subseries, the RFC documents published in the BCP subseries are assigned additional BCP numbers. A BCP document index is available at http://www.faqs.org/rfcs/bcp/bcp-index.html.

FYI Subseries Finally, not all specifications of protocols or services should or will become part of the STD or BCP subseries [10]. Such nonstandard track specifications are not subject to the rules for Internet standardization. Nonstandard track specifications may be published as experimental or informational RFCs at the discretion of the RFC Editor in consultation with the IESG [8]. Some of these RFC documents form the FYI subseries, with FYI meaning "for your information." An FYI document index is available at http://www.faqs.org/rfcs/fyi/fyi-index.html.

2.3.3 Internet Standards Process

In the past, TCP/IP protocols were often specified and implemented ad hoc with little formality; this informality was considered to be a major factor in their success. This situation has changed. Today, there are many people involved in specifying TCP/IP protocols and even more people involved in implementing, testing, and using them. In this new environment, a more formal, or at least more codified, Internet standards process is urgently needed.

In short, an Internet Standard refers to a protocol specification that is stable and well understood; is technically competent; has multiple, independent, and interoperable implementations with substantial operational experience; enjoys significant public support; and is recognizably useful in some or all parts of the Internet. In theory, the process of creating Internet Standards is simple and straightforward. A protocol specification undergoes a period of development and several iterations of review by the Internet community and revision based upon experience, is adopted as an Internet Standard by the appropriate body, and is finally published in an appropriate format. In practice, however, the process is more complicated, due to the difficulty of creating specifications of high technical quality, the need to consider the interests of all affected parties, the importance of establishing widespread community consensus, and the difficulty of evaluating the utility of a particular specification for the Internet community.

According to RFC 2026 and BCP 9 [11], the Internet standards process is an activity of the ISOC that is organized and managed on behalf of the Internet community by the IAB and IESG. It is concerned with all protocols, procedures, and conventions that are used in or by the Internet, whether or not they are part of the TCP/IP communications protocol suite. As such, it resembles many other standards processes, including, for example, the one employed by the ISO.[22]

In theory, the Internet standards process distinguishes between technical specifications and applicability statements:

  • A technical specification is a description of a protocol, service, procedure, convention, or format that either completely describes all of its relevant aspects or leaves one or more parameters or options unspecified. Consequently, a technical specification may be completely self-contained, or it may incorporate material from other specifications by reference to other documents. A technical specification must include a statement of its scope and the general intent for its use. Thus, a technical specification that is inherently specific to a particular context will contain a statement to that effect. However, a technical specification does not specify requirements for its use within the Internet; these requirements, which depend on the particular context in which the technical specification is incorporated by different system configurations, are defined by a corresponding applicability statement.

  • An applicability statement specifies how, and under what circumstances, one or more technical specifications may be applied to support a particular Internet capability. An applicability statement identifies the relevant technical specifications and the specific way in which they are to be combined, and may also specify particular values or ranges of technical specification parameters or subfunctions of a technical specification protocol that must be implemented.

Although technical specifications and applicability statements are conceptually separate, in practice an Internet standards track document may combine an applicability statement and one or more related technical specifications. For example, technical specifications that are developed specifically and exclusively for some particular domain of applicability, such as for e-mail servers, often contain within a single specification all of the relevant applicability statement and technical specification information. In such cases, no useful purpose would be served by deliberately distributing the information among several documents just to preserve the formal distinction between technical specifications and applicability statements. However, a technical specification that is likely to apply to more than one domain of applicability should be developed in a modular fashion to facilitate its incorporation by multiple applicability statements.

In the Internet standards process, each specification (i.e., a technical specification or an applicability statement) is assigned a requirement level (sometimes also called an applicability status) and a maturity level. As illustrated in Figure 2.2, this leads to a two-dimensional classification scheme for Internet specifications. Requirement and maturity levels are overviewed and briefly discussed next.

click to expand
Figure 2.2: The two-dimensional classification scheme for Internet specifications.

Requirement Levels

The Internet standards process distinguishes among five requirement levels that may be assigned to technical specifications and/or applicability statements (the levels are indicated on the vertical axis in Figure 2.2):

  • Required: Implementation is required to achieve minimal conformance.

  • Recommended: Implementation is not required for minimal conformance, but experience or generally accepted technical wisdom suggest its desirability in the domain of applicability. Vendors are strongly encouraged to include the functions, features, and protocols of recommended specifications in their products, and should omit them only if the omission is justified by some special circumstance.

  • Elective: Implementation is optional within the domain of applicability. However, a particular vendor may still decide to implement it, or a particular user may decide that it is a necessity in a given environment.

  • Limited use: Implementation is considered to be appropriate for use only in limited or unique environments.

  • Not recommended: Implementation is considered to be inappropriate for general use. This may be because of its limited functionality, specialized nature, or historic status.

The first three requirement levels (i.e., required, recommended, and elective) may be assigned to specifications that are submitted to the Internet standards track. For example, IP and ICMP are required and must be implemented by all Internet hosts using the TCP/IP protocols. In addition, the Telnet protocol is recommended and should be implemented by all hosts that would benefit from remote terminal access, whereas the DECnet management information base (MIB) is elective and could be seen as valuable only in environments where DECnet protocols are still in use (certainly a rare species today). The other two requirement levels (i.e., limited use and not recommended) may be assigned to specifications that are not submitted to the Internet standards track or have been retired from it.

Maturity Levels

In addition to the five requirement levels, the Internet standards process distinguishes among six maturity levels that may be assigned to technical specifications or applicability statements (the maturity levels are indicated on the horizontal axis in Figure 2.2). Three maturity levels (i.e., Proposed Standard, Draft Standard, and Internet Standard) may be assigned to specifications that are submitted to the Internet standards track. The three other maturity levels (i.e., informational, experimental, and historic) may be assigned to specifications that are not submitted to the Internet standards track (in the case of informational and experimental) or have been retired from it (in the case of historic).

  • Proposed Standard: A specification that is generally stable, has resolved known design choices, is believed to be well understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. Nevertheless, further experience might result in a change or retraction of the specification before it advances on the Internet standards track. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable and will usually represent a strong argument in favor of a Proposed Standard designation. As a matter of fact, the IESG may require implementation or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them to gain experience and to validate, test, and clarify the specification. However, because the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. A specification must remain at the Proposed Standard level for at least 6 months.

  • Draft Standard: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the Draft Standard level. The corresponding WG chair is responsible for documenting the specific implementations that qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of each of the individual options and features. This documentation should be submitted to the responsible IETF area director with the protocol action request. In general, elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful. A Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered. In most circumstances, it is reasonable for vendors to deploy implementations of Draft Standards into a disruption-sensitive environment. A specification must remain at the Draft Standard level for at least 4 months, or until at least one IETF meeting has occurred, whichever comes later.

  • Internet Standard: A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community. A specification that reaches the status of an Internet Standard is assigned a number in the STD subseries while retaining its RFC number.

  • Informational: A specification that is published for the general information of the Internet community and does not represent an Internet community consensus or recommendation.

  • Experimental: A specification that is part of some research or development effort. Such a specification is published for the general information of the Internet community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process.

  • Historic: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete.[23]

The informational, Internet Standard, and historic states are permanent, or at least there is no limit on how long a protocol may stay in one of those states. That is the reason why they are shown as rectangles in Figure 2.2. The other states are all temporary and transient. As such, they are shown as ellipses.

Standardization Process

The Internet standardization process requires decisions of the IESG concerning the elevation of a specification onto the Internet standards track or the movement of a standards track specification from one maturity level to another (e.g., from a Proposed Standard to a Draft Standard or from a Draft Standard to an Internet Standard). Although a number of reasonably objective criteria are available to guide the IESG in making a decision to move a protocol specification onto, along, or off the standards track, there is no guarantee of elevation to or progression along the standards track for any specification. The experienced collective judgment of the IESG concerning the technical quality of a specification is an essential component of the decision-making process.

A specification that is intended to enter or advance in the Internet standards track must be posted as an Internet-Draft unless it has not changed since publication in an RFC document. It shall remain as an Internet-Draft for a period of time, not less than 2 weeks, that permits useful community review, after which a recommendation for action may be initiated. A standards action is initiated by a recommendation by the IETF WG responsible for the specification to its area director, copied to the IETF secretariat, or, in the case of a specification not associated with a WG, a recommendation by an individual to the IESG. The IESG then determines whether or not the specification satisfies the applicable criteria for the recommended action and must also determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. The IESG sends notice to the IETF of the pending IESG consideration of the documents to permit a final review by the Internet community. This last-call notification will be through e-mail to the IETF announce mailing list. Comments will be accepted from anyone, and should be sent as directed in the last-call announcement. The last-call period will be no shorter than 2 weeks except in those cases where the Proposed Standards action was not initiated by an IETF WG, in which case the last-call period will be no shorter than 4 weeks. If the IESG believes that the community interest would be served by allowing more time for comment, it may decide on a longer last-call period or to explicitly lengthen a period. In a timely fashion after the expiration of the last-call period, the IESG shall make its final determination of whether or not to approve the standards action and will notify the IETF of its decision again through e-mail to the IETF announce mailing list. If a standards action is approved, notification is sent to the RFC editor and copied to the IETF with instructions to publish the specification as an RFC. The specification will at that point be removed from the Internet-Draft directory.

Note that the minimum time for a protocol specification to reach Internet Standard status is 10 months (6 months for Proposed Standard and another 4 months for Draft Standard). These minimum periods are intended to ensure adequate opportunity for community review without severely impacting timeliness. When a standards track specification has not reached the Internet Standard level but has remained at the same maturity level for at least 2 years, and every year thereafter until the status is changed, the IESG shall review the viability of the standardization effort responsible for that specification and the usefulness of the technology. Following each such review, the IESG will approve termination or continuation of the development effort. At the same time the IESG will also decide to maintain the specification at the same maturity level or to move it to historic status. This provision is not intended to threaten a legitimate and active WG effort, but to provide an administrative mechanism for terminating a moribund effort.

A new version of an established Internet Standard must progress through the full Internet standardization process as if it were a completely new specification. As technology changes and matures, it is possible and even likely that the new Internet Standard specification is so clearly technically superior that one or more existing standards track specifications for the same function should be retired. In this case, or when it is felt for some other reason that an existing standards track specification should be retired, the IESG will approve a change of status of the old specifications to historic. This recommendation will be issued with the same last-call and notification procedures used for any other standards action. A request to retire an existing standard can originate from a WG, an area director, or some other interested party. In other cases, both versions may remain Internet Standards to honor the requirements of an installed base. In this situation, the relationship between the previous and the new versions must be explicitly stated in the text of the new version or in another appropriate document.

Disputes are possible and likely to appear at various stages during the Internet standards process. As much as possible, the process is designed so that compromises can be made and genuine consensus achieved. However, there are times when even the most reasonable and knowledgeable people are unable to agree. Such conflict must be resolved by a process of open review and discussion. RFC 2026 specifies the procedures that shall be followed to deal with Internet Standards issues that cannot be resolved through the normal processes whereby IETF WGs and other Internet standards process participants ordinarily reach consensus [11].

[6]http://www.isoc.org

[7]The largest and most important conference of the ISOC is the INET conference, which is held annually at various locations around the globe.

[8]http://www.isoc.org/oti/

[9]Until June 1992, the acronym IAB was used to refer to "Internet Activities Board."

[10]http://www.iab.org

[11]http://www.ietf.org

[12]For example, the 51th and 52th IETF Meetings were scheduled to take place in August 2001 (in London) and December 2001 (in Salt Lake City, Utah), respectively.

[13]Some work is done in working groups that jointly belong to more than one technical area. For example, the Transport Layer Security (TLS) WG is jointly chartered by the Security and Transport Areas.

[14]http://web.mit.edu/network/ietf/sa/

[15]http://www.irtf.org

[16]http://www.icann.org

[17]http://www.rfc-editor.org

[18]http://www.ietf.org/ID.html

[19]As of this writing, a list of currently available IETF mirror sites for Internet-Drafts is available at http://www.ietf.org/shadow.html.

[20]http://www.ietf.org/rfc.html.

[21]A well-designed archive is available at http://www.faqs.org/rfcs/.

[22]In the ISO standards process, a specification first becomes a committee draft (CD), before it moves forward to become a draft international standard (DIS) and international standard (IS).

[23]Some people have suggested that the correct word for "historic" should be "historical"; however, the use of "historic" is historical.


Team-Fly


Internet and Intranet Security
Internet & Intranet Security
ISBN: 1580531660
EAN: 2147483647
Year: 2002
Pages: 144

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net