How The IETF Is Fixing Its Open Standards Process

In my last post, I discussed how we shouldn't toss aside the open standards model for open source, and how the two models complement each other. However, there still are issues -- whether real or perceived -- with the IETF and its attendant open standards process. Given the networking industry needs both open standards and open source, the IETF still needs to be “fixed.”

The IETF, as it turns out, is working hard on the apparent problems. A number of changes have been put in place in the last year to improve the speed at which the IETF can operate. This final post in my series on open standards and open source models examines these changes, along with the tradeoffs.

Area reorganization. The IETF is taking a hard look at the way the areas of work are laid out, moving work around where it makes sense to improve the workflow. For instance, several control plane technologies have been moved into the Routing Area (such as LISP), as that is where the expertise exists to properly review and manage the work. Reorganization within the areas is helping to adjust the workflow, as well.

Throwing more people at the problem. A common complaint among IETF participants is that the area director position, in particular, is essentially a full-time undertaking. This makes it very difficult to find people who are willing to take the position on, and companies willing to sponsor them. The Routing Area took on a third director this year to alleviate some of the workload.

Beyond this, the IETF is learning to spread work around more. Area Directorates have been taking a more definite form and adding people; the Routing Area Directorate, for instance, has been instrumental in reviewing a lot of documents, helping to improve the speed of processing what amounts to a flood of new work in the control plane. Working groups have been taking on secretaries to allow chairs to focus on managing the process rather than the documents.

Controlling scope creep with design teams. Design teams are being used to refocus areas of work, for example in HomeNet and the Interface to the Routing System (I2RS). These smaller design teams can focus on small problem, and come to a conclusion more quickly. While a design team might not find the final answer, they can collect a lot of information very quickly, and break a problem down to its more essential parts, allowing the entire working group to make a more informed and better decision about technical direction.

Pushing cross-functional work. The problem of having wide areas of work where no single person can know all the information needed to do effective design or make effective decisions is being attacked through cross -functional mailing lists and design teams (see above). These efforts are particularly bearing fruit in security and YANG.

Interim meetings. A number of working groups now have interim meetings to augment the face-to-face IETF meetings. This allows more people to present their ideas, and more live discussion time about specific ideas and drafts.

Drawing in a wider set of engineers. One of the efforts the Internet Society (ISOC) and the IETF have been working at is getting more operational folks to participate. It’s often hard to justify the expense in terms of time and money for an operator, but as the network world continues to blend open source and open standards more fully in the future, this case might be easier to make. The ability of the IETF to pull together users and developers is, perhaps, one of its greater strengths; it would be useful if that strength could be put to more common use.

These aren’t all the different efforts being undertaken, but they’re representative of the types of solutions being put in place to help make the IETF a faster monster, rather than a slower one. Of course, there are things the IETF could still do -- sunsetting protocols might be one, as bit rot can set in on older standards as much as it can on older open source projects. You still have the problem of what to do with users who are playing in that pond, but perhaps some mechanism can be put in place to resolve these problems that would apply to both worlds -- open source and open standards -- equally well.

But engineers should also realize that there is no such thing as a free lunch. Many of these solutions do have a set of tradeoffs.

The professionalization of standards

All this additional working time will, of course, not only lead to faster work, but also to more work. As the old saying goes, “if you really want to get something done, give it to the busiest person you know.” As the workload grows, the problem isn’t going to go away. Rather, the IETF is likely to become more fragmented, rather than less, and the time required to actually follow “the whole work,” is going to become either full time -- or impossible time -- as the workload grows.

Growth in scope and depth is a good thing, but it’s also a bad thing. Adding separate secretaries and shepherds and directorates spreads the load, but it also complicates the process, making it ever more difficult to understand and follow the progress of any particular draft or group of drafts.

The likely effect of these changes, as necessary as they are to handle the increasing speed at which the IETF is expected to work, is the increasing professionalization of the open standards process. Most of the various open standards groups -- the IETF included -- really began as more professional organizations than “community participation” efforts. They’ve often grown into more of a community effort; it may be difficult to hold on to those changes in the face of increasing time requirements, however.

Is there any way to counter this commercialization and continue the drive to make both open source and open standards true community efforts? Is it possible to blend the strengths of both movements into a solid, unified, whole that will serve the networking community well -- both users and producers? Is it possible to control the time commitment required to participate in open standards in a way that makes the “one step away” model work well, and serves the needs of the community at large, in order to control the rate of professionalization?

These are questions both the IETF and the open source community will face -- and need to find answers for -- in the future.

Alvaro Retana, Distinguished Engineer at Cisco, and IETF Routing Area Director Alia Atlas, Distinguished Engineer at Juniper, provided input to IETF Routing Area Director Russ White for this article.