IETF News

IETF 76 Plenary Report

By: Carolyn Duffy Marsan

Date: January 1, 2010

line break image
Jun Murai
Social event in Hiroshima
IETF 76 participants mingle at reception

By Carolyn Marsan

The IETF 76 Administrative Plenary kicked off with a brief address by IETF chair Russ Housley, who introduced the meeting’s host, Jun Murai, of the Widely Integrated Distributed Environment (WIDE) project. Jun thanked attendees for traveling to Hiroshima, a city that he admitted was far away for many participants. Jun pointed out that Hiroshima was an appropriate location for an IETF meeting because it was one of the first cities in Japan to engage in computer networking research. He thanked the city of Hiroshima for giving an Olympic-class welcome to the IETF community.

Jun also thanked meeting attendees for participating in ongoing WIDE-funded research regarding RFID deployment and standards. IETF 76 attendees and speakers were given badges with embedded RFID cards, which were used throughout the meeting for the social check-in, blue sheets sign-up, and open-mic sessions when activated. Jun thanked many of the attendees for their “patience, cooperation, and braveness” in moving past their privacy concerns and participating in WIDE’s RFID testing.

IETF Chair Report

Russ said IETF 76 attracted 1,106 attendees from 44 countries, compared with 937 attendees from 52 countries at the November 2008 meeting in Minneapolis. The largest number of attendees at IETF 76 came from Japan and the United States.

Russ chided attendees for being “procrastinators,” pointing out that 70 percent of the new and updated Internet-Drafts published since the group’s summer meeting had been posted in the four weeks prior to the Hiroshima meeting.

In terms of upcoming meetings, Russ pointed out that the March 2010 meeting in Anaheim, California, is without a host. But he said the summer meeting, to be held in Maastricht, Netherlands, will be hosted by SIDN, while the fall 2010 meeting will be held in Beijing, with Tsinghua University serving as host. He reminded attendees that all of the 2010 meetings would feature Friday afternoon sessions.

Itojun Service Award Presented

 

Jun Murai of WIDE, host of IETF 76
Next, Jun presented Google engineers Lorenzo Colitti and Erik Kline as the first annual recipients of the Itojun Service Award, which recognizes extraordinary dedication toward the development and deployment of IPv6.

The Itojun Service Award honours the memory of Dr. JunIchiro “itojun” Hagino, who passed away in 2007, at age 37. The award, established by friends of itojun and administered by the Internet Society (ISOC), recognizes and commemorates the extraordinary dedication exercised by itojun over the course of IPv6 development. The award includes a presentation crystal, a USD 3,000 honorarium and a travel grant.

Itojun’s mother gave a moving tribute, thanking the members of the IETF community who helped establish an award in her son’s memory. She said she hoped her son’s “passion for IPv6 and his friendships continue forever.”

Erik and Lorenzo were honoured for evangelizing IPv6 across Google, for helping develop IPv6-enabled Google services, and for coordinating Google’s IPv6 conferences.

“I went to my first IETF meeting with the express purpose of meeting itojun. That was in December 2007, and I was only able to go to the memorial there,” Erik said as he accepted the award. “I didn’t meet itojun, but I met many others who helped us do our work and change our culture internally.”

IAOC Report

Bob Hinden, chair of the IETF Administrative Oversight Committee (IAOC), began his report by stating that all of the outstanding issues with the host and the hotel for IETF 79 in Beijing have been resolved. “We’re very confident we can have a normal IETF meeting just like we do everywhere else,” Bob said.

He added that the IETF is close to meeting its 2009 budget despite the economic downturn. The IETF is forecasting revenues of USD 3.2 million, expenses of USD 4.7 million, and a total ISOC contribution of USD 1.5 million.

 

A performance at the IETF 76 social event in Hiroshima
The IETF took advantage of ISOC stimulus funding so that it could lower registration fees for its meetings and maintain attendance levels. However, the IETF has not tapped into contingency funds that ISOC made available earlier in 2009.

The IETF experimented with one-day passes at the Hiroshima meeting, but it has not decided whether it will continue with that effort at future meetings.

For 2010, IAOC plans to keep registration fees the same, at USD 635 per meeting. The group is projecting USD 3.1 million in revenues, USD 5.2 million in expenses, and an ISOC contribution of USD 2.1 million. The 2010 budget includes investments in new automated tools, including Data Tracker extensions, Secretariat tools, RFC services, and programme management capabilities.

“A lot of our important tools have been developed by volunteers. This has been wonderful, but we’re starting an effort to make these tools more supportable over the long term,” Bob said.

Also in 2010, the IETF plans to begin migrating its RFC Production Centre and RFC Publisher from the University of California’s Information Sciences Institute (ISI) to a new contractor, AMS. The IAOC is still involved in awarding contracts for the RFC Series Editor and Independent Submissions Editor (see the article on page 14 in this issue for more detail and discussion of these developments).

In other IAOC news, Hinden said that the committee was making progress at publishing the minutes from its meetings. All 2008 minutes along with the minutes of 13 out of 19 meetings held in 2009 were published online.

Trust Chair Report

NomCom
As of IETF 76, the NomCom was still working on IAB, IAOC, and Internet Engineering Steering Group (IESG) positions opening in March 2010.
Chair: Mary Barnes

Voting Members

Scott Brim
David Crocker
Roque Gagliano
Randall Gellens
Dorothy Gellert
Wassim Haddad
Stephen Kent
Dimitri Papadimitriou
Simo Veikkolainen
Lucy Yong
Nonvoting members

Joel Halpern (Past-year Chair)
Henrik Levkowetz (Tools Advisor)
Jon Peterson (IAB Liaison)
Tim Polk (IESG Liaison)
Henk Uijterwaal (IAOC Liaison)
Bert Wijnen (ISOC Liaison)
IETF Trust chair Marshall Eubanks explained why modifications to the Trust Legal Provisions (TLP) are still in flux.

In October 2009, the trust chair proposed TLP 4.0, which would cover production of IETF, Internet Architecture Board (IAB), Internet Research Task Force (IRTF), and Independent Stream documents. However, the RFC Editor Board has some disagreements with this document. So Marshall said it will be revised again and sent back to the IETF community for comment in January.

Marshall said the IETF community levied a fair amount of criticism on the trust for the trust’s lack of transparency in its process of modifying the TLP. In response, Marshall said the trust has “tried very hard to improve our communications with the community,” and he pointed out that the group’s meeting minutes are now available online.

Recognition

Russ and IAB chair Olaf Kolkman recognized and thanked ISI for being the RFC Editor for nearly 30 years. Plaques were presented to ISI employees Bob Braden, Sandy Ginoza, and Alice Hagens. See the article on page 14 in this issue for more detail and discussion of these developments.

Open Mic Comments

During the open-mic session, several questions were raised about whether IETF participants would have open, unfettered Internet access while meeting in Beijing in 2010. The IETF leadership said it has been assured by the local host and hotels that there will be no content filtering or blocking of the group’s Internet access.

Additionally, several participants said they would like to see the IETF expand its use of Web conferencing to support remote participation in its meetings, while others complained that Web conferencing is a distraction and reduces the meeting attendees’ productivity.

A discussion took place about how best to attract attendees to Friday sessions, with proposals to move the technical plenary or the social to Friday evening.

Finally, IETF participants and leaders debated the purpose of the group’s three-step standards process and whether it makes sense for documents to become full standards or to remain as draft standards or proposed standards.

IETF 76 Technical Plenary

IETF 76 participants mingle at reception
Olaf opened the technical plenary with a welcome to attendees, particularly those following the event remotely through Web conferencing or Jabber.

IRTF Report

Next on the agenda was IRTF chair Aaron Falk, who said four research groups met in Hiroshima: Host Identity Protocol (hip), Scalable Adaptive Multicast (sam), Delay Tolerant Networking (dtn), and Routing Research Group (rrg). Aaron said the IRTF has six RFCs waiting to be published that have been held up because of trust issues discussed at the administrative plenary. Aaron highlighted the ongoing work of two research groups-Anti-Spam and Scalable Adaptive Multicast-in the hopes of generating more interest and activity from IETF participants. For more information, see the IRTF Update on page 22.

IAB Report

Olaf outlined several IAB documents in his talk. One that is about to be published is the Peer-to-Peer Architecture; another that is under development covers IPv6 Network Address Translators (NATs). The IAB is also working on documents that describe the Internet Assigned Numbers Authority (IANA) function and an update on the IP model.

One piece of news that Olaf shared with attendees: IANA will be signing the .arpa zone using the same mechanism for Domain Name System (DNS) Security Extensions that will be used to sign the DNS root zone.

Olaf said the IAB has created an advisory group that will select candidates to serve as the RFC Series Editor (RSE) and Independent Submissions Editor (ISE) under the IETF’s new RFC Editor model. After some delay, the IAB is interviewing candidates for the ISE job and expects to be interviewing candidates for the transitional RSE position.

Internationalization in Names and Other Identifiers

ComicThe IAB is working on a document about internationalization-draft-iab-idn-encoding-that inspired the discussion led by John Klensin, Stuart Cheshire, and Dave Thaler.

Internationalization “is understood moderately well by a fairly small number of experts, most of whom end up realizing how little we actually understand,” John said at the beginning of the talk. “But it affects a large number of protocols, a large number of people, and it should affect virtually everything we’re doing in the IETF.”

John said internationalization is increasingly common in domain names, e-mail addresses, and URLs because users want to use the Internet in their own languages. Among those pushing for internationalization are users from Arabic-speaking nations, China, South Korea, and Taiwan.

Stuart explained the rationale behind the IETF policy regarding internationalization. The IETF requires that all protocols created after January 1998 should be able to use UTF-8, which is an ASCII-compatible method of encoding Unicode characters as integers. This policy is explained in RFC 2277: IETF Policy on Character Sets and Languages.

Stuart also explained Punycode, which is a method of encoding Unicode characters for use in internationalized domain names. He demonstrated some of the shortfalls of Punycode, particularly that it creates a sequence of bytes that applications can interpret in more than one way.

Because Internet protocols do not handle international text natively, the number of ways of encoding international text into printable ASCII characters has proliferated, Stuart said, which is creating chaos.

“This can get really crazy,” he said. “Suppose you have a domain name that is part of an e-mail address, which you put in a mailto: URL, which is then appearing on a Web page in HTML text. Is the domain name supposed to be actual rich text as seen to the user? Or is it supposed to be Punycode?”

Next, Dave discussed the difficulties involved with doing matching for internationalized domain names, pointing out how easy it is for users to be confused by what they read on the screen.

“If you have a sufficiently creative use of fonts and you have style sheets from a strange environment, almost anything can look like almost anything else,” John said, pointing out that people tend to see what they expect to see.

He added that the confusion over internationalized domain names could lead to security risks, such as phishing attacks.

“If I can make a string in one script-or partially in one script-look like a string in some other script, I suddenly have an opportunity, especially if I’m what the security people call a bad guy,” John added, pointing out that such attacks can be deliberate or accidental.

John then talked about some of the difficulties of mapping, including that mapping leads to lost information and differs by language. That’s why the IAB doesn’t recommend developers make up their own mapping systems.

Dave said the situation today is that we have multiple encodings of the same Unicode characters and different encodings, even within DNS. “Because you have all the differences across the protocols, networks, and so on, you can imagine the confusion that results,” he said.

In conclusion, Stuart said the IETF may need to go beyond its current recommendation of supporting UTF8 as one encoding mechanism to requiring it as the only encoding mechanism for the text that end users see.

Questions from the audience focused on the security problems related to internationalization, such as spoofing one character with another and changing fonts.

John said the Internet engineering community has known for nearly 20 years about the confusion that would be caused in moving from the limited ASCII character set to an environment with tens of thousands of characters.

“I don’t think there are any easy answers,” he said. “But the alternative to this situation is that nobody gets to use their own script, and that answer is completely unacceptable.”

Other questions from the audience revolved around the IAB’s document regarding NATs for IPv6.

This article was posted on 24 January 2010 .

No Comments to Show

Leave a Reply

Your email address will not be published. Required fields are marked *