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

Timeframe IETF 95 (Buenos Aires)

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

Applications and Real-Time


  • Name: IAOC Meeting Venue Selection Criteria & Procedures (mtgvenue)
  • Description: The IETF has expressed concern regarding the process followed when selecting a meeting venue. The IAOC and IAOC Meetings Committee have undertaken to document that process, which has been posted at an IAOC-private site for some time and is being updated, in an internet draft for community discussion. We would like to discuss it with the community.
  • Chair(s) Name(s) and e-mail address(es): Fred Baker <fred.baker@cisco.com>
  • Agenda: Presentation and discussion with the community of the criteria and procedures for selection of IETF meeting venues by the IAOC.
  • Conflicts to avoid: v6ops opsec softwire homenet pcp sunset4 6man aqm dnsop isis opsawg ospf tsvwg dots, after plenary
  • Expected Attendance: 200
  • Special requests: MeetEcho?, with the possibility of both remote listening and speaking, and slide projector
  • Number of sessions: 1
  • Length of sessions: 1 hour


  • Name: Low-Power Wide Area Networks (LPWAN)
  • Description: Low-Power Wide Area Networks (LPWAN) are long range Lowpower Lossy Networks, many of which operating in license-exempt bands. LPWANs provide low-rate connectivity to vast numbers of battery-powered devices over distances that may span tens of miles. Existing pilot deployments have shown the huge potential and met industrial interest, but the loose coupling with the Internet makes the device management and network operation complex and implementation specific. As of today, there is little to no use of IETF technologies in LPWANs at large, and there is a need to evaluate their applicability.
  • Agenda
    • Discussion: Better characterization of a LPWAN. Identify target technologies
    • Discussion: Applicability and gap analysis of Internet protocols
      • IP challenges and non-IP wireless I/O models
      • Latency and transport: applicability and problems with existing models
      • exchange model: Is REST the right approach?
      • AAA model

  • Name: Alternative Resolution Contexts for Internet Naming (ARCING)
  • Description: RFC 819 described Internet names as a set of directed graphs in an absolute naming context. While that work eventually lead into the creation of the domain name system, it is important to note that it does not imply that there will be a single resolution system for Internet names. While the most common Internet names by far are those which are part of the domain name system, that set of names is not the whole. A number of independent naming and resolution contexts have emerged. In addition to those created for onion routing and multicast DNS, there are large sets associated with the Handle system, URNs, and Internet scale proprietary names (e.g. twitter handles).

It is apparent that the desire to re-use Internet protocols that default to DNS-based resolution in other resolution contexts has created ambiguities in what resolution context should be used for individual names. Those ambiguities may be expressed in operational difficulties (queries in the wrong context) and in concerns about limitations implied for DNS-based names.

The proponent believe that the IETF should describe the architectural issue and document best practices for identifying alternative resolution contexts. Among those best practices might be the creation of a registry that associates specific resolution contexts with the method they have chosen to use for identification. We note that discussions have been ongoing on related topics within the DNSOP WG, but we believe that a broader community is required to discuss and resolve the issue.

  • Agenda
    • Problem statement
    • Alternatives methods for identifying resolution context within existing protocols
    • Registration methods
      • Outside the DNS
      • Within a DNS-subtree
      • Using DNS syntax
      • Discussion
  • Status: non-WG-forming
  • Mailing list: arcing@ietf.org
  • Responsible AD: Brian Haberman
  • BoF proponents: Ted Hardie, Andrew Sullivan, Suzanne Woolf
  • BoF chairs: Suzanne Woolf (suzworldwide@gmail.com) and Joe Hildebrand (jhildebr@cisco.com)
  • Number of attendees: 100
  • Length of session: 2 or 2.5 hours

  • Name: Intelligent Transportation Systems (ITS)
  • Description: The goal of this group is to standardize and/or profile IP protocols for establishing direct and secure connectivity between moving networks.

We concentrate on 1-hop moving network to nearby moving network communications. This has immediate applicability in mobility environments such as vehicle-to-vehicle or to-infrastructure communications, or PAN-to-homenet, or train-to-vehicle at intersection. In some of the moving network applications the window of opportunity for exchanging data with the immediate infrastructure may be very short. The safety and security requirements are higher in connected mobility environments. The links are very heterogeneous such as: 802.11p/ac/ad OCB, Infra-red, VLC, cellular, 802.15.4 and more.

The activity may leverage protocols elsewhere at IETF such as 6lo protocols for short-range low-power mobile, homenet, MANET for n-hop topologies, Mobile IP, DNS configuration, Neighbor Discovery and DHCP Prefix Delegation.

The BoF gathers implementers, users and experts from academia, institutes, IT and automotive industry, and public authorities. Strong relationships with SDOs: ETSI TC ITS, IEEE P1609, 802 and Category A liaison with ISO TC204 "Intelligent Transport Systems".

  • Agenda
    • tutorial of IP in vehicular communications - 20min Alex Petrescu
    • ITS use-cases C-ACC and Platooning - 10min draft-petrescu-its-cacc-sdo-04.txt Alex Petrescu
    • ITS V2I problem statement - 5min draft-jeong-its-v2i-problem-statement-00 Jaehoon Paul Jong
    • ITS V2V problem statement - 5min draft-petrescu-its-problem-00.txt Dapeng Liu
    • ISO TC204 needs - 10min Alex Petrescu
    • Other SDO needs of V2V and V2I: ETSI, SAE, 3GPP, ITU - 10min Alex Petrescu
    • Mobility requirements in connected rail deployments - 5min Sri Gundavelli
    • Charter proposal - 10min Alex Petrescu
  • Discussion - 45min

Operations and Management


  • Name: Babel routing protocol
  • Description: Babel is a loop-avoiding distance vector protocol that has good provisions for dynamically computed metrics and remains robust even in the presence of metric oscillations and failure of transitivity. Babel has seen some production deployment, notably in hybrid networks (networks that combine classical, wired parts with meshy bits) and in global overlay networks (networks built out of large numbers of tunnels spanning continents). Babel is also considered as part of the IETF Homenet protocol stack. There exist three independent implementations of Babel, all of which are open source.

The core of the Babel protocol is described in detail in RFCs 6126 and 7557, which are both Experimental. While these RFCs have been useful (as indicated by the independent reimplementations of Babel), a number of parties have expressed a desire to have a new specification, which would clarify RFC 6126 according to the feedback provided by the independent reimplementations and integrate the contents of RFC 7557 without expanding the scope of Babel.

The goal of this BoF is to discuss the value and scope of the work required to create a standards track successor to RFCs 6126 and 7557, including discussing what technical topics need attention as part of advancement. The BoF will also discuss the applicability of Babel, in preparation for the working group producing a suitable applicability statement. The working group, when formed, will be responsible for evaluating the costs and benefits of changes to the existing work on Babel, as well as developing suitable security mechanisms. Implementation experience is helpful both for the BoF and the working group.


  • Name: Limited Use of Remote Keys (lurk)
  • Status: Non wg-forming, but if it goes well, we may follow up and charter before Berlin
  • Description: HTTPS in typical use authenticates the server by proving ownership of a private key, which is associated with a public-key certificate. Currently most trust models assume private keys are associated and owned by the HTTP server, and that the server is responsible for both the hosted content and for the network delivery. Although these assumptions were largely true in the past, today, the deployment of services on the current Internet largely relies on multiple distributed instances of the service. Similarly, the delivery of popular content often splits the roles of providing the content and delivering the content. In such architectures, the application - like a web browser - expects to authenticate a content provider but is actually authenticating the node delivering the content. In this case, the confusion mostly results from using a secure transport layer to authenticate application layer content.
  • List discussion has established that there is interest in dealing with the "offload TLS without giving the CDN my private key" use-case, with some list participants proposing to also support DTLS in anticipation of future secure protocols. Hopefully the BoF session will help to clarify if other use-cases also need to be tackled, and with establishing if there is sufficient interest to tackle work in this space.
  • Responsible Area Director: Stephen Farrell
  • BoF Chairs: Yaron Sheffer, Eric Burger
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid:rtcweb, SEC, httpbis, STIR, MODERN, MILE, and Thursday or Friday (MUST be on Monday - Wednesday)
  • Mailing list:
  • Drafts (note: the list has not yet had detailed discussion of these):


  • Name: Alternatives to Content Classification for Operator Resource Deployment (ACCORD)
  • Description: Mobile Radio Access Networks (RANs) have historically allowed content-type based classification to associate service descriptions with flows, with the goal of efficient use of the often volatile radio bearer. The increased use of TLS and other encrypted transports eliminates this metadata from the view of the operator and forces a re-examination of this method.

While having endpoints expose classification of this and other metadata to the RAN outside the encrypted channel would restore this, it would degrade the confidentiality expected and require extensive coordination among application developers, user endpoint manufacturers and RAN operators. To avoid the disadvantages of that approach, we wish to examine both what specific network treatments need to be elicited for the efficient operation of RANs, if any, and what the minimal communication to elicit those treatments would be.

  • Agenda
    • Review of current 3GPP architectural use of content-based​ classification for radio resource allocation
    • Alternatives for current or future architectures:
    • Zero-bit AQM alternative
    • 1 bit alternative signal
    • Delay, throughput, and reliability, hmm, haven’t we seen that before? RFC 791 TOS bits refresher.
    • Modern DSCP marking
    • Discussion
  • Status: not WG forming
  • Mailing list: accord@ietf.org
  • Responsible AD: Spencer Dawkins
  • BoF proponents: Ted Hardie, Brian Trammell, Joe Hildebrand
  • BoF chairs: Gonzalo Camarillo, Pete Resnick
  • Number of attendees: 150
  • Length of session: 2 or 2.5 hours
  • Conflicts: Transport Area, SAAG, RTCWEB, ACME, MAPRG, TCPINC, CDNi, NFVRG​, DISPATCH​

IAB Sessions