* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Birds of a Feather Meetings (IETF Pre-WG Efforts)

This page provides one common place that lists "possible IETF pre-WG efforts", known as Birds of a Feather ("BoF") meetings. Anybody who proposes a BoF is strongly encouraged to register the BoF effort here at such time as appropriate; e.g., during steps 1 and 2 in RFC 5434. Also see http://www.ietf.org/wg/bof-procedures.html.

The IAB will also attempt to provide BoF Shepherds as described in their document on the subject only on request from the IESG. If you feel that your BoF would benefit from an IAB BoF Shepherd, please discuss this with your Area Director.

To allow the Secretariat to schedule a BoF slot if it is approved, each entry MUST include the following items:

  • Long name and abbreviation
  • Description, including whether the BoF is intended to form a WG or not
  • The responsible Area Director (AD)
  • BoF Chairs (or the ADs as placeholders)
  • Number of people expected to attend
  • Length of session (1, 1.5, 2, or 2.5 hours)
  • Conflicts to avoid (whole Areas and/or WGs)
  • Does it require WebEX? If so, why?
  • Does it require Meetecho? If so, why?
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Template for BOF Entry

Timeframe IETF 91 (Honolulu)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 2359 UTC Friday, September 26, 2014. The IAB and IESG will hold a joint teleconference to discuss the proposals. ADs will be expected to approve or disapprove the BOF request on that teleconference, ensuring that the Secretariat has all of the information to put the first draft of the agenda together on or before October 10.

Applications

arcmedia (Approved for IETF 91)

  • Name: archive Top Level Media Type
  • Description: The purpose is to discuss registering a top level media type for file archives, i.e., formats that package files and file metadata into a single data stream. Common semantics apply to all archive formats in ways that are very similar to multipart and message top-level types. Each file has its own security implications, along with metadata that also has security implications (user and group permissions, access bits, executable bits, ACLs). At the highest level, an Internet-connected application ought to be able to identify that a particular piece of content is of this type (as opposed to the opaque application type), so it can make decisions about the content that are unique to archives, namely, dealing with the security issues, and presenting uniform user interfaces to handling such archives. Content bundling types like message (RFC 5322), multipart, and application/cms (CMS) are conceptually distinct. All those types can contain content that can get split off into files, but their purpose is not to replicate file system data.

    Archives are ubiquitous on the Internet. Even if archives are used "infrequently" across the Internet architecture, they are obviously used at the endpoints. Improper transmission of archives has become a major source of labeling and security issues.

    Remarkably, most archive formats have not been registered as media types (except for application/zip, which is an oldie). Therefore, it's pretty much a "clean field". Furthermore, there is a trend of a lot of widely available tools to support multiple formats, so the probability is good that if you pass some archive/* labeled content to an archive application, it will be able to do something intelligent with it.
  • Agenda
    • Speaker: Sean Leonard
    • Other Speakers: TBD
    • Discuss proposal to make archive TLMT
    • Identify use cases
    • Identify types of archives and whether these types of archives should all go in, e.g.: archiving only, multi-function, software packaging, disk images, backup
    • Identify formats in common use, and debate which ones should be considered as exemplary for purposes of creating archive TLMT
    • Identify commonalities between all formats
    • Sketch how to represent commonalities (e.g., fragment identifiers), and whether these commonalities should be mandated (e.g., all fragment identifiers have the same syntax or the same (possibly extensible) base syntax)
    • Identify user interface considerations
    • Identify security considerations
    • Identify composite-type considerations (e.g., Content-Coding of bzip2 vs. integrating into media type)
    • Identify issues with interchange when sending and receiving systems do not have the same settings (e.g., different code pages), and the failure to coordinate these same settings result in interchange problems because the archive does not take the differences into consideration (e.g., interpreting file names in one character set/codepage vs. another character set/codepage, where the character set/codepage is not specified in the archive)
    • Divide work up
  • Status: non WG Forming
  • Responsible AD: Applications Area: Barry Leiba and/or Pete Resnick
  • BoF proponents: Ned Freed <​ned.freed@mrochek.com>, Ira McDonald?? <​blueroofmusic@gmail.com>, Matthew Kerwin <​matthew@kerwin.net.au>
  • BoF chairs: ?
  • Number of people expected to attend: 50
  • Length of session (1, 1.5, 2, or 2.5 hours): 1 hour
  • Conflicts to avoid (whole Areas and/or WGs): Apps Area, SAAG, URN/URI-related discussions, TLS. Preferably not Friday.
  • Does it require WebEX? Yes
  • Does it require Meetecho? Yes
  • Mailing List Discussions: ​https://mailarchive.ietf.org/arch/msg/media-types/S1tGM-I7kta-27r3ooFLasGQZEY

General

Internet

DPRIVE (Approved for IETF 91)

  • Name : DNS Private Exchange (DPRIVE)
  • Description: This is a placeholder for the proposed DPRIVE WG, whose charter is under review.
  • Responsible AD: Brian Haberman
  • Chairs: Tim Wicinski and Warren Kumari
  • Number of attendees: 100
  • Length: 2 hours
  • Conflicts: DNSOP, IPSECME, DANE, OPSAWG
  • WebEX: No
  • Meetecho: No
  • Mailing list: dns-privacy@ietf.org

DetNet (Approved for IETF 91)

Operations and Management

ANIMA (Approved for IETF 91)

  • Name: Autonomic Networking Integrated Model and Approach (ANIMA)

Note: proposed charter at https://datatracker.ietf.org/wg/anima/charter/ This charter status is "proposed" and on the IESG formal telechat on October 30

  • Agenda
  • 1. Agenda bashing (5 min)
  • 2. Area Director introduction (Benoit, 10 min)
  • 3. Charter [short presentation, mainly discussion] (40 min)
  • 4. NMRG Document status (10 min)
  • 5. ANIMA & related documents overview [not detailed presentations] (20 min)
  • 6. Discussion of major issues (60 min)
  • 7. Next steps (10 min)

LIME (Approved for IETF 91)

  • Name: Layer Independent OAM Management in the Multi-Layer Environment (LIME)

Note: proposed charter at https://datatracker.ietf.org/wg/lime/charter/ This charter status is "proposed" and on the IESG formal telechat on October 2nd

  • Description: Network Operators have been increasingly challenged with operational and management limitations in typical network deployments due to siloed Operations, Administration, and Maintenance (OAM) in different administrative and technology layers. This problem is exacerbated by the lack of a common architectural approach to OAM tools in those different layers. New work on network virtualization further complicates the layering model and the problems of coordinating OAM between layers. The absence of a common approach to OAM and to the management interfaces for OAM has made it very difficult for operators to:
    • Suppress large numbers of unnecessary alarms and notifications related to defects and failures arising in lower layers and visible in each higher layer
    • Quickly identify root causes of network failures
    • Coordinate end-to-end performance measurement with the results of performance monitoring at different layers in the network
    • Correlate defects, faults, and network failures between the different layers to improve efficiency of defect and fault localization and provide better OAM visibility.
    This BoF will examine whether there is sufficient understanding of this problem space to start work on data models for generic layer- independent and technology-independent configuration, reporting, and presentation for OAM mechanisms, and to define an architecture for new IETF OAM that can be used as guidance by other working groups developing new OAM protocols or modifying existing OAM protocols.
  • Agenda:
    • administrivia
    • purpose of the BoF
    • problem statement
    • potential for common data models
    • value of an architecture for OAM
    • discussion of potential charter
  • Status: WG Forming
  • Responsible AD: Benoit Claise
  • BoF proponents:
  • BoF chairs: TBD
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid (whole Areas and/or WGs):

Level 1: All OPS WGs, RTG Area Meeting Level 2: XRBLOCK, SACM, MPLS, PWE3, TRILL, RTGWG Level 3: SFC, NVO3, INT Area WG

SUPA (Not approved for IETF 91)

  • Long name and abbreviation: SUPA (Shared Unified Policy Automation)
  • Description: Programmatic ways to configure networks, often called software-defined, are considered by many network operators in order to shift the balance in their favor. Automating the way of exposing a view of the network to applications may provide significant improvements in configuration agility, error detection and uptime for operators. However the real value behind central configuration schemes lies within the possible simplification through models provided by such systems to applications and network services running above them (on the so-called northbound side).

SUPA will focus on service specific models that allow applications to request certain network services to be created/deleted/modified. A network service can for example be a virtual link between two endpoints that uses certain properties, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users.

Each network service can be represented by a service based POLICY model that can model a group of demands (i.e., actions and constraints) that are being initiated by applications that impose similar requirements on the communication network. The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to the way of how the service policy model is generated, since it groups, unifies and shares the similar requirements imposed by a bulk of applications. SUPA will provide guidelines for mechanisms that can dynamically and on an interoperable manner, AUTOMATICALLY map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies.

Please note that this is a new version of APONF BoF proposal (IETF90) based on comments received.

RAI

NETVC (Canceled)

  • Name: Internet Video Codec
  • 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 in the space 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, royalty-free (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 like MPEG 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 principals of open participation, can produce better results than competition between patented technologies. The IPR rules in BCP 78 and 79 are also critical for success. They impose a duty to disclose, and require exact patent or patent application numbers, in addition to basic licensing terms. This allows participants to evaluate the risk of infringement and, if appropriate, design work arounds, in any technology adopted, and assess the cost of adopting such technology. Because it does not force participants to agree to license their patents under RF terms, it helps to encourage participation even by those opposed to such terms (instead of guaranteeing they stay away). In addition to an environment which encourages third-party disclosures, this provides much better chances of success than SDOs which have a "patent-blind" process or which require blanket RF grants.

  • Agenda:
  1. Note Well, logistics, agenda bashing (5 minutes, Chairs)
  2. Introduction and scoping of BoF (AD, 10 min)
  3. Goals (Chairs, 10m)
  4. Progress to date (10 minutes, Chairs)
    1. rtcweb video codec discussion established perceived need
    2. Open issues: requirements, participants
    3. Several individual drafts have been published
  5. Engineering progress to date (30m, Mozilla & TBD)
  6. Charter discussion (35 minutes, moderated by Chairs)
    1. Problem statement
    2. Objectives
    3. Deliverables
    4. Milestones
  7. Questions to be answered (20 minutes, moderated by Chairs)
    1. Is there a problem that needs solving?
    2. Is the scope of the problem well defined and understood?
    3. Should this work be done at the IETF?
    4. Is there agreement on what a WG would need to deliver?
    5. Are there people willing to do the work?
      1. Writing drafts
      2. Reviewing drafts
      3. Implementing / testing / characterizing / other
    6. Would a videocodec WG have a reasonable probability of success?

Routing

BIER (Approved for IETF 91)

ACTN (Approved for IETF 91)

Security

I2NSF (Approved for IETF 91)

  • Name: Interface to Network Security Functions (I2NSF)
  • Description: The non-WG forming BoF for the Interface to Network Security Functions (I2NSF) will discuss interfaces for clients (especially enterprises) to request, negotiate, operate, and/or verify the network security functions that are not physically present at requesters’ premises. Those security functions, hosted by service providers or 3rd parties, can be instantiated on physical appliances, or as virtual machines instantiated on common compute server (i.e. the Virtualized Network Functions defined by ETSI NFV).

The Interface to (Virtual) Network Security Functions (I2NSF) initiative aims at improving the dynamic allocation and operation of network security functions by documenting a global framework that would include protocol-based control and management interfaces, along with adequate data models. The information required for the provisioning, the configuration and the operation of network security functions will be exchanged through the said interfaces and protocols. The I2NSF initiative will also take into account the need for co-existing with legacy configuration and management systems used to allocate and operate network security functions, whether they are embedded in network devices or virtualized in data center environments, for example. The standard Interface to request, negotiate, allocate, and/or operate (virtual) Network Security Functions is one of the necessary tools for operators and service providers to offer network security functions as a service to their corporate clients.

  • The responsible Area Director is Kathleen Moriarty
  • BoF Chairs: Dan Romascanu and Joe Salowey
  • Number of people expected to attend: 60
  • Length of session (1, 1.5, 2, or 2.5 hours): 2hr
  • Conflicts to avoid (whole Areas and/or WGs): NFVRG, SACM, I2RS, HTTPbis, TPCINC, SFC, RADEXT, PCE, NVO3, SAAG (and for the AD: HTTPAuth, Oauth, MILE, JOSE, IPSecMe, ACE)
  • Does it require WebEX? If so, why?
  • Does it require Meetecho? If so, why?
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

◦ Mailing list: https://www.ietf.org/mailman/listinfo/i2nsf
◦ Relevant drafts:

◦ Charter in development, working version on list: https://sites.google.com/site/interface2nsf/

Transport

DTN (Approved for IETF 91)

  • Name: Delay Tolerant Networking (DTN) BoF
  • Description:
    • The DTN BoF concerns protocols for communications over paths that may incur long delays and/or frequent disruptions. This BoF will discuss the draft charter for forming a working group.
  • Agenda
    • Welcome, note well, agenda bash, Chairs - 5min
    • draft charter discussion - 55min
  • Status: WG Forming -- Placeholder for WG to be chartered.
  • Responsible AD: Martin Stiemerling
  • BoF proponents: Fred L. Templin (fred.l.templin@boeing.com), Marc Blanchet (marc.blanchet@viagenie.ca)
  • BoF chairs:
  • Number of people expected to attend: 75
  • Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours
  • Conflicts to avoid (whole Areas and/or WGs): DTNRG, DMM, V6OPS, 6MAN
  • Does it require WebEX? Yes - Venue is a travel challenge for some interested contributors.
  • Does it require Meetecho? Yes
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

IAB Sessions

Previous meeting BOFs

Timeframe IETF 90 (Toronto)

Timeframe IETF 89 (London)

Timeframe IETF 88 (Vancouver)

Timeframe IETF 87 (Berlin)

Timeframe IETF 86 (Orlando)

Timeframe IETF 85 (Atlanta)

Timeframe IETF 84 (Vancouver)

Timeframe IETF 83 (Paris)

Timeframe IETF 82 (Taipei)

Timeframe IETF 81 (Quebec City)

Timeframe IETF 80 (Prague)

Timeframe IETF 79 (Beijing)

Timeframe IETF 78 (Maastricht)

Timeframe IETF 77 (Anaheim)

Timeframe IETF 76 (Hiroshima)

Timeframe IETF 75 (Stockholm)

Timeframe IETF 74 (San Francisco)

Timeframe IETF 73 (Minneapolis)

Timeframe IETF 72 (Dublin)

Timeframe IETF 71 (Philadelphia)

Timeframe IETF 70 (Vancouver)

Timeframe IETF 69 (Chicago)

Timeframe IETF 68 (Prague)

Timeframe IETF 67 (San Diego)

Timeframe IETF 66 (Montreal)

Timeframe IETF 65 (Dallas)