As usual, it takes a while for the gears to start grinding RFCs and protocol actions out again after an IETF meeting. Pittsburgh is no exception, but at least we’re going again.
Though not yet an RFC, an interesting Internet-Draft came out recently, titled “ Defining the IETF. (If a new version comes out between the time I wrote this and the time you read it, you may want to try changing the “-03” to “-04” to make that link work.)
It’s interesting because it tackles the question, what exactly is the IETF? It’s also interesting because the answer — at least, the draft answer — turns out to be that the IETF is the group that acts in accordance with BCP 9 (“The Internet Standards Process – Revision 3”, RFC 2026) and BCP 11 (“The Organizations Involved in the IETF Standards Process”, RFC 2028). So, now that that’s settled, let’s take a look at what’s been happening.
There are just a few RFCs this time around, listed in Table 1. To start with, we have a couple of stragglers from July about Internet fax that didn’t get announced until the end of the first week in August: RFC 2879, “Content Feature Schema for Internet Fax (V2),” and RFC 2880, “Internet Fax T.30 Feature Mapping.”
RFC 2879 is a Proposed standard, and it updates and replaces RFC 2531, “Content Feature Schema for Internet Fax.” The document describes a framework for exchanging information about content features of faxes transmitted over the Internet. However, the changes noted in the appendix indicate that the update is largely editorial rather than substantive, with one appendix getting an update to be more complete and correct, and with examples being updated to accord with the T.30 specification.
That brings us to RFC 2880, which covers mapping T.30 features onto Internet fax. This Informational RFC “describes how to map Group 3 fax capability identification bits described in ITU T.30 [the ITU specification for facsimile transmission], into the Internet fax feature schema described in” RFC 2879. So, if you’re into Internet fax, these are important RFCs for you.
Reliable multicast is almost an oxymoron, according to the authors of RFC 2887: Multicast implies many recipients, while reliability implies significant bandwidth for making sure each recipient has gotten everything. RFC 2887, “The Reliable Multicast Design Space for Bulk Data Transfer,” is an Informational that presents an interesting review of the factors that constrain the way reliable multicast can be implemented. Anyone interested in building or using reliable multicast applications would do well to review this one.
Next comes an Informational, RFC 2888, “Secure Remote Access with L2TP”, which is worth reading if, like so many other corporate network managers, you’re facing a growing contingent of users who want to access your corporate network through the Internet rather than directly through dedicated dialup lines. As the author, Pyda Srisuresh, of Mipitas, Calif.-based Campio Communications Inc., puts it: “The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial in through the Internet.” (L2TP itself is specified in “Layer Two Tunneling Protocol L2TP”, RFC 2661.) According to Srisuresh, new protocols are not necessary. This RFC “proposes three new RADIUS parameters for use by the LNS [L2TP Network Server] node, acting as a Secure Remote Access Server (SRAS) to mandate network level security between remote clients and the enterprise.”
RFC 2889, “Benchmarking Methodology for LAN Switching Devices,” is another product of the Benchmarking Methodology Working Group (BMWG). This document provides a methodology for doing benchmark testing of LAN switches, covering test setup, frame formats and sizes, benchmarking testing procedures and reporting.
Another Proposed standard, RFC 2891, “LDAP Control Extension for Server Side Sorting of Search Results,” describes two control extensions for LDAPv3 that enable “server side sorting of search results.” Usually, the client making an LDAP request performs this type of function; when a client does not have the ability to do such sorting (for example, a dumb terminal), these extensions will help make it possible to do the sorting on the server.
Finally, RFC 2894, “Router Renumbering for IPv6,” is a new Proposed standard. IPv6 provides much greater flexibility in assigning and reassigning host numbers with IPv6 Neighbor Discovery and stateless address autoconfiguration; Router Renumbering (RR), as defined in this RFC, provides a mechanism that allows routers to be renumbered almost as easily.
Document, protocol, and working group actions
There hasn’t been much action this time in the document, protocol, and working group action department–no working group actions and not even a full dozen document and protocol actions (which are conveniently listed in Table 2). The one big one this time is “Use of HTTP State Management,” which is to be published as a Best Current Practices (BCP) document.
Of course, HTTP state management is actually the technical term for cookies, as spelled out in RFC 2109, “HTTP State Management Mechanism.” RFC 2109 was published about three and a half years ago, so it’s getting a bit stale. It shouldn’t be a surprise that the successor document, draft-ietf-http-state-man-mec-12.txt, of the same name, was just approved for publication.
This BCP-to-be is an important document: It helps put the controversy over cookies in perspective, outlining the “recommended” uses and the “problematic” uses for cookies, and providing guidelines for how cookies should be implemented on clients.
The stream of new RFCs and protocol/document actions should continue to gradually increase over the coming weeks, especially as everyone involved comes home from their summer vacations. If you’re interested in the updated messaging RFCs, you might want to check out the recent flurry of activity in the working group mailing lists: After being virtually moribund for months, we may soon see a resolution to the issues deviling those groups for so long. //
Pete Loshin has been writing about IP networking since 1988, including 20 books about networking, the Internet, and Internet standards. The founder of Internet-Standard.com, Pete frequently consults on Internet protocol issues.