Plenary Report

Note: This is not a complete report of the plenary sessions; rather, it is a summary of the highlights of the discussions. All IETF 68 presentations can be found on IETF’s website

At IETF 68, the operations and administrative plenary session consisted of two parts: The first consisted of the usual updates on administrative and operational IETF issues. The second was dedicated to the status of the routing and addressing problem (ROAP).

IETF 68 attendees heard from Morgan Sackett – a representative of VeriLAN, the company providing network as well as network operations centre (NOC) services for the meeting – who gave a brief presentation that described the general network layout. Attendees also heard from Jon Lindberg, vice president of Secretariat Services, who gave an elevator speech about NeuStar’s services. NeuStar Secretariat Services (NSS) organises the IETF meetings and is responsible for tools development and the overall IT infrastructure.

Brian Carpenter presented Jon with a plaque of contribution to NeuStar for hosting IETF 68, a gesture recently introduced at the meetings to recognise IETF meeting host organisations.

IETF Stats

Brian provided a summary report, including updates from the IETF Administrative Director (IAD), the Internet Assigned Numbers Authority (IANA), and the RFC Editor. The March 2007 meeting was attended by 1,200 people, which is roughly the same number of people who attended the meeting in Dallas one year ago. The number of countries increased, though, from 36 at the meeting in Dallas to 45 at the meeting in Prague. Participants from the United States are still in the majority but constituted only about a third of the participants compared with about half last time.

Since IETF 67, three new working groups (WGs) have been created, and six WGs have been closed. This leaves approximately 120 WGs currently active. See more statistics under Facts & Figures.

The RFC Editor published 95 RFCs since the last IETF meeting. Brian noted the improvements in the RFC editor queue and other improvements (see full report on the IAOC Web site) The new contract with the RFC Editor is imminent.

IANA processed 1,160 IETF related requests since the last meeting, 81 of which were requests for port number. This is worrisome because the number of ports is finite. Since the service-level agreement (SLA) was signed between IANA and IAOC and the IAB, IANA is now ramping up its implementation. The IANA staff has worked especially hard to improve tools and metrics.

The IAD reported that the total meeting income for IETF 67 in San Diego was $799,000. The total direct meeting expenses amounted to $438,000. This leaves a surplus of $361,000 that was contributed to the IETF Administrative Support Activity (IASA). It is important to note that over the year, the IASA needs to build up about 50% surplus on meetings toward secretariat activities. The numbers for 2007 are on track so far.

The status of the IAOC action points from the last meeting is as follows:

• The new RFC Editor contract is close to be finalised.
• An SLA has been signed with IANA.
• An RFI on secretariat services has been issued.
• RFC copyright transfers from ISOC to the IETF Trust have been completed.
• An agreement has been reached to attach open-source license to Secretariat tools; source files have been received.
• IETF is a registered trademark.
• Document retention policy has been defined and implemented.

News and Notes

Following Brian’s reports, Andrew Lange, chair of the Nominations Committee (NomCom), gave an update on the results of the NomCom. All voting members and liaison members worked hard and kept the best interests of the IETF as a whole as their guiding principle.

As the NomCom removed Russ Housley for consideration as Security Area director by appointing him to the IETF chair position, it noted a dearth of candidates for the Security AD position. This resulted in an additional call for nominations for the Security Area position. From this call a large number of candidates was generated, with eight of them willing to serve.

Andrew discussed a few key issues being faced by the NomCom. There has been a significant decline in the number of volunteers for the NomCom in recent years, and the NomCom chair expressed concerns about this. Another problem is what Andrew called the Strong Incumbent Syndrome, wherein strong, well-respected incumbents appear to dominate and few other people are stepping forward. Finally, there seems to be a growing tension between openness and confidentiality. Andrew suggested that an amendment be made to the NomCom guidelines laid out in RFC 3777, which would make the list of willing candidates – or even all nominated candidates – public.

Daniel Karrenberg, chair of the ISOC Board of Trustees, reiterated a comment Andrew made: “You get the governance you deserve.” He recognised all of the outgoing IAB and Internet Engineering Steering Group (IESG) members. All of them will receive in the mail a plaque of recognition.

Brian and Russ celebrated the passing of the dots, a tradition in which Brian hands over his IETF chair dot – which appears on his badge – to the new IETF chair, Russ Housley.

In his presentation as incoming chair, Russ said he is on a steep learning curve and that he welcomes any input on how to do a good job as IETF chair.

In closing, Russ said everyone has a slightly different view of the Internet. He welcomes suggestions on how to help figure out what his goals are and how to “achieve my goals in your part of the Internet.”

During the following IAOC open-mic session, Lucy Lynch, outgoing IAOC chair, recognised everyone who is leaving the IAOC and welcomed the new members. She further announced that Dave Crocker and Steve Crocker are the first two volunteers who signed their RFCs over to the IETF trust to ensure that the IETF continues to have as much scope as possible to extend and revise the protocols specified in the RFC series. Dave and Steve stepped up to the podium and each signed an open-ended license for the RFCs they authored. They encouraged others to do the same.

Daniel thanked the IAOC for an excellent and professional job over the past three years.

Leslie Daigle, former chair of the IAB and member of the IAOC, agreed and then reminded everyone that this conversation would have been inconceivable a few years ago. “Congratulations to us all!” she said.

Focus on ROAP

Part 2 of the plenary was dedicated entirely to the routing and addressing problem (ROAP), which was discussed during the last IETF plenary session and at many other meetings. This session was led by the Internet and Routing Area directors.

Brian Carpenter gave a presentation that illustrated where we are with this problem and what the IETF can and intends to do about it. To better understand the context for the recent activities, it is worth looking at the historical time line:

1962 Packet switching invented
1974 Internet concept invented
~1978 Internet Protocol designed
~1988 Border Gateway Protocol (BGP) designed
1992 Classless Inter-Domain Routing (CIDR) designed
1995 IPv6 designed

Attendees interact at IETF 68

Since 1995 there has been growing concern about such issues as scaling, transparency, multihoming, renumbering, provider independence, traffic engineering, and the impact IPv6 has on the Internet and the routing system. In 2006, the IAB held a workshop to discuss routing and addressing issues. See the full report.

An important architectural principle is that a network should be able to implement reasonable internetworking choices without unduly impacting other networks’ operations. The issue at hand on the architectural level is that today certain implementations need to be handled in ways that threaten that principle. This is the root cause of ISP problems and end-site dissatisfaction. The question is, What can be done to harmonise the network to that architectural principle? Brian mentions the “tragedy of the commons from provider-independent address usage” as an illustration of that problem.

There are a number of technical goals, both on the end-user level and on the ISP level. On one hand, end users want to connect to multiple ISPs while maintaining support for current traffic engineering capabilities. They also want to change ISPs without major switching costs. ISPs, on the other hand, want to keep the BGP table size and dynamics within their routers’ operational capabilities. ISPs also want the ability to match traffic engineering flows with their business needs. An overall technical goal is to support end-to-end session transparency.

Another issue is scaling: Today, 200.000 Internet BGP routes and several times more customers and virtual private network (VPN) routes are common. A goal for 2050 could be to connect 10 billion end nodes with 10 million multihomed customers. Can we get there at a reasonable cost for vendors, Internet service providers, and end users? And what should the five-year goal be?

A number of sessions at various recent meetings – such as at the regional operators meetings, the DARPA R&A workshop, NSF/OECD workshop, and the TERENA workshop – were held to raise awareness of the problem. Within the IETF community, activities are being organised to address the issue, including a Routing and Addressing Directorate, which was formed recently. In addition, the Routing research group has been rechartered (see more details later in this article), and the Routing and Addressing mailing list [email protected] has become quite active. During IETF 68, a number of meetings were organised to address the issue not only during the plenary session but also during the open Internet and the open Routing Area meetings.

With BGP4 in use with little change since 1994, there is growing concern about the growth of the BGP routing table. This is related primarily to the size and update rate as well as to the impact that multihoming has on the routing table. The problem exists in both IPv4 and IPv6. Attendees at the IAB workshop in October 2006 looked at hardware trends that raise economic and engineering concerns about the size of the Forwarding Information Base (FIB).

Another issue raised was a problem with transparency. Since 1981, the upper layers of the network stack have assumed that a thing that looks like an address is an address. For instance, application programmers often assume that an IP address is a valid end-system identifier that can also be passed on to third parties. Consequently, problems arise when addresses are viewed merely as locators. NAT, STUN and other applications attempt to deal with this problem in their own ways, which lead to newer problems. The historical reliance on address transparency creates specific difficulties for multihoming and traffic engineering. There are a few areas for which solutions can be developed:

• Router and microelectronics designers can work on engineering to help solve the RIB/FIB scaling problem.
• BGP adjustments and better operational practices could help improve the update dynamics.
• Traffic engineering, multihoming, end-to-end transparency, and mobility would benefit from architectural changes. Identifier/locator split and/or multilevel locators form a hopeful approach.

All of those developments are orthogonal to both IPv6 deployment and application-level namespace issues.

What can the IETF do? It can provide a forum for open problem analysis and development of solutions by vendors, operators, and users working in concert. And the Internet Research Task Force (IRTF) can help with research. In the short term, routing-table growth is only an engineering issue. While routing dynamics need to be better understood, this is likely also an engineering issue and can possibly be addressed by stronger pushback in the ISP community as well as through implementation and protocol improvements. Thus, there is reason to believe that we do not have a short-term technology problem, even though it will continue to be hard work and will have an impact on business decisions. However, architectural problems remain. The IETF can help with short-term protocol work, such as better tuning BGP to meet today’s challenges. The IETF can also help by looking into architectural changes, such as the identifier/locator split and multilevel locators.

As an overall plan, it has been suggested that the IETF work on all of the above levels (short-term incremental improvements as well as architectural changes) and continue the dialogue with the operators community.

The introductory presentation by Brian Carpenter was followed by a lively and animated discussion. Some people felt this problem is still not taken seriously enough and encouraged “the IETF to be bolder in tackling this problem,” as Ted Hardie put it.

Many people suggested that the problem be addressed on multiple levels. There are a number of things that can be done today to work on BGP dynamics, such as operational practices and certain routing policies or tweaks in implementations and protocols. And there are more-fundamental architectural changes – such as splitting the locator from the identifier – that won’t come without costs. The trade-offs are not yet well understood. But “it is good to know that there are engineering solutions to keep the Internet running in the meantime while we start working on some fundamental changes,” said Ross Callon, one of the Routing Area directors.

Dave Ward, the other Routing AD recognised Dave Meyer, who has been working over the past few years to bring this problem to light. Dave Meyer thanked the IETF for the applause but pointed out that we’ve already known about this development for 15 years and cannot wait another 15 years. He emphasised that this is not a discussion about incremental improvement to BGP , which needs to be done anyway. “This is a controversial topic, and it will be hard to get IETF consensus,” said Dave. “Do we have any way forward in our process to deal with this?”

Other people agreed, expressing concern that it is not clear what the right processes are to make architectural changes to the Internet. The general consensus was that this issue is too important to leave to the IESG or to the IAB; it should be worked on by the entire community. One participant mentioned that almost any architectural change will have costs, but this one might have significant impacts on security. Security implications need to be looked at early on in the process.

Summary of Progress Made

Much has been done in the past six months with regard to ROAP – a clear sign that the IETF now takes this problem seriously. Daniel Karrenberg suggested that in the discussion, the IETF should also look back and learn from past experiences. “There was a panic about routing-table growth that gave us CIDR,” he said during the plenary. “We needed a quick fix, and we did a quick fix. There was a panic about IP address space running out that gave us IPv6. And some of the ‘features’ IPv6 brings us is because we rushed it.”

However, it will take several years to develop, implement, and deploy any new architecture, and no one solution or tool will solve all problems; it might be necessary to apply different sets of tools in order to solve different parts of the problem. Some have expressed concern that the IETF may have already constricted itself to a small problem space: routing (and small incremental changes) and addressing (big fundamental changes). In general, however, there is agreement that for short-term solutions, the focus should be on routing and that for the longer-term solutions, a lot more will be involved. Collaboration between all IETF areas will be necessary.

Additional concern about operators and users not being able to pay for continuing updates of hardware led to a discussion about the implication of architectural changes on business decisions, with an emphasis on the need for new architecture to take existing business models into account. “We have to make sure we deal with the architecture in some way that does not lead into high costs and short lifetime of equipment,” said R�diger Volk. On the other hand, it might be unrealistic to assume that one can make fundamental changes and keep all the existing business models.

“The Internet got started by breaking the then existing business models completely,” said Bob Hinden. “It could be that this will also happen today. We should not be constrained by the way people do business today.”

The IETF 68 Technical Plenary, held on the following evening, began with an update by Internet Research Task Force chair Aaron Falk on the activities of the IRTF.

Aaron’s presentation was followed by Aiko Pras of the University of Twente, The Netherlands, who serves as chair of the Networking Management research group (nmrg). Aiko reported on a workshop held in October 2006 in Utrecht, which brought together researchers, operators, vendors, and technology developers to identify future directions of network and service-management research. The workshop was jointly organised by the IRTF nmrg and the European Network of Excellence for the Management of Internet Technologies and Complex Services (EMANIC). The work is expected to result in recommendations for research directions that are worth exploring over the next five years. The work is not intended to define the management standards that are needed now.

A number of challenges in this area were identified at the workshop:

1. Management models: The Manager-Agent approach (client-server) and hierarchical management (DisMan, TMN) are well understood. What is not yet understood are issues such as fully distributed management (P2P, ad-hoc) and self-technologies (auto-configuration, stability of control loops).
2. Distributed monitoring: A track number or quality of VoIP calls as well as a way to find the best proxies and peers (P2P) are needed. The goal is to develop a lightweight, distributed monitoring layer that offers aggregates of local information to applications.
3. Data analysis and visualisation: It is possible to create topology maps for small networks and statistic time series plots. There are difficulties with the creation of maps for large, multi-layer networks, the visualisation of anomalies and real-time, interactive visualisation techniques.
4. Economic aspects of network management: Most researchers tend to focus on technical solutions. There is limited research into the operational costs of such technologies. Network Management is risk management.
5. Uncertainty and probabilistic approaches: Many researchers focus on deterministic approaches and yet scalability problems might need more probabilistic approaches. How does one decide between probabilistic and deterministic approaches?
6. Ontologies: The data modelling is believed to be understood. There is still more research needed in areas such as how ontologies can be effectively used to automate the implementation of management interfaces as well as how ontologies can help check or enforce policies and behaviour.
7. Behaviour of managed systems: Management models usually represent a state (MIBs, CIM). More research is needed to model and manage behaviour, such as normal versus abnormal behaviour, detection of resource failure, and the design of self-stabilising systems. As a follow-up to the nmrg workshop, an Internet-Draft will be written describing outcomes and an overview article will be submitted to the IEEE ComMag.

Internationalisation in an IETF Context

One of the more complex and challenging issues facing the IETF – and the Internet more generally – today served as the basis for discussion during the remainder of the technical plenary session: Internationalisation of the Internet in the context of the IETF. “There is an entire set of human Internet users who cannot use the Internet the way we do,” said Ted Hardie of the IETF’s interest in the issue. “We would like to change that.” As part of the technical plenary, a small team of experts – Leslie Daigle, Patrik Fältström, Ted Hardie, John Klensin, Xiaodong Lee, and Pete Resnick – presented slides, explained the issues, and answered questions.

Tackling internationalisation is an ambitious undertaking – one that at times can be complicated by questions that are more philosophical or linguistic than they are technical. After all, it would be unrealistic to expect the IETF to attempt to develop a standard for helping one group understand the language of another if they don’t speak that language. Still, there is a lot that the IETF can do to improve international accessibility. As John has often said, “The IDN issues are tractable as long as we keep a clear focus on what problems we are trying to solve and what areas of the general topic actually need solving and can be solved.”

In a high-level introduction to the topic, Leslie shed light on the core set of issues associated with internationalisation and protocol design and offered a broader perspective on RFC 4690, Review and Recommendations for Internationalised Domain Names (IDN). She challenged a widely held assumption within the IETF that the topic does not concern those who are not involved in the applications area when, in fact, the technical issues associated with IDN touch many areas. She said that while there is no clear problem statement, there are, in fact, a variety of problems that promise to become bigger problems over time. “This portion of the technical plenary is meant as a heads-up on what may be coming into the IETF as new work,” she said.

The problems and concerns associated with IDN underscore the difficulties with which language is translated into code. In an attempt to put internationalisation into context for the IETF, Ted showed a clip from the movie Charade, in which Audrey Hepburn and Cary Grant are asked to transfer an orange from under their chin to another person without using their hands. The clip demonstrates with humour how communication often relies on the ability to understand one or more languages as well as body language, context, and tone. In terms of IDN, the question is much larger and more complex than how characters are coded. The question is, How do we create character sequences and applications that depend on language use and context for accuracy and usability? As Ted pointed out to the audience, the clip’s protocol description was in at least four different languages, but only two were close to complete. To know that, though, one would have to recognise and understand all of them. And, in the end, you can’t internationalise a chin or an orange.

As Ted said, there are specific instances when context is essential. Those include protocol descriptions, protocol elements, and human elements, the last of which is the most important and perhaps the most difficult. As spelled out in his slides, things that we may assume are protocol elements can sometimes be human elements and vice versa. That means that in some contexts, internationalisation is completely inappropriate; in others, it’s necessary to understand how much context is available in order to do proper design. As the movie clip demonstrates, rapid language switching requires context switching. If you can’t identify the context (or the language), you’re going to have a problem.

If the Internet is to be truly global, it must be relevant on a local level. For many, that means a Domain Name System that is functional regardless of language and useful regardless of context. In RFC 4690, it is stated that “While IDNs have been advocated as the solutions to a wide range of problems. . . . They are no more and no less than DNS names, reflecting the same requirements for use, stability, and accuracy as traditional ‘hostnames’ but using a much larger collection of permitted characters. In particular, while IDNs represent a step toward an Internet that is equally accessible from all languages and scripts, they, at best, address only a small part of that very broad objective. There has been controversy – since IDNs were first suggested – over how important they will actually turn out to be; that controversy will probably continue. Accessibility from all languages is an important objective; hence it is important that our standards and definitions for IDNs be smoothly adaptable to additional scripts as they get added to the Unicode character set.”

In his presentation, John provided an overview of current IDN work within the IETF and emphasised the importance of advancing work on IDNA (Internationalising Domain Names in Applications). He said changes may need to be made in IDNAbis (the term for the successor to RFC3490 and related specifications), such as further clarification of terminology and separation of the user interface and language issues from the protocol, since the DNS deals only with strings of characters without any language identification or a requirement to conform to the syntax of any specific language. That would mean that in IDNAbis, character-to-character mappings become the responsibility of the user interface and not the protocol. “Most reasonable user interfaces won’t need to be changed,” he said. “The protocol should be able to work with different versions of Unicode and, hence, would not be restricted to specific Unicode versions.” Some have suggested that more characters be added for functionality and that a larger number of characters be allowed to appear in registered strings. John expressed the hope that IDNAbis would allow for better treatment of bidirectional languages, such as Arabic languages that read from right to left. He also expressed confidence that the new work would lead to a protocol that would be easier to understand and explain.

The discussion that followed offered several examples of how confusion over internationalisation is evident even within the IETF. In one case, a participant asked a question in connection with the concept of Internationalised Resource Identifiers (IRI)s. Observing that the deployment community is not clear about whether it’s possible to use non-ASCII characters in IRIs being passed in protocols, the participant asked if all the right things were done with regard to terminology. “You’ve just fallen into the same trap as the last questioner, which is, you used the word characters,” said Pete. “IRIs are the things on the side of the bus with the funny characters. What goes in protocols are URIs [Uniform Resource Identifiers]. Generally speaking, those have octets in them; actually, they have 7bit filled octets in them. Well, sometimes they’re filled, and sometimes they’re not.”

“Maybe you now understand why we had headaches for the past three years,” said Patrik.

Unicode, as John pointed out, is concerned only with standardised code points; in other words, it does not specify how to draw characters or how to address fonts or context. For example, the criteria given in the Unicode Standard for assignment of code points excludes the assignment of codes to font variations on the same character. However, for the base Latin alphabetic characters, additional code points are assigned for mathematical uses; in other words, code points are assigned to characters that visually and within a specific mathematical context are the same as their base counterparts – except for such attributes as bold and italic, which meet any reasonable definition of font variations. As John said, one cannot distinguish those characters from others except that they are defined in the Unicode description as mathematical. “Given the context that Unicode essentially expects, these are not the base characters and a font difference at all, but mathematical symbols,” he said. “That’s a problem, because in our environment it causes complications.” For ordinary IETF text string purposes, one must either map these mathematical characters into the base ones or forbid them entirely. Either choice comes with problems, but in terms of IDNAbis, we concluded that it is better to forbid them in the protocol, leaving mappings, if any, to the user interfaces. John said in a separate discussion that there are other Unicode assignment rules that are not completely orthogonal to each other and that there are issues of some type with almost every script and language. “Difficulties arise when there is inconsistency in the application of the Unicode Consortium’s own rules,” he said.

According to Harald Alvestrand, the IETF cannot claim expertise in character set coding and should not attempt to do so; that, he said, is the responsibility of the Unicode Consortium, even if its work doesn’t give us a complete solution to internationalisation issues.

Patrik responded that there is no need for the IETF to hold off on working on the IDN and IDNA issues it is prepared to address or on internationalisation issues more generally. He believes there is a clear boundary between the Unicode Consortium and the IETF. “What we are doing is, relying on the data the Unicode Consortium is providing,” he said. “We are referencing their expertise for the classification of each of the Unicode characters.”

The conversation shifted to the potential for fragmentation of the Internet with IDN, particularly if different scripts are allowed. One participant raised the question of whether the worldwide operation of the Internet could be disrupted if e-mails are written in a script the recipient does not understand. In terms of content of messages, this situation has existed for more than a decade and has caused no more, and no fewer, problems than incompatibilities among languages traditionally do. The risks obviously increase if one is presented with domain names, IRIs, or e-mail addresses that one can’t understand or, worse, that one’s terminal device cannot render. Obviously, nothing the IETF can do about internationalisation will solve the problems of people communicating with each other by using languages that neither party speaks. However, the bigger and more relevant issue is the considerable number of people in the world who still cannot communicate on the Internet, even with other people who share their language and writing system. By adding more functionality that would facilitate the use of other languages, many more people would be able to benefit from the Internet. “We are actually worried about that problem, and what we’re attempting to do in the internationalised e-mail address working group is to come up with a form of e-mail address that, if it gets to you and you’re not in on the game of fancy e-mail addresses with all sorts of interesting characters in them, you’ll at least be able to reply and get back to me,” said Pete.

Even so, other concerns persist, including the risk that different applications might deal with internationalisation in ways that will, once again, cause incompatibility and create problems for the users. “While those types of problems might exist today,” said Andrew Sullivan from the floor, “the scope of confusion will be significantly higher if people start trying to communicate across language and script borders.”

Another concern is the possibility that if the new IDNAbis becomes standard, names registered under the old IDNA may no longer be valid. “This might indeed happen,” said Patrik. “However, most of the names that will become invalid are corner cases, and only people who are interested in phishing use them.”

John agreed, adding that the vast number of labels that will not be valid in the new system were not valid under the old system – a system that included guidelines from the Internet Engineering Steering Group (IESG) and the Internet Corporation for Assigned Names and Numbers (ICANN) – either. “The old system was just more permissive,” he said. “The new system will standardise more and allow for fewer borderline cases.”

In reality, most of the issues are related to localisation and not internationalisation or multilingualism. “The purpose of our work is to include the people who cannot participate in the Internet today because we are failing to make it possible for them to localise properly,” said Ted.

IAB News and Notes

Following the long and lively discussion on internationalisation, Leslie gave an update on recent IAB developments. A number of documents have been published or are in the publication queue, including reports on the IAB workshops on unwanted traffic and routing and addressing. There is also a document on the process for publication of IAB RFCs being published (draft-iab-publication-00.txt).

The IAB has appointed Bob Hinden to the IETF Administrative Oversight Committee (IAOC) and has renewed Aaron Falk’s chairmanship of the IRTF. Aaron has been appointed to serve as chair for another two years.

At the conclusion of the technical plenary, Leslie handed the IAB chairmanship over to Olaf Kolkman, who thanked Leslie for her outstanding work and presented her with a gift. The session ended with a long round of applause and standing ovations for Leslie from the plenary attendees.

NomCom Results

Incoming IESG Members