25.02.2013 Views

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

The process of st<strong>and</strong>ardization is summarized as follows:<br />

► In order to have a new specification approved as a st<strong>and</strong>ard, applicants have<br />

to submit that specification to the IESG where it will be discussed <strong>and</strong><br />

reviewed for technical merit <strong>and</strong> feasibility <strong>and</strong> also published as an Internet<br />

draft document. This should take no shorter than two weeks <strong>and</strong> no longer<br />

than six months.<br />

► After the IESG reaches a positive conclusion, it issues a last-call notification<br />

to allow the specification to be reviewed by the whole Internet community.<br />

► After the final approval by the IESG, an Internet draft is recommended to the<br />

Internet Engineering Taskforce (IETF), another subsidiary of the IAB, for<br />

inclusion into the St<strong>and</strong>ards Track <strong>and</strong> for publication as a Request for<br />

Comments (see 1.3.1, “Request for Comments (RFC)” on page 22).<br />

► Once published as an RFC, a contribution may advance in status as<br />

described in 1.3.2, “Internet st<strong>and</strong>ards” on page 24. It may also be revised<br />

over time or phased out when better solutions are found.<br />

► If the IESG does not approve of a new specification after, or if a document<br />

has remained unchanged within, six months of submission, it will be removed<br />

from the Internet drafts directory.<br />

1.3.1 Request for Comments (RFC)<br />

The Internet protocol suite is still evolving through the mechanism of Request for<br />

Comments (RFC). New protocols (mostly application protocols) are being<br />

designed <strong>and</strong> implemented by researchers, <strong>and</strong> are brought to the attention of<br />

the Internet community in the form of an Internet draft (ID). 1 The largest source<br />

of IDs is the Internet Engineering Task Force (IETF), which is a subsidiary of the<br />

IAB. However, anyone can submit a memo proposed as an ID to the RFC Editor.<br />

There are a set of rules which RFC/ID authors must follow in order for an RFC to<br />

be accepted. These rules are themselves described in an RFC (RFC 2223),<br />

which also indicates how to submit a proposal for an RFC.<br />

After an RFC has been published, all revisions <strong>and</strong> replacements are published<br />

as new RFCs. A new RFC that revises or replaces an existing RFC is said to<br />

“update” or to “obsolete” that RFC. The existing RFC is said to be “updated by” or<br />

“obsoleted by” the new one. For example RFC 1542, which describes the<br />

BOOTP protocol, is a “second edition,” being a revision of RFC 1532 <strong>and</strong> an<br />

amendment to RFC 951. RFC 1542 is therefore labelled like this: “Obsoletes<br />

RFC 1532; Updates RFC 951." Consequently, there is never any confusion over<br />

1 Some of these protocols can be described as impractical at best. For instance, RFC 1149 (dated<br />

1990 April 1) describes the transmission of <strong>IP</strong> datagrams by carrier pigeon <strong>and</strong> RFC 1437 (dated<br />

1993 April 1) describes the transmission of people by electronic mail.<br />

22 <strong>TCP</strong>/<strong>IP</strong> <strong>Tutorial</strong> <strong>and</strong> <strong>Technical</strong> <strong>Overview</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!