All the IETF news that’s fit to print

Pete Loshin

With the end of the 47th IETF (Internet Engineering Task Force) meeting just two months ago in Adelaide, Australia, and just one more month to go before the 48th in Pittsburgh, Pa., there’s plenty going on. The upcoming IETF meeting means travel to an exotic (for some) locale, but it also means we’ll be seeing more Internet-Drafts in the pipeline in coming weeks as well as more RFCs published in the weeks after the meeting. In the meantime, there’s plenty of news to track.

New RFCs

"By the way, if you plan to be in Pittsburgh, Pa., for the July 30 to August 4 IETF meeting, check your hotel reservations: Doubletree Pittsburgh reportedly cancelled over 70 confirmed reservations due to overbooking. Otherwise, you may want to bring your sleeping bag!


The last two weeks have seen publication of an even dozen new RFCs (request for comments), listed in Table 1. Of particular interest in the latest crop is a new Best Current Practices, BCP 40 (RFC 2870), “Root Name Server Operational Requirements,” which documents formal guidelines for the proper operation of root DNS servers.

Table 1: RFCs Published June 11 – June 25, 2000

RFC Title Status Date
2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services Standards Track June 2000
2849 The LDAP Data Interchange Format (LDIF) – Technical Specification Standards Track June 2000
2851 Textual Conventions for Internet Network Addresses Standards Track June 2000
2852 Deliver By SMTP Service Extension Standards Track June 2000
2853 Generic Security Service API Version 2 : Java Bindings Standards Track June 2000
2854 The ‘text/html’ Media Type Informational June 2000
2855 DHCP for IEEE 1394 Standards Track June 2000
2856 Textual Conventions for Additional High Capacity Data Types Standards Track June 2000
2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH Standards Track June 2000
2858 Multiprotocol Extensions for BGP-4 Standards Track June 2000
2860 Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority Informational June 2000
BCP 40
(RFC 2870)
Root Name Server Operational Requirements Best Current Practice June 2000

Also notable: RFC 2860, “Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority,” which outlines the terms under which the Internet Assigned Numbers Authority (IANA) will function as it’s handed over to ICANN (Internet Corporation for Assigned Names and Numbers). Hardly news, though, since the MoU was signed back in March, 2000.

Of particular interest to IP telephony implementers is RFC 2848, “The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services,” defining PINT (PSTN/Internet Interworking). PSTN, of course, is the public switched telephone network, and PINT defines a protocol for “invoking certain telephone services from an IP network,” including “placing basic calls, sending and receiving faxes, and receiving content over the telephone.” The PINT Service Protocol builds on the SIP 2.0 (Session Initiation Protocol, RFC 2543) and SDP (Session Description Protocol, RFC 2327) protocols.

RFC 2849, “The LDAP Data Interchange Format (LDIF) – Technical Specification,” defines a standards track specification for a well-defined common interchange format for directory information. This RFC should help in the import and export of directory information, and will also aid those wishing to develop tools and applications that use data from existing databases or other sources and put it into a universally recognized format.

Also on the standards track, RFC 2852, “Deliver By SMTP Service Extension,” defines an extension for SMTP that allows the client to specify a time after which the message need not be delivered. In other words, a mail client can specify that if the message is not delivered by 5:00 pm, it should not be delivered at all. Mail servers are not supposed to treat this option as a mechanism for assigning priority to messages; rather, users could use it as a way to identify messages that lose relevance after a certain time.

RFC 2857, “The Use of HMAC-RIPEMD-160-96 within ESP and AH,” is another standards track RFC that describes how the RIPEMD-160 secure message digest algorithm is used together with the hashed message authentication code (HMAC, defined in RFC 2104) algorithm to authenticate data under the IP Security Architecture using the Encapsulating Security Payload (ESP, RFC 2406) and the Authentication Header (AH, RFC 2402).

Another standards track RFC that covers security issues, RFC 2853, “Generic Security Service API Version 2: Java Bindings,” specifies the Java bindings to GSS-API, which let calling applications use security services such as authentication and encryption. GSS-API itself is specified in RFC 2743, where it is described in programming language-independent language.

Document actions

Approval for publication of a couple of Internet-Drafts came through this past two weeks as well. Out of the Benchmarking Methodology Working Group comes the draft “Benchmarking Methodology for LAN Switching Devices”, which will be published as an Informational RFC. The Benchmarking Methodology group focuses on developing recommendations for testing and evaluating internetworking technologies, and this draft defines a set of benchmarks for LAN switching devices–meaning devices that switch frames at the Media Access Control (MAC) layer.

Another Informational-to-be, “The Reliable Multicast Design Space for Bulk Data Transfer”, comes out of the Reliable Multicast Transport Working Group. General-purpose multicast protocols are tough to build because there are so many different factors that affect their design, depending on the problem to be solved. This document reviews the various constraints placed on designers working on reliable multicast protocols for bulk data transfers.

Last calls and other activity

Eleven “last calls” were issued over the past two weeks, but if you have any comments you’d better hurry. The Internet Open Trading Protocol (IOTP) group continues to move their drafts forward, as does the Dynamic Host Configuration group. The current Last Calls are listed in Table 2.

Table 2: Last Calls, June 11-June 25, 2000

Title Filename
Identifying composite media features draft-ietf-conneg-feature-hash-04.txt
The Subnet Selection Option for DHCP draft-ietf-dhc-subnet-option-05.txt
Domain Name System (DNS) IANA Considerations draft-ietf-dnsext-iana-dns-00.txt
The User Class Option for DHCP draft-ietf-dhc-userclass-08.txt
Use of the CAST-128 Encryption Algorithm in CMS draft-ietf-smime-cast-128-02.txt
The Name Service Search Option for DHCP draft-ietf-dhc-nsso-04.txt
Internet Open Trading Protocol (IOTP) HTTP Supplement draft-ietf-trade-iotp-http-07.txt
HTTP MIME Type Handler Detection draft-ietf-trade-mime-detector-03.txt
Procedure for Defining New DHCP Options and Message Types draft-ietf-dhc-new-opt-msg-01.txt
Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients draft-ietf-rap-cops-client-mib-03.txt
DHCP Relay Agent Information Option draft-ietf-dhc-agent-options-10.txt

A new IETF working group has been formally proposed: Blocks eXtensible eXchange Protocol (bxxpwg). The aim of the group is to develop “a standards-track application protocol framework for connection-oriented, asynchronous request/response interactions.”

Phil Neumiller at Motorola Inc. and Pat R. Calhoun of Sun Microsystems Inc. are chairing the Common Radio Access Protocol Set (CRAPS) BoF, to discuss whether a working group should be chartered to design a handover protocol for seamless mobile wireless connectivity. (BoF stands for “Birds of a Feather” and BoF sessions are usually relatively informal meetings of anyone who has an interest in the topic of the BoF.) The work should then be applicable to wireless and cellular communications services, which enable, for example, seamless roaming across short and long distances. Interested? To subscribe to the mailing list, send e-mail to [email protected], with “subscribe [e-mail]” in the body.

Another BoF for the Small Group Multicast (SGM) is in the process of forming to consider whether the IETF should standardize a method for multicasting to small groups, where “small” is roughly between three and 10 members, or possibly as many as 20 members. The reasoning behind the project is based on two issues: first, some believe that some of the applications that might use multicast tend to have few members (such as audio and video conferencing); second, existing multicast mechanisms are thought to have scaling problems as the group size increases. If you’re interested in SGM, join the mailing list by sending e-mail to [email protected].

In other news, the Internetworking Over NBMA (ion) working group has been closed, as has the IP Over IEEE 1394 (ip1394) group. //

Pete Loshin has been writing about IP networking since 1988, including 20 books about networking, the Internet, and Internet standards. The founder of, Pete frequently consults on Internet protocol issues.

Latest Articles

Follow Us On Social Media

Explore More