IETF News

IETF Ornithology: Recent Sightings

By: Mat Ford

Date: March 1, 2013

line break image

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 the level of interest in and support for the work. In this article, we’ll review the BoFs that took place during IETF 85, 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.

Internet Video Codec (videocodec)

Description: To quote from the proposed charter for a working group on this topic, “According to reports from developers of Internet video applications and operators of Internet video services, there is no standardized, high-quality video codec that meets all of the following three conditions:

1. Is optimized for use in interactive Internet applications.

2. Is published by a recognized standards development organization (SDO) and therefore subject to clear change control and IPR disclosure rules.

3. Can be widely implemented and easily distributed among application developers, service operators, and end users.

The goal of this working group is to ensure the existence of a single, high-quality video codec that can be widely implemented and easily distributed among application developers, service operators, and end users. At present it appears that ensuring the existence of such a codec will require a development effort within the working group.”

The objective of this working-group-forming BoF meeting was to understand the problem and solution space, close any open issues with the proposed charter, determine if people are willing and able to do the work (write, review, code), determine if the IETF is the right place to do the work, and determine if a working group would have a reasonable chance of success.

Proceedings: http://www.ietf.org/proceedings/85/minutes/minutes-85-videocodec

Outcome: A mostly positive discussion highlighted a few issues with the proposed charter that need further work. It is expected that a revised charter will be proposed by the next meeting.

RFC Format (rfcform)

Description: Discussion on RFC formatting. The BOF worked through some of the overriding assumptions, the existing requirements to be kept in any revised format, new requirements, RFC Editor requirements, and existing requirements that can be retired. For a summary of the more contentious issues relating to RFC format, see http://www.rfc-editor.org/rse/wiki/doku.php?%20id=formatsummary.

Proceedings: http://www.ietf.org/proceedings/85/minutes/minutes-85-rfcform

Outcome: The attendees provided detailed feedback on the various requirements and assumptions up for discussion. Discussion continues on the list (https://www.rfc-editor.org/mailman/listinfo/rfc-interest).

Interface to the Routing System (irs)

Description: The Interface to the Routing System (IRS) provides a common, standard, read/write interface that allows access to the information that enables the routing components of routing elements in the network. This BoF meeting was held to determine the focus and support for work within the IETF to specify abstract data information models, specific data models, and protocols to operate the IRS. The BoF did not assume that new data modelling languages or protocols will be required—that decision is expected to form part of the analysis carried out by a working group, if one is formed.

Proceedings: http://www.ietf.org/proceedings/85/minutes/minutes-85-irs

Outcome: This was a productive meeting that showed strong support for working group formation with a reduced scope (i.e., fewer chartered documents to produce). The discussion to refine the charter will continue and it is hoped that a working group will be formed by the next IETF meeting.

Security Automation and Continuous Monitoring (sacm)

Description: This was a working-group-forming BoF. If formed, the SACM working group will develop, where practical, security automation protocols and data format standards in support of information security processes and practices. These standards will help organizations better utilize security practitioners by automating the routine tasks related to endpoint and server security, thereby enabling practitioners to focus on more advanced tasks. The initial focus of this work is to address enterprise use cases.

Proceedings: http://www.ietf.org/proceedings/85/minutes/minutes-85-sacm

Outcome: The meeting concluded that the problem space is reasonably well understood, that standardisation is required, and that the IETF is the right place to do the work. There was consensus to create a new working group to tackle this, focussing initially on architecture and requirements as key foundational pieces of work needed to understand next steps.

Certificate Transparency (certrans)

Description: This non-working-group forming BoF discussed plans to specify mechanisms and techniques that allow Internet applications to monitor and verify the issuance of public X.509 certificates, such that all issued certificates are available to applications, and each certificate seen by an application can be efficiently shown to be in the log of issued certificates. Furthermore, it should be possible to cryptographically verify the correct operation of the log.

Proceedings: http://www.ietf.org/proceedings/85/minutes/minutes-85-certrans

Outcome: The meeting discussed several options and concluded that an AD-sponsored experimental RFC was the right thing to do with draft-laurie-pki-sunlight. It may make sense to form a working group after that. In the interim, it was suggested that an Internet Architecture Board workshop on this topic might help make progress.

Extensions to the Bonjour Protocol Suite (mdnsext)

Description: This was a working-group-forming BoF regarding the following problem. Currently, zeroconf networking protocols are generally used to discover services within the scope of a single link (e.g., mDNS and DNS-SD). The problem is how best to extend these protocols beyond a single link, such as in future multilink home networks (as envisaged by the homenet working group), or in routed campus or enterprise networks. As demand for service discovery across routed networks grows, vendors are beginning to ship their own early solutions. It is both timely and important that efforts to develop improved, scalable, service-discovery solutions for routed networks are coordinated toward the production of a single, standards-based solution.

Proceedings: http://www.ietf.org/proceedings/85/minutes/minutes-85-mdnsext

Outcome: This was a good meeting with lots of participation and strong support from attendees to work on this problem and review documents. More work is needed to refine the proposed charter. It is hoped that a working group can be chartered by the next IETF meeting.

Fixed Mobile Convergence (fmc)

Description: Fixed/mobile convergence (FMC) deals with the issues surrounding the interactions of fixed and mobile networks. Of specific interest are issues with serving access to the user terminals that requires the sharing of subscribers’ policies between the fixed and mobile networks. Existing deployment scenarios range from wireless local area network (WLAN) access points directly connected to a mobile-operators core via mobile-operator owned WLAN access points to one or more access points controlled by a fixed-network operator or single access points at residential premises.

Proceedings: http://www.ietf.org/proceedings/85/minutes/minutes-85-fmc

Outcome: The proponents of this work received strong feedback that they have a lot more work to do to clarify the problem they are trying to solve. Very few of those in attendance understood the presented use cases. Taking some of these use cases to the Broadband Forum might be a next step toward identifying those gaps that need to be addressed in the IETF.

HTTP Authentication Mechanisms (httpauth)

Description: Both versions 1.0 and 1.1 of hypertext transfer protocol (HTTP) can run over a secure or an insecure transport. By default, the user is not identified or authenticated. But HTTP does contain a framework for user authentication. Existing standards provide two authentication methods:

– Basic: analogous to point-to-point protocol’s (PPP’s) password authentication protocol (PAP)

– Digest: analogous to challenge-handshake authentication protocol (CHAP) or MD5-Challenge

Both of these authentication methods are considered insecure. This BoF meeting discussed whether an IETF working group should be formed to develop a better authentication mechanism for HTTP.

Proceedings: http://www.ietf.org/proceedings/85/minutes/minutes-85-httpauth

Outcome: The meeting exposed two schools of opinion regarding the merits of this proposal. One group believed this should be chartered immediately to solve an obvious problem. The other group felt that it is still unclear what the scope of useful work would be and that chartering a working group without a clear scope would likely lead to failure.