Getting new work started in the IETF usually requires a birds-of-a-feather (BoF) meeting to discuss goals for the work and to help assess the level of interest in and support for new work. In this new regular feature of the IETF Journal, we will review the BoFs that took place during the most recent IETF meetings and summarize their intentions and outcomes.
BoF meetings have a very different tone than do [working group] WG meetings. The purpose of a BoF is to make sure that a good charter with good milestones can be created and that there are enough people willing to do the work needed in order to create standards. Some BoFs have Internet-Drafts already in process, whereas others start from scratch.
An advantage of having a draft before the BoF is to help focus the discussion. On the other hand, having a draft might tend to limit what the other folks in the BoF want to do in the charter. It’s important to remember that most BoFs are held in order to get support for an eventual working group, not to get support for a particular document.
Many BoFs don’t turn into WGs for a variety of reasons.
The Tao of IETF (http://www.ietf.org/tao.html)
If you are inspired to arrange a BoF meeting, please be sure to read RFC 5434: Considerations for Having a Successful Birds-of-a-Feather (BoF) Session.
Full descriptions of the BoFs that took place during IETF 80 in Prague, the Czech Republic, can be found on the wiki at http://trac.tools.ietf.org/bof/trac/wiki/WikiStart.
RTCWEB – Real Time Communication on the World Wide Web
Description: Many implementations have been made that use a Web browser to support direct, interactive communications, including voice, video, collaboration, and gaming. In these implementations, the Web server acts as the signalling path between these applications, using locally significant identifiers to set up the association. Up until now, such applications have typically required the installation of plugins or nonstandard browser extensions. There is a desire to standardize this functionality so that these types of applications can be run in any compatible browser and allow for high-quality real-time communications experiences within the browser.
Minutes: http://www.ietf.org/proceedings/80/minutes/rtcweb.txt
Outcome: This effort, spearheaded by Google, but with coinitiative takers including Cisco, Ericsson, Mozilla, and Skype, aims to establish standards for enabling browsers to send audio and video between each other without the need for media intermediaries, which would make interactive video a commonplace rather than a specialized undertaking.
The meeting was very well attended (more than 250 attendees) and showed both strong support for letting this go forward and quite good consensus that we had achieved “roughly the right level” in the proposed charter. The Friday work session laid out some of the challenges ahead, including thorny issues such as what happens when intellectual property rights claims meet “mandatory to implement.”
The work will go forward in cooperation with the W3C.
CDNI—Content Distribution Network Interconnection
Description: There is an emerging requirement for interconnecting content delivery networks (CDNs) so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. This BoF is an opportunity to discuss the proposed development of IETF standards to facilitate such CDN interconnection. These standards might include protocols for the following.
Exchange of metadata between CDNs
Exchange of transaction logs and monitoring information
Exchange of request-routing information
Exchange of policies & capabilities
Content management/flushing
Minutes: http://www.ietf.org/proceedings/80/minutes/cdni.htm
Outcome: Approximately 120 people attended the CDNI BoF. The first presentations established the multiple-use cases that network service providers have for CDN interconnection (such as footprint extension, off-net delivery, offload and fail-over, multivendor, and over the top content providers) and introduced the key missing touch-points needed across CDNs.
The CDN interconnection experiments presented next confirmed the feasibility of content delivery across two CDNs while bringing to light the limitations resulting from the lack of a standard approach. A poll of the audience revealed a strong agreement that there was a real problem that needs solving.
The next few presentations articulated the overall CDNI architecture as well as the functional role and requirements for each of the four inter-CDN interfaces that would be in the scope of the CDNI WG (CDNI Request-Routing, CDNI Distribution Metadata Exchange, CDNI Logging, and CDNI Control). The resulting discussion concluded that the CDNI WG would need to document the threat analysis, including discussion of the CDNI trust model and privacy issues.
The next discussion centred on the question of whether CDNI required new protocol or protocol extensions. The key outcome is that the CDNI work is expected to involve definition of new schemas (such as the definition of a Web services-style of interface), but no new schema languages and no new protocol or protocol extensions.
A show of hands indicated consensus that the problem was well understood and that the IETF was the right place to solve it. After review of the draft charter and some real-time tweaks, there was consensus in the room that the draft charter identifies the right set of deliverables and that a WG should be created with that charter. Many individuals volunteered to be editors or reviewers of the CDNI deliverables.
The charter has been refined and the the IESG recently announced formation of the CDNI working group in the Transport Area. The CDNI WG will hold its first meeting during IETF 81.
Plasma–Policy Augmented S/MIME
Description: Current S/MIME mechanisms provide cryptographic access to a message based on the identity of the recipient at the time of transmission. Any additional access-control enforcement depends on the configuration of the recipient’s email client. Several Internet-Drafts have been submitted that establish a more robust access-control mechanism, where cryptographic access to a message is only granted after the access check.
This proposed WG would develop a framework for enforcing a more robust access-control mechanism, based on existing CMS, S/MIME, and SAML-based policy-enforcement standards. The WG will also develop any necessary extensions to these base protocols specific to this problem space.
Minutes: http://www.ietf.org/proceedings/80/minutes/plasma.txt
Outcomes: Despite some original concerns that the work is only of interest to a limited group of people, the meeting was well attended and there was active participation in the discussion of related use cases. Some interest in using a ABFAB-capable solution together with the policy server was expressed.
One area director questioned why sending secure email can’t be done using only Web protocols (without SMTP at all), eliminating the need for S/MIME. Proponents answered that users still like to use email for many tasks, so building upon/fixing existing secure email is a desired goal.
At the end of the meeting several participants (in addition to the BoF proponents) expressed their desire to work on something in this space. Several people were also interested in use of the proposed architecture for non-email use cases (such as with XMPP or for website access controls). As there was no strong consensus that a WG should be formed, the proposed charter was not discussed. This will be done on the mailing list at an appropriate time.
Some questions were raised about whether the proposal presented was the best design and whether something else (which can turn out to be more generic) can be used. The discussion on the mailing list is ongoing. It is currently unclear whether this proposal will go on to form a WG.
PAWS–Protocol to Access White Space Database
Description: As nations struggle to provide radio spectrum for use with wireless Internet bandwidth, there are problems with incumbents in a given band. The incumbents may use the spectrum inefficiently, especially geographically; for instance, there may be large regions where a particular band is not used at all and others where use is only in a portion of the band.
Recently, techniques have been developed that attempt to share spectrum between incumbents and new users. The generic term for this is ”white space.” For example, in over-the-air TV bands, spectrum is divided into channels. In any one area it is possible that not all channels have TV transmitters in range. There is a desire among many regulators to make this prime spectrum available for Internet access and other uses, as long as the new use does not interfere with existing TV band use.
The U.S. Federal Communications Commission has freed up its digital TV spectrum for unlicensed use and has crafted rules and regulations that require compliance. The available spectrum and associated channels for use vary on a regional basis. In the United States, as in many other countries, there are other incumbents besides the television broadcasters. Spectrum and channel availability is dynamic while spectrum use requires verification of availability prior to use (and periodically on an ongoing basis). The U.S. regulator has decided that all new users of the TV band white space (“TV Band Device” or TVBD) must query a database with the location of the TVBD and receive from the database a list of available channels that it may use.
Multiple databases containing the information about available channels for use at a given location are expected to exist. A device is required to query the database for available channels and associated information. There are several scenarios that the U.S. regulation permits, which include a simple tower/client arrangement where the tower queries the database on behalf of itself and its client TVBDs and ad-hoc mobile networks where at least one TVBD in the ad-hoc network has another path to the Internet that can query the database.
Minutes: http://www.ietf.org/proceedings/80/minutes/paws.txt
Outcome: The BoF went very well. After everyone was brought up to the same level on what White Space is, how it works, and what the group wanted an IETF WG to do, participants engaged in a number of lively discussions on privacy and security issues and how the group may be able to achieve its goals of supporting database queries that are independent of physical layer, spectrum band, or nation. Several suggestions were made for charter language improvement in these areas.
A number of people in the room indicated that they would contribute or review contributions. It is common at this stage to have little opposition to creating a WG but only a relatively small number of people willing to do work. This BoF attracted roughly two to three times the usual number of people indicating they would be active participants.
The IAB and IESG have been discussing the charter. It does look like the group will have approval to form a Working Group, albeit with some further changes to the scope and, specifically, in the security and privacy text on the proposed charter. An interesting aspect of this work is that the participants did not suggest a specific area, as the work does not seem to fit neatly into any of the area definitions particularly well but, rather, it touches on a number of them. In the end, it seems like we it be in the Apps area.
Renum–Site Renumbering
Description: As outlined in RFC 5887, renumbering, especially for medium to large sites and networks, is viewed as an expensive, painful, and error-prone process, often avoided by network managers as much as possible. Some would argue that the very design of IP addressing and routing makes automated renumbering intrinsically impossible. In fact, managers have an economic incentive to avoid renumbering, with many resorting to private addressing and Network Address Translation (NAT). Consequently, mechanisms for managing the scaling problems of wide-area (BGP4) routing that require site renumbering are often dismissed as unacceptable. Even so, renumbering is sometimes unavoidable.
The task of the proposed RENUM Working Group is to (1) identify specific renumbering problems in the context of site-wide renumbering and (2) develop point solutions and system solutions to address those problems (or, if appropriate, to stimulate such development in other Working Groups). The principal target will be solutions for IPv6, but solutions that apply equally to IPv4 may be considered.
Minutes: http://www.ietf.org/proceedings/80/minutes/renum.txt
Outcomes: While there was an encouraging level of interest expressed in the BoF in terms of people willing to work on this topic, it was also recognized (quite rightly) that renumbering is a huge area and that trying to solve all renumbering issues in one go is unrealistic. The discussions in the BoF raised a number of ways that the work could be more focused. Therefore, since the meeting, the BoF has been working on scoping the potential WG charter to allow achievable, but useful, goals to be defined.
There is significant concern over the potential increase in the size of backbone routing tables should large numbers of end sites adopt IPv6 PI addressing. Thus, focusing the work on (managed) IPv6 enterprise networks and (unmanaged) SOHO networks is one avenue to scope the work more realistically. As IPv6 becomes more widely deployed, it is expected that we would have developed appropriate new operational and protocol elements so that site renumbering will be seen as a more routine event.
A first step for a new WG could thus be undertaking scenario-based descriptions, including documentation of current capabilities and best practices. These texts can then contribute to a gap analysis that also draws on existing published work in RFC 4192 and RFC 5887. In parallel, a review of current IP address-management practices would be performed to determine if a more appropriate model for supporting site renumbering might be devised. This initial programme of work would not lead immediately to new protocols or practices, but a subsequent WG recharter would identify how and where such work could be done.
Implicitly, such a focus would mean a ‘RENUM6’ WG would not cover renumbering avoidance methods, ISP renumbering (except the ISP’s role in site renumbering), or IPv4 renumbering. he IPv6 Site Renumbering (6renum) working group has been formed in the Operations and Management Area and the full charter is at http://datatracker.ietf.org/wg/6renum/charter/.