IESG Working Group Actions, January - February 2001

By Pete Loshin | Feb 27, 2001 | Print this Page
http://www.enterprisenetworkingplanet.com/netsp/article.php/600411/IESG-Working-Group-Actions-January--February-2001.htm

With the new year, this column is changing format: Instead of appearing biweekly, we'll be appearing semi-monthly. And instead of offering a roundup of all IETF and IESG activities in each column, we'll be alternating between looking at the newest RFCs and covering all the other actions, from working group actions to the latest chatter on the IETF front.

The past month or so has seen an unusual number of working group actions by the IESG: nine new working groups announced since the start of the year (a tenth was announced December 2000), and six existing working groups' activities concluded during the same time.

Sub-IP

Much of this activity can be attributed to the decision by the IESG to institute a new sub-IP area, announced in November 2000. According to a message from IESG member and IETF Chair Fred Baker, the traditional focus of the IETF has been "above the wire and below the application," meaning the IETF does not concern itself with how data is transmitted at the link layer or with how applications are specified. At the wire, the IETF would leave specifications to other organizations such as the IEEE for Ethernet and the ATM Forum for ATM.

However, according to Baker, "Over the years the boundary between 'wires' and IP protocols has become harder to define and the interaction has become more intertwined." For example, Baker notes that a virtual network may appear to consist of wires or circuits that are actually routed datagrams traveling across an underlying IP network, and that dynamic networks such as ATM and optical media "can interact with IP-level traffic engineering and routing." Finally, he states that "technologies such as MPLS are defining a whole new class of 'wires'."

Thus, the need existed for a new IETF area, whose working groups will deal with sub-IP technologies. The first step is to define a pseudo-area for sub-IP, into which new working groups will be apportioned and existing groups, such as Multiprotocol Label Switching (mpls) and Internet Traffic Engineering (tewg), are to be moved. Four of the new working groups of the past couple of months are part of this new pseudo-area: Common Control and Measurement Plane (ccamp), Provider Provisioned Virtual Private Networks (ppvpn), IP over Resilient Packet Rings (iporpr), and IP over Optical (ipo).

First, we'll look at highlights of the new working groups; then we'll briefly summarize the concluding working groups. With IETF 50 coming up soon (in Minneapolis, March 18-23, 2001), everyone wants to make sure their new working groups are set up and the old ones that need to conclude are terminated properly.

Working the Working Groups

Table 1 lists new working groups approved so far in 2001. As already noted, four of these new groups are within the sub-IP pseudo-area, and focus on the area bridging the link layer with the network layer (layers 2 and 3). One of the more interesting is the Provider Provisioned Virtual Private Networks (PPVPN) group, chartered to define a few relatively standard solutions to the problem of service providers who wish to provide their customers with virtual private networks using open standards.

Table 1: New working groups, January 1 through February 22, 2001.

Most of the other new working groups are aimed at particularly vexing issues, because the Internet's growth seems to be slowed by issues of scalability.

The Multicast Security (MSEC) working group, chartered to "standardize protocols for securing group communication over internets, and in particular over the global Internet," will start by tackling the complicated problem of securing multicast groups with a single source and very large numbers of recipients.

Another scalability-focused group, Web Intermediaries (WEBI), will be working on mechanisms to standardize the way intermediaries such as caching proxies are updated, and to define requirements for discovery protocols for such intermediaries that respect the end-to-end networking model. Likewise, the Reliable Server Pooling (RSERPOOL) working group will attack scalability at the server by developing an architecture for pooled servers and protocols for managing those servers and for offering client access to server pools.

The Middlebox Communications (MIDCOM) working group should be worth following for its focus on "middle boxes": systems such as firewalls and network address translators (NATs) that implement policies (especially security and quality of service policies) but which are located in intermediate locations in the Internet. MIDCOM is chartered to develop mechanisms by which middleboxes can be controlled remotely to remove application logic from the middleboxes and give greater control over how that logic is disseminated and implemented.

The Silence of the Working Groups

Table 2 lists the ending working groups announced over the past month or so. Several of these groups have been more or less dormant, having produced no RFCs for some time. The FYI Updates (FYIUP) group never actually produced any updated FYIs; the Web Elucidation of Internet-Related Developments (WEIRD) group's results were also disappointing (see their IETF Info page).

Table 2: Concluding working groups, January 1 through February 22, 2001.

Other groups were more productive: The Simple Public Key Infrastructure (SPKI) group turned out a couple of experimental RFCs (RFC 2692, "SPKI Requirements," and RFC 2693, "SPKI Certificate Theory"). The Open Network Computing Remote Procedure Call (ONCRPC) working group put out five standards track RFCs through September 1999; part of its original charter, to develop an updated to NFS, was taken over by the NFSv4 working group.

The PSTN/Internet Interfaces (PINT) working group moved forward the cause of integrating the publicly switched telephone network (PSTN) with the Internet, and the Roaming Operating (ROAMOP) working group clarified issues related to roaming: "the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one."

What's Next

IETF 50 is only a month away. In the meantime, February saw publication of a solid couple of dozen new RFCs, including a new Best Current Practices (BCP) document, and just about everything else from new stuff on Session Initiation Protocol (SIP) to IPv6 to DHCP. //

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.