Getting new work started in the IETF usually requires a birds-of-a-feather (BoF) meeting to discuss goals for the work, the suitability of the IETF as a venue for pursuing the work, and to assess the level of interest in and support for the work. In this article, we’ll review the BoFs that took place during IETF 83, including their intentions and outcomes. If you’re inspired to arrange a BoF meeting, please be sure to read RFC 5434: Considerations for Having a Successful Birds-of-a-Feather (BoF) Session.
SCIM—Simple Cloud Identity Management
Description: The Simple Cloud Identity Management (SCIM) specification is designed to make managing user identity in cloud-based applications and services easier. The specification suite seeks to build on experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users into, out of, and around the cloud. For more details, see http://www.simple-cloud.info/.
Outcome: A very productive discussion that indicated lots of interest in the work and support for doing the work in the IETF. Ongoing discussion will address the scope of the work and how to label it (not everyone is happy to see the word cloud used in this context). See our cover article by Chris Phillips for more discussion of this developing area.
WEIRDS—WHOIS-based Extensible Internet Registration Data Service
Description: This work is aimed at designing a replacement for WHOIS that can be delivered as a RESTful service, with an eye toward avoiding a number of the issues that have prevented IRIS (Internationalized Resource Identifiers) deployment as a WHOIS replacement. The impetus for this work is the existence of three already deployed experimental services similar to the approach being proposed for IETF work, as well as the burgeoning number of internationalized domain name (IDN) TLDs in the domain name system root zone. See the cover article from the last issue for more detail:http://www.internetsociety.org/articles/something-weirds-way-comes.
Outcome: Following the BoF meeting held during IETF 82 in Taipei, Taiwan, this meeting focussed on how to scope the charter for a working group (WG) on this topic. If working on a solution that includes domain names starts to slow things down, the focus will shift to numbering resources only.
RPSREQS—Remote Participation Services Requirements
Description: For many years, the IETF has provided tools for remote participation in a variety of activities. Some IETF participants also used their own tools when they felt the need. The IETF now wishes to support enhanced remote participation that is as seamless as possible, approaching the quality of direct physical attendance for the various roles—including chair, presenter, and simple attendee. Before deploying the new tools and services needed for this enhanced remote participation, the requirements for such tools and services must be defined. This meeting allowed for discussion of the draft requirements and participants’ experiences of remote participation during the IETF 83 meeting.
Outcome: Good discussion, more to come as this work progresses.
ANTITRUST—Does the IETF Need an Antitrust Policy?
Description: Standards development organizations have done a range of things in response to antitrust legislation over the years. This meeting addressed the question of whether there is anything that the IETF could or should usefully do in this regard.
Outcome: The meeting identified a need for two types of materials to be produced: (1) educational materials aimed at chairs that clarify the laws of various countries, and (2) materials that put this information within the context of the IETF.
RFCFORM—RFC Format
Description: The newly appointed RFC series editor, Heather Flanagan, is soliciting input on the question of formatting the RFC series. This topic has a long history of passionate debate within the IETF community and this meeting was intended to capture as many of the different requirements and concerns about moving to a new format as possible before any firm proposals are tabled.
Outcome: Very well organized session, no conclusions reached yet.
NVO3—Overlay Networking
Description: Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized servers known as virtual machines (VMs). A key multi-tenancy requirement is traffic isolation, so that a tenant’s traffic (and internal address usage) is not visible to any other tenant and does not collide with addresses used within the data center itself. Another key requirement is to support the placement and live migration of VMs anywhere within a data center, without being limited by DC network constraints, such as the IP subnet boundaries of the underlying DC network.
This work proposal will develop an approach to multi-tenancy that does not rely on any underlying L2 isolation mechanisms to support multi-tenancy. In particular, the proposal will develop an approach where multi-tenancy is provided at the IP layer using an encapsulation header that resides above IP. This approach should provide an Ethernet service. It may provide an IP service; an important goal is to develop a layer-agnostic framework and architecture that meets data center requirements.
Outcome: This was a packed meeting with lots of support for adopting this work within the IETF. The chairs presented a well-developed draft charter and there was considerable support for it. Many people indicated they would be interested in actively participating in this work by writing and reviewing documents and there was no dissent. A proposed charter for a WG is now in review.
I2AEX—Infrastructure-to-Application Information Exposure
Description: A non-WG-forming BoF to investigate infrastructure-to-application information exposure and communications requirements in fully controlled (such as data centers) or partially controlled environments (such as content delivery networks (CDNs)). Application-layer traffic optimization (ALTO) was designed to provide network infrastructure information to applications that may not be under the same administrative control as the network. ALTO only reveals limited information about the network infrastructure. By comparison, other protocols that monitor and manage infrastructure may reveal much more information, but are typically only accessible to the operators of the network infrastructure. CDNs and data center applications have some requirements to operate over the Internet, possibly between administrative domains. ALTO was initially designed to address peer-to-peer application requirements, but it was designed to be extensible. This BoF seeks input from the IETF community about whether ALTO (with possible extensions) or other protocols might be most appropriate to satisfy the information access requirements of CDN and data center applications. As this is not a WG-forming BoF, but an input-gathering exercise, discussion of proposed work in this BoF should not lead to any expectation that any specific proposed work will be authorized.
Outcome: Operator input indicated that if trust and security issues can be resolved, then they are willing to expose the information to applications. Application developers indicated they are willing to make use of this information. The ALTO model provides a useful abstraction but it is critically missing a publish-subscribe mechanism. There is a choice of protocols that may apply here. Work may proceed in the ALTO WG, or maybe in another venue.