IETF Ornithology: Recent Sightings

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 92, including their intentions and outcomes. 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.”

By: Mat Ford

Date: July 6, 2015

line break image

Locale-free UniCode Identifiers (lucid)

Description: The Internet Architecture Board (IAB) recently issued a statement about issues found by the use of some characters in identifiers ( The IAB expects that the IETF investigate ways to address this problem. Work could be done in existing Working Groups or elsewhere. The purpose of the BoF meeting is to define a plan.


Outcome: This meeting was not intended to form a Working Group. There was vigorous discussion of the problem statement and possible ways forward. Meeting participants agreed that there is potentially a serious problem here and that getting the Unicode Technical Consortium experts engaged and working on the drafts are key next steps.

Managing, Ordering, Distributing, Exposing, and Registering telephone Numbers (modern)

Description: The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing and resolving telephone numbers (TNs) in an Internet Protocol (IP) environment. Existing mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and new applications for TNs become possible. The traditional model of a TN having an association to a single service provider and a single application is breaking down. Although its use as a network locator is going away, its use as an identifier for an individual or an organization will remain for some time. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities.


Outcome: There was lively discussion of the problem of adapting telephone-number handling to all-IP networks. The charter discussion was very detailed and indicated that more work on the charter is necessary before a WG can be formed. There was strong support to form a WG to address this problem.

Automated Certificate Management Environment (acme)

Description: This meeting was to discuss ongoing work related to automated public-key certificate management. Let’s Encrypt ( was a primary discussion point, but other Certificate Authorities and other stakeholders were also represented.


Outcome: There was strong community support for working on this problem and consensus in the room to try to charter a WG as soon as possible via further discussion on the mailing list.

Simplified Use of Policy Abstractions (supa)

Description: The purpose of SUPA is to develop a methodology by which management of network services can be done using standardized policy rules. The working group will focus in the first phase on interdatacenter traffic management in the use case of a distributed data center, including the automated provisioning of site-to-site virtual private networks of various types.


Outcome: There was agreement in the meeting that there is a problem to solve here, it is reasonably well understood and that there may be some work relevant to the IETF. Further work is required to more clearly articulate and scope the charter of a proposed WG in this space.

DDoS Open Threat Signaling (dots)

Description: There is a need for a standards-based approach for on-premise distributed denial-of-service (DDoS) mitigation devices to communicate threat and telemetry data to service provider based solutions. On-premise DDoS mitigation devices are sophisticated entities that may already identify, profile, and mitigate a wide range of attacks. Although flow export, syslog, and Simple Network Management Protocol (SNMP) are currently used by service providers to identify anomalies, there is no agreed standard allowing for any device to signal to any other device or service provider what the anomaly is and the subsequent threat telemetry data. 

DDoS open threat signaling (DOTS) would enable any on-premise DDoS mitigation device to effectively communicate the current threat landscape and load and response data to a mitigation service provider. The upstream solution would then have a clear view of the threat should the on-premise solution be required to redirect attack traffic to a more capable handler. A vendor-agnostic approach would allow any combination of vendor, service provider, or community-driven efforts to interoperate. DOTS would be extensible and may, in the future, be expanded as a method of real-time information exchange between other security devices and potentially across organisations.


Outcome: This meeting was not intended to form a WG.  Attendees discussed two draft documents and held a panel discussion with people building services and appliances related to DDoS threat signaling. It was agreed that there was work worth standardizing in the IETF here, if appropriately and narrowly scoped. Charter text will be refined on the mailing list.

Session Protocol for User Datagrams (spud)

Description: The deployment of new transport protocols, as well as the extension of existing IETF-defined transport protocols faces the continuing challenge of how to make these protocols robust against packet and flow modification in the Internet at the hands of middleboxes. The increasing deployment of these middleboxes have made expectations about packet handling behaviors implicit. For example, a Transmission Control Protocol (TCP) packet with the SYN and ACK flags set not only synchronizes sequence numbers and sets up state on both endpoints for a TCP connection (its explicit meaning), it also confirms network address translation (NAT) mappings along the path and signifies to any firewalls along the path that the endpoint has accepted the connection (implicit meanings). One strategy to resolve this tussle was identified and discussed during the recent IAB workshop on Stack Evolution in a Middlebox Internet (SEMI): provide a mechanism for applications at the end as well as boxes along the path to explicitly declare their assumptions and intentions.


Outcome: This was not a Working Group forming meeting. A good community discussion of the SPUD proposal was had and while it was clear that there is not work ready for standardization here, there is further discussion to be had about where to continue the work (e.g. in the IAB program, or the IRTF).

Internet Video Codec (netvc)

Description: The Internet needs a royalty-free (RF) video codec that can become the backbone for universal deployment of video related technologies. Royalty-bearing codecs put constraints on implementors that are unacceptable, but current RF codecs are not yet competitive with royalty-bearing offerings. This dilemma stalls innovation and means large sets of consumers don’t have access to the best video technology.

There are efforts underway by several groups to produce a next-generation RF video codec, including VP10 by Google and Daala by Mozilla/Xiph.Org. While far from complete, these efforts aim to surpass the royalty-bearing competition. Efforts within other standards organizations to create RF video standards have been unsuccessful so far, but have showed that many consumer device manufacturers would support an RF codec.

The success of Opus from the CODEC WG has also shown that collaboration, based on the IETF’s principles of open participation, can produce better results than competition between patented technologies. 


Outcome: There was unanimous agreement that there was a problem that needed solving and strong support for the idea that the scope of the problem was well-defined and understood. The majority of those present felt that an IETF WG should be formed. [Note: The Internet Video Codec (netvc) WG was formed on 18 May 2015.]

No Comments to Show

Leave a Reply

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