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

Timeframe IETF 93 (Prague)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 2359 UTC Friday, 2015-06-05. 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 2015-06-19.

Applications and Real-Time

Name: CAPtive PORTal interaction (CAPPORT) (Approved for IETF 93)

Description: Improve the interaction with captive portals. Captive portals are used in many locations (e.g coffeeshops, hotels). With a move to a more secure Internet, the interception techniques become increasingly problematic. The user experience also leaves much to be desired. This BoF seeks to understand if there is sufficient energy to work on the problem and design a protocol for interacting with captive portals.

Agenda [ To be filled in ]

Status: WG Forming

Responsible AD: Barry Leiba

BoF proponents: Warren Kumari (warren@kumari.net), Mark Nottingham (mnot@mnot.net)

BoF chairs: Warren Kumari (warren@kumari.net), Mark Nottingham (mnot@mnot.net) (proposed)

Number of people expected to attend: 100

Length of session: 1.5 hours (we are fine with longer, whatever works best for scheduling)

Conflicts to avoid: 1st: DANE, DPRIVE, OpsAWG (WK co-chairs these), httpbis 2nd: DNSOP, appawg

Does it require WebEX? No

Does it require Meetecho? Yes

Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Mailing List: ​https://www.ietf.org/mailman/listinfo/captive-portals

Other info: https://github.com/httpwg/wiki/wiki/Captive-Portals

Draft charter: TBD

[ Note: This is a proposed BoF - we are still determining if we sufficient interest to burn meeting time, but figured worth filling in the form now. We had a bar BoF in Dallas with significant interest. See: https://github.com/httpwg/wiki/wiki/Captive-Portals ]

PERC (Placeholder for WG-in-Formation) (Approved for IETF 93)

  • Name: Privacy Enhanced RTP Conferencing (PERC)
  • Description:

RTP-based real-time multi-party interactive media conferencing is in widespread use today. Many of the deployments use one or more centrally located media distribution devices that perform selective forwarding of mixed-media streams received from the participating endpoints. The media transport protocol commonly used is RTP (RFC3550). There are various signaling systems used to establish these multi-party conferences.

These conferences require security to ensure that the RTP media and related metadata of the conference is kept private and only available to the set of invited participants and other devices trusted by those participants with their media. At the same time, multi-party media conferences need source authentication and integrity checks to protect against modifications, insertions, and replay attacks. Media distribution devices supporting these conferences may also perform RTP header changes, and they often consume and create RTCP messages for efficient media handling.

This WG will work on a solution that enables centralized SRTP-based conferencing, where the central device distributing the media is not required to be trusted with the keys to decrypt the participants’ media. The media must be kept confidential and authenticated between an originating endpoint and the explicitly allowed receiving endpoints or other devices. Further, it is desired that a solution still provides replay protection, so that the media distribution devices can’t replay previous parts of the media.

  • Agenda: TBD
  • Status: WG Forming (Placeholder for WG-in-formation)
  • Responsible AD: Ben Campbell
  • BoF proponents: Magnus Westerlund (magnus.westerlund@ericsson.com)
  • BoF chairs: Richard Barnes (rlb@ipv.sx), Suhas Nandakumar (suhasietf@gmail.com)
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid:
  • Does it require WebEX? No
  • Does it require Meetecho? Yes
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

MODERN (Placeholder for WG-in-Formation) (Approved for IETF 93)

  • Name: Managing, Ordering, Distributing, Exposing, & 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 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. Its use as a network locator is going away, but 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.

The TeRQ proposal (effectively an ENUM replacement) was previously submitted to the DISPATCH process in the RAI Area and given a favorable reception. This charter continues that work but considers a broader set of problems than TeRQ, including systems for acquiring telephone numbers and looking up metadata associated with telephone numbers. It will also draw on the work that has been done in STIR since TeRQ was proposed to add a strong security dimension to number management on the Internet.

  • Agenda: TBD


EDUNEXT (Approved for IETF 93)

  • Name: Education and Mentoring Next Generation (EDUNEXT)
  • Description: We are looking for input on the future direction of the IETF education (http://www.ietf.org/edu/) and mentoring (https://www.ietf.org/resources/mentoring-program.html) activities.
  • Agenda: http://www.arkko.com/ietf/edu/edung.txt
  • Status: Not WG forming
  • Responsible AD: Jari Arkko
  • BoF proponents: Mirjam Kuehne, Jari Arkko
  • BoF chairs: Mirjam Kuehne, Dan Romascanu
  • Number of people expected to attend: 50
  • Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): Area Meetings, LMAP, SACM, XRBLOCK, I2NSF BOF (if approved), SUPA BOF (if approved)
  • Does it require WebEX? No
  • Does it require Meetecho? Yes
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.


Operations and Management

SUPA (Approved for IETF 93)

  • Name: Simplified Use of Policy Abstractions (SUPA)
  • Description:

SUPA (Simplified Use of Policy Abstractions) is defining an interface to a network management function that takes high-level, possibly network-wide policies as input and creates element configurations snippets as output.

SUPA will define a generic policy information model (GPIM) for use in network operations and management applications. The GPIM can represent different types of policy rules for controlling managed entities throughout the service development and deployment lifecycle. The GPIM will be translated into corresponding YANG data models to define interoperable implementations that can exchange and modify generic policies using protocols such as NETCONF/RESTCONF.

SUPA defines a vendor-neutral mechanism to express management policies that control configuration of network elements. Management policies can be interpreted outside of network elements, and the interpretation typically results in configuration changes of collections of network elements.


Name: Deterministic Networking (detnet) (Approved for IETF 93)


Operational Technology (OT) refers to industrial networks that are typically used for monitoring systems and supporting control loops, as well as movement detection systems for use in process control (i.e., continuous manufacturing) and factory automation (i.e., discrete manufacturing). Due to its different goals, OT has evolved in parallel but in a manner that is radically different from Information Technology/Information? and Communications Technology (IT/ICT), focusing on highly secure, reliable and deterministic networks, with limited scalability over a bounded area.

In parallel, the wide application scope for deterministic networks has led to the IEEE 802.1 Audio/Video Task Group becoming the Time-Sensitive Networking (TSN) Task Group (TG), covering industrial and vehicular applications in addition to professional Audio. The networks in consideration are extending beyond the LAN boundaries and require secure deterministic forwarding and connectivity over a Layer 2/Layer 3 network. The properties of deterministic networks will have specific requirements for the use of routed networks to support these applications.

The deterministic networking Working Group (detnet) would consider the establishment and maintenance of deterministic paths over Layer-2 Bridged and Layer-3 routed segments, focusing on Layer 3 aspects in support of deterministic applications. The Working Group would specify an overall architecture that encompasses the data plane, OAM, management, control, and security aspects that are required to enable a complex multi-hop path including packet redundancy capabilities, and forwarding along that path, with the deterministic properties of controlled latency, low packet loss, ultra-low jitter, and high reliability.

  • Agenda:
    • BoF Introduction & meeting logistics 10 min
    • User's View 35 min
      • Answering the following:
        1. What is your application?
        2. How do you support the application today?
        3. What do you want to differently in the future?
        4. What would you like the IETF to deliver? (may be combined with 3)
    • DetNet Problem Statement 30 min
    • Working group scope and deliverables discussion 35 min
    • Concluding WG forming BoF discussion 10 min

Status: WG Forming



BoF proponents: Jouni Korhonen <jouni.korhonen@broadcom.com>, Pascal Thubert <pthubert@cisco.com>


Number of people expected to attend: 150

Length of session: 2 hours

Conflicts to avoid: 6TiSCH, PCE, TEAS, CCAMP, NVO3, TSVWG, 6MAN, DTN

Does it require WebEX? Yes

Does it require Meetecho? Yes

Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.


Name: SDN Authentication and (high level) Authorization (SDNAuth)(Not approved for IETF 93)

Description: Authentication and authorization are both critical enablers on any Software Defined Networking (SDN) [1,2] solutions. This is because, before two SDN components (e.g. an application, an SDN switch, a SDN router, etc.) want to communicate to a SDN controller, they need to be authenticated and authorized. This process will avoid the propagation of attacks on the whole SDN based infrastructure by preventing unauthenticated and unauthorized access to a centralized SDN controller and as a result to the network devices. The existing authentication scheme used in SDN solution is based on TLS certificates. The problem with the use of self-signed certificates is the spoofing attack at the beginning of the TLS establishments. In case the certificates are introduced to both SDN components, the problem is key management and scalability of such solution. The use of the existing public CA solves the scalability and key management problem but this approach doesn’t fit to the nature of a SDN solution. This is because, if the private key of a CA is compromised, then it might affect all SDN based infrastructure that has their certificates signed by the compromised CA which may result in serious damages on the operators’ networks. One solution would be the use of local PKI models. This solution will reduce the range of attacks to a limited scope such as only one operator but cannot completely eliminate such attacks. Therefore, improving the authentication model of SDN components and reduce the range of attacks as much as possible is demanding and this is what this group wants to address.

Furthermore, an operator might have distributed SDN controllers (each does different task) in different data centers that these SDN controllers belong to a vendor or there might be a case where an operator received its service from different vendors but wants to have overall information about its network. There might be also a case where SDN controllers belong to multi-operators. Therefore, the communications of these SDN controllers is one of the requirements for such distributed networks. At the moment, there is a lack of standard communication protocols for the communication of two SDN controllers for exchanging topology information or any other information which is demanding. Since the security of a SDN controller is really important. Having a single point of communication to a SDN controller reduces the range of attacks on a SDN controller. Therefore, the mediator service can be used to handle these communications among SDN controllers together and applications to SDN controllers. Since there is no standard model for this communication, this group also addresses this requirement by introducing new standard model and standard structure for the communications of SDN controller and application via this mediator service. One important use case scenario that requires the communication of different SDN controllers in multi-domain multi-operator environment is that a seamless user authentication for WiFi? scenarios (especially during user movements from one operator’s domain to another operator’s domain). At the moment EAP is a protocol in use for submitting user authentication and RADIUS is a protocol for authenticating and authorizing users. But, to provide a user with similar access control in its visited network as it had in its home network (the network that this user established its communication for the first time or is a customer) requires two much administrative works. For example, to open VoIP port on switches and firewalls where by default it is closed. A SDN controller can reduce this administrative works easily. However, there need to be a standard model for handling this scenario so that all operators can follow it and with fewer efforts provide such possibilities for a user especially by considering a RADIUS service as an application (in application plane) in a SDN solution. Therefore a standard structure for submitting an user information to this RADIUS application via this mediator service is what this group addresses. The above scenario was an example of data (in a form of protocols) that needs to be exchanged among two SDN controllers in multi-domain networks.

SDNAuth will standardize a group of protocols to address the unique challenges of SDN.

Summary of the scope of SDNAuth

  • Standard structures for the communications of SDN controllers via a mediator service or communications of applications (e.g. user authenticator application) to a SDN controller via this mediator service
  • An improved authentication model for SDN based solutions.
  • This group might use some of the existing protocols such as EAP, RADIUS, DNS, etc.

The tasks and milestone of this group includes:

1) Produce the completed version of problem statement, requirements and use cases: August 2015 2) Gap analysis of this work with the existing work in open source standards, and other WGs at IETF: October 2015 3) Identify the solution scopes for replacement of PKI model for SDN solution in mutli-tenant environment: November 2015 4) Identify the solution scopes for a standard model for the communication of SDN controllers via a mediator service: March 2016


  • Introduction of SDNAuth BOF (Chairs, 10 min)
  • Problem statement and Use cases (15 min)
  • Gap analysis
  • Potential solutions
    • Improved PKI model for SDN sotlutions
    • A structure model for communications of SDN controllers via a mediator service
  • Charter Scope
  • Questions

BoF Proponents: Hosnieh Rafiee, Alexandre Petrescu, Mike Geller (this list is being updated...)

Status: BoF request to form a WG (had a Bar BoF in Dallas)

Responsible AD: Kathleen Moriarty

BoF chairs: TBD

Number of people expected to attend: 40

Length of session: 2 hours

Conflicts to avoid: SAAS, NFVRG, SDNRG, SUPA, I2NFS, NVO3

Does it require WebEX? No

Does it require Meetecho? Yes

Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Name: Openpgp - placeholder for WG-in-formation (Approved for IETF 93)

Name: Automated Certificate Management Environment (ACME) (Approved for IETF 93)

Description: Discussion of work that is going on with automated certificate management, following on to the BoF session in Dallas and the mailing list discussion since then.


Status: WG Forming

Responsible AD: Kathleen Moriarty

BoF proponents: Ted Hardie <ted.ietf@gmail.com>, Rich Salz <rsalz@akamai.com>

BoF chairs: Ted Hardie, Rich Salz

Number of people expected to attend: 100

Length of session: 2 hours

Conflicts to avoid: Security Area, RTCWEB, webpush, httpbis

Does it require WebEX? No

Does it require Meetecho? Yes

Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Name: Interface to Network Security Functions (I2NSF) (Approved for IETF 93)


In a nutshell, I2NSF wants to define interfaces to the flow based network security functions hosted by service providers at different premises.

Network security functions (NSFs) are provided and consumed in increasingly diverse environments. Users of NSFs could consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. Likewise, service providers of NSFs may offer their customers network security services that consist of multiple security products and/or functions from different vendors. NSFs may be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monitor, and control security policies that govern the behavior of NSFs, it becomes virtually impossible for security service providers to automate their service offerings that utilize different security functions from multiple vendors.

The primary goal of I2NSF is to define an information model, a set of software interfaces and data models for controlling and monitoring aspects of NSFs (both physical and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Controlling and monitoring of NSFs should include the use of policies to specify, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and functions on their devices, I2NSF will focus on flow based NSFs that provide treatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection, or pattern matching and remediation.


  • Introduction of I2NSF BOF (Chairs, 10 min)
  • Merged Use cases (10 min)
  • problem space (10 min)
  • Gap analysis, especially to answer questions like:
    • Is it within IETF scope & expertise? (why not OpenStack?, security alliance . .)
    • Why need a new WG? (why not done at SACM, I2RS, NETCONF, NETMOD, SFC, ANIMA, PCP, . . .?)
  • Potential solutions
    • Framework For Interfaces To NSFs
    • Capability interface Information model
  • Charter Bashing: https://sites.google.com/site/interface2nsf/home
  • Hard Questions

Status: WG Forming

Responsible AD: Kathleen Moriarty

BoF proponents: Diego Lopez diego.r.lopez@telefonica.com, Christian Jacquenet christian.jacquenet@orange.com, Myo Zarny Myo.Zarny@gs.com, Shaibal Chakrabarty shaibalc@us-ignite.org, Linda Dunbar linda.dunbar@huawei.com

BoF chairs: Dan Romascanu, Joe Salowey

Number of people expected to attend: 60

Length of session: 2 hours

Conflicts to avoid: SACM, SAAS, nfvrg, I2RS, IDR, SDNrg, TRILL, LMAP, XRBLOCK, SUPA, SFC, NVO3, SUPA BoF (if approved), Detnet BoF (if approved)

Does it require WebEX? No

Does it require Meetecho? Yes

Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.


  • Name: DDoS Open Threat Signaling (DOTS)(Approved for IETF 93)
  • Description:

The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards based approach for the realtime signaling of DDoS related telemetry and threat handling requests and data between elements concerned with DDoS attack detection, classification, traceback and mitigation.

On-premise DDoS mitigation devices are sophisticated entities which may already identify, profile and mitigate a wide range of attacks. Although flow export, syslog and SNMP are currently used by service providers and operators 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.

  • Agenda: TBD
  • Status: WG Forming
  • Responsible AD: Kathleen Moriarty
  • BoF proponents: Nik Teague nteague@verisign.com
  • BoF Chairs: Russ Housley (TBC) & Roman Danyliw
  • Number of people expected to attend: 150
  • Length of session: 2hours
  • Conflicts to avoid: IPFIX, MILE, SACM, I2NSF, SAAG, OPSAWG, OPSAREA
  • Does it require WebEx??: No, meetecho is enough
  • Does it require Meetecho?: Yes for remote attendees
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts etc.:

Mailing-list: https://www.ietf.org/mailman/listinfo/dots
Draft-charter: http://www.ietf.org/mail-archive/web/dots/current/msg00140.html
Relevant drafts:


IAB Sessions