By: Mirjam Kühne
More than 1200 participants from 44 countries convened in Montreal in July for IETF 66. Hosted by Ericsson and held at the Palais des congrÃ¨s in MontrÃ©al, the meeting featured a robust network provided by RISQ and CANARIE.
In his welcoming remarks in the first plenary session, IETF Chair Brian Carpenter described the progress made in the past four months since IETF 65.
Since then, four new working groups (WGs) were formalised, 13 closed, and approximately 120 are now chartered. A total of 463 new Internet-Drafts were submitted, 56 percent of them submitted in the four weeks prior to the meeting. Internet-Drafts updated since Dallas total 852, with 67 percent of those being updated in the four weeks prior to the meeting. In addition, there have been 80 IETF Last Calls, 96 approvals, and roughly 138 RFCs published.
dmsp – Distributed Multimodel Synchronizastion Protocol
wae – Web Authentication Enhancement
rtpsec – Securing the Real-Time Transport Protocol
hoakey – Handover and Application Keying and Pre-Authentication
nea – Network Endpoint Assessment
offpath – Path-decoupled Signalling for Data
Brian described a number of enhancements being made to the IETF meeting process, including a new scheduling procedure for WG and BoF sessions. The IESG is proposing to commence scheduling for working group meetings two weeks earlier than usual so as to allow more time for adjustments to the agenda and to minimise the possibility of clashes. Looking ahead to IETF 67, planned for November 5-10 in San Diego, the change means WG scheduling will open on August 7, with a cut-off date of September 18 for both WG scheduling and BoF proposals. A preliminary agenda will be announced on September 29 and the final agenda will made available on October 16.
A significant portion of the plenary discussion was dedicated to the future of standards-track reform. The current three-stage standards process, as described by Scott Bradner in RFC 2026, was intended “to provide a fair, open, and objective basis for developing, evaluating, and adopting Internet Standards.” As such, a specification undergoes first a period of development and review by the Internet community, and then revisions based on preliminary implementation. It is then adopted as a Proposed, Draft or Full Standard by the IESG and then published as an RFC.
As mentioned in the previous issue of the IETF Journal, in reality, protocol specifications are often adopted and implemented before they are approved as full standards. RFC 3774, published in May 2004, addressed the erosion of the three-stage process, stating that “in practice, the IETF currently has a one-step standards process that subverts the IETF’s preference for demonstrating effectiveness through running code in multiple interoperable implementations. This compresses the process that previously allowed specifications to mature as experience was gained with actual implementations.” This problem has further been identified and described in the newtrk WG, chartered in 2004, but no clear community consensus has emerged as a solution to the problem.
Opening the plenary discussion, Brian offered three possible directions. In option 1, RFC 2026 would be clarified, not just to “reflect the reality” that few standards go through the process as laid out in RFC 2026 but also to acknowledge that “the problems with the existing standards track are not serious enough to justify the effort needed to make substantial changes.” Option 2 focuses on document relationships, or, as the newtrk charter now says, “[creating] a new series of shorter IESG-approved IETF documents to describe and define IETF technology standards.” Option 3 would focus attention on the “maturity” levels of proposed standards, which would mean revising the three-stage IETF standards track described in RFC 2026.
A spirited debate ensued, with a number of participants admitting that large segments of the industry start accepting standards as soon as they have an RFC number, preferring not to wait for specifications to go through the entire three-stage process. However, a critical step in the standards track is one in which interoperability is demonstrated through a number of independent implementations, a part of the process that, if neglected, could lead to problems down the road. Other participants preferred to look at ways to get the “running code” piece back into the IETF, maybe as part of the WG specification writing process and not as part of the standards track.
“Sometimes we spend too much time on process and yet it seems like the problems are not big enough,” said Sam Hartman, who added that “while it would be nice to fix RFC 2026,”it doesn’t seem to be a high-enough priority for the community. “If we turn to it,” he said, “we need to get it right; it would be easy to get this one wrong and that would be very bad.” Bradner agreed, pointing out that “the Internet hasn’t stopped because we are not following RFC 2026.” However, Bradner also said he believes that a good description of the standards process would be useful. “The three-stage process shows maturity levels of the document,” he added.
Long-time IETF participant Dave Crocker suggested that a second label be explored, one in which the market reports its use of particular standards. In this scenario, a document would move to “Proposed Standard” for X number of years. If the market does not come back within that many years, it ceases to be a standard. Dave said that while not moving through the levels doesn’t seem to be hindering the process, he lamented the “lack of feedback about the specs.”
Brian put the issue to an informal vote, resulting in no clear consensus on which of the three options is preferred. There was some agreement, however, that the nature of the problem may have been incorrectly stated and that the discussion would continue on the IETF mailing list.
IAOC Makes Progress, Moves toward the Future
Lucy Lynch, chair of the IETF Administrative Oversight Committee (IAOC), reported that a request-for-information (RFI) had been issued for the RFC Editor function, as were a statement of work (SoW) and a draft IANA service-level agreement (SLA). Both the SoW and the SLA were sent to the IETF community. Shortly after the IETF 66 meeting, an RFP for the RFC Editor function was published.
Lucy gave a brief summary of a two-day IAOC retreat held in May, where members outlined future activities and turned their attention to setting goals. Topics discussed at the retreat included meeting planning, funding models, and IASA goal setting, as well as plans for finalising an IASA work plan for 2006-2007. Lucy announced progress on the newly formed IETF Trust, saying that some issues still await resolution within the Intellectual Property Rights (IPR)-WG, which affect both ISOC and the Trust. “We need to deal with current physical assets transferred from CNRI and develop a document’s retention policy,” said Lucy. The IAOC expects to solicit additional donations of IETF-related IPR in the coming year and the group is addressing the need for inventory tools and archival storage. More information can be found at the IAOC Web site at http://wkoi.uroegon.edu/~iaoc/, which will soon move tohttp://iaoc.ietf.org.
IASA: The First 180 Days
Reporting on the activities of the IETF Administrative Support Activity (IASA), IETF Administrative Director (AD) Ray Pelletier outlined plans to establish a multievent contract with a hotel chain, which he said, was intended to reduce both costs and risks associated with IETF meetings as well as to improve long-term planning. The group is also considering the possibility of outsourcing the operations of the IETF meeting network, which Ray said would reduce the host’s workload and possibly attract organisations that may not possess expertise in running big networks to host an IETF meeting.
According to Ray, the additional resources that have recently been invested in the RFC Editor had met with success, as evidenced by the elimination of copy-edit backlog. An RFP is being issued for the RFC Editor function and Ray anticipates that new contracts will be negotiated in September. A transition is scheduled for December and RFC Editor services are expected to commence in January 2007.
Photo: Shane Kerr
IANA Operations Manager Barbara Roseman announced that while a few positions remained unfilled, the increase in administrative staffing has resulted in measurable service improvements. By introducing redundancy and providing for back-up for staff on leave, single points of failure have been eliminated. In addition, the regularising of request processing has led to increased responsiveness and better collection of statistics. However, according to Roseman, due to legacy data and the fact that highly detailed and accurate statistical reporting requires considerable preparation time, a few issues remain regarding the collection and analysis of statistics. Prior to IETF 67, IANA expects to complete implementation of the SLA within the IAB, migration of historic data, public documenting of IETF-related processes, and the launch of a new web site for IETF assignments.
IETF 66 Technical Report Draws Attention to DNS and IDN
The publication of draft-iab-idn-nextsteps took center stage at the technical session of the IETF 66 plenary. IAB Chair Leslie Daigle made it clear that the intention of the document is not to propose solutions, but “to identify issues and in some cases possibilities.” The document identifies a number of experiences with IDNA and IDN, including concerns about character spoofing and similarities that do not currently have technical fixes. Leslie also pointed out the difficulty in trying to design policies that are helpful in solving such problems but not so restrictive as to make IDNs unappealing.
The position of the IAB is that the time is right to review certain aspects of IDNA – especially the tables. Leslie suggested that a more restricted approach to permitted characters may be needed. There was also general agreement that IDN creates problems for DNS as it exists today. “We could spend a long time debating this,” said John Klensin. “But the point is that these things overload the DNS and DNS was never built to deal with these kinds of issues.”
Independent Document Submissions
A proposal to change the document draft-iab-rfc-editor-00.txt based on feedback from the community was offered by Leslie. The draft describes the need for an RFC Series that is implemented for the community and that has a number of key characteristics: it needs to be expertly implemented and clearly managed, and it needs appropriate community input and review of activities.
According to Leslie, the proposal would allow for more explicit integration of the RFC Editor, the IAB, and the IETF, while ensuring that each retains clear and distinct responsibilities. RFC Series decisions would thus be more open to community discussion, with the IAB monitoring the discussion and maintaining the coherency of the series and related discussions. Leslie said the IAB believes that the proposed changes would clarify the role of decision-making groups and ensure the right balance of RFC streams. The community is encouraged to participate in the discussion on a new mailing list atwww1.ietf.org/mailman/listinfo/independentlist.
A fair portion of the plenary session was dedicated to a public discussion about independent submissions to the RFC Editor. IAB member Olaf Kolkman, who led the discussion, is the moderator of firstname.lastname@example.org mailing list.
Olaf pointed out that it is important to the RFP process that policies and procedures be documented. The IAB is looking for broad community input, which is why the mailing list was announced at the IETF as well as other venues, such as the Regional Internet Registry (RIR) communities. The feedback received on the list thus far indicates that the document “draft-klensin-rfc-independent-02.txt” provides a good desription of the current process and procedures. There are a number of open issues, related mostly to different interpretations of RFC 3932 – “The IESG and RFC Editor Documents: Procedures” – and which require broad agreement. Olaf presented a number of issues and encouraged people to raise their voices on the mailing list. He pointed out that now is the time to set up a good working structure for RFCs and independent submissions.
In the discussion that followed, Allison Mankin cautioned participants about making changes to RFC 3932 as it is an approved BCP that was reviewed by the community. In contrast, others felt it is important that the document reflect reality, such as in the editorial process and in the way reviews are accomplished.
It was also suggested that non-IETF-consensus documents should have a different name or label, so they do not get confused with standards-track documents.
This discussion will be continued on the email@example.com mailing list.
The Challenges of Appeals
With formal appeals on the rise, the IAB was asked if having to deal with those types of challenges is consuming too much of the group’s time and, if so, wether the IAB would consider using a separate organisation to handle appeals. Members of the IAB agreed that the appeals process is an important part of the IAB’s work, as well as part of its charter. As Eric Rescorla pointed out, the appeals process may take time, and the IAB should probably think about streamlining the process instead of creating a separate pool of people to handle appeals.”
A key concern expressed by attendees was the potential of one-person appeals to obstruct the process. “The past several months have demonstrated the potential for people who are not actively participating in getting things done to be launching appeals,” said John Klensin. He added that the IAB should consider mechanisms for “applying dampers” for appeals that are submitted repeatedly, before the situation gets out of control.
Of equal concern was the need to handle changes to the appeals process with care. Bradner reminded the group that the appeals process was not only an issue of fairness but also a condition set by the IETF’s insurance company as means for avoiding litigation. “We need to be careful when changing the appeals process,” he said. “We cannot be seen as an unfair organisation by insurance companies, even though we have never had to use the insurance so far.”
Dave Crocker expressed appreciation for the diligence with which appeals have been handled thus far but said he felt “real concern” about the abuses he has seen recently. “The IETF model of rough consensus is about broad-based concern and consensus,” he said, suggesting that the IETF consider requiring that appeals be submitted by multiple people or at least supported by others. “It might also make sense that an appeal should not be resubmitted by the same person,” he said.
While it was agreed that care should be taken when addressing changes to the appeals process, there was general agreement that the number of appeals should be reduced by any means.
Anticipating the Future
When asked what they thought the most pressing problems over the next five years might be, IAB member Lixia Zhang answered that the routing system needs a fundamental change. “Congestion and routing were problems at IETF 1,” she said. “Congestion solved itself but the routing problem is still there.” She also pointed out the value of looking back to see which protocols have been successful and which others took a lot of time but didn’t take off. Conducting this type of review, she said, would help in the future with prioritising tasks.
IAB member Bernard Aboba answered that until the IAB workshop on unwanted traffic, he had underestimated the security problem. “Often we seem to underestimate how difficult it is to apply security mechanisms on a global scale,” he said. Dave Oran, a new IAB member, said that over the past 20 years, there have been dramatic shifts in traffic as a result of e-mail, the Web, and VoIP. “We need to be getting more knowledgeable about applications that have no known upper bound on bandwidth,” he said. “We need to figure out network management without thinking that adding bandwidth is the solution.” It was recommended to work closely with ISOC on issues related to policy and politics.
The discussion gravitated toward nontechnical issues, particularly those involving policy, including whether the IETF should be concerned with Net Neutrality. “There are a lot of important issues out there that are at a different level,” said Bradner, “but we should not overlook them. Routing might not be important anymore if bad things happen at level 8 or 9.”
Presentations given during the IETF 66 plenary session can be found atwww3.ietf.org/proceedings/06jul