Tag: IETF

A New Role For Eliot

As many of you know I have a long history within the Internet Engineering Task Force (IETF), having been involved since 1989.  The IETF is responsible for many of the underlying protocols that computers use to talk with one another for purposes such as Email and the Web.  I have served as the chair of two working groups, a research group, and have written numerous drafts and requests for comments.

As of late I have been involved with the International Telecommunications Union (ITU).   The ITU is a U.N. organization whose origins date back to at least 1869, long prior to forming of the U.N. The ITU has developed numerous data communication standards, including X.509, which is what web encryption uses, as well as many of the codecs that are used on the network to transmit voice and video.

Last May I was able to join the United States delegation to the World Telecommunications Development Conference (WTDC) in Hyderabad India.  Now I have been asked to serve as the Internet Architecture Board liaison to the ITU-T.  My role will be first and foremost to see that liaisons (messages between the organizations) are properly handled by the IAB and IETF.  I will advise the IAB and IETF on how the ITU-T functions, and the context around particular liaison statements.  Occasionally I will assist in drafting liaison statements.

These organizations operate quite differently.  The IETF is driven by individual participation, where people needn’t even attend meetings to participate in decisions.  The ITU-T is an intergovernmental organization in which only governments may make decisions, although others may advise.

This is an important role at an important time, because when these two organizations do not cooperate at some level, they end up duplicating and competing with each other’s work.  That can lead to more expensive products or products that do not work well together.

Off to Dublin (well sort of)!

Today, the Internet Engineering Task Force begins its 72nd in person meeting.  The IETF as it is known is a standards organization that primarily focuses on, well, the Internet.  The work done in this body has included Multimedia Internet Mail Extensions, Internet Calendaring, Voice over IP, and many others.  Not all work done by the IETF has worked out.  An effort I worked on some time ago weeded out the stuff that either was never used or is no longer used.  One of the key areas that any standards organization struggles with is how much potentially useful stuff to let through versus sure bets.  Sure bets are those things where a necessary improvement or change is obvious to a casual observer.  The people who make those changes are not the ones with imagination.

It’s the people who use their imaginations who make the bucks.  Always has been.  The problem is that there are a lot of people who may have good imaginations, but are unable to convert a good idea into something that can be broadly adopted.  This is a problem for a standards organization because each standard takes time and effort to develop, and each failed standard diminishes confidence in the organization’s overall ability to produce good stuff.

On the whole the IETF has done demonstrably well, as demonstrated by the vast amount of money organizations have poured into personal attendance at the in person conferences, even though no attendance is required to participate.

This summer’s conference is being held in Dublin City West at a golf resort, a bit away from the major attractions.  There are two benefit of this: first the cost isn’t absolutely outrageous.  Second, if people know they the attractions are a bit far off, then fewer tourists will come.  I actually don’t mind the idea of an IETF in Buffalo in the winter, but I may be taking things a bit too far.

Among the many discussions that will take place at this conference include one about what to do about email whose domain cannot be ascertained to have authorized its release.  The standard in question that identifies email is called Domain Keys Identified Mail (DKIM), and is relatively new.  What to do, however, when DKIM is not employed or if the signature sent is broken in some way?  This is the province of a work called Author Domain Sender Policies (ADSP).  The specification provides a means for sending domains to communicate their intentions.  After a year of arguments we hope to have a standard.  Whether it proves useful or not will only be shown by the test of time.