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

Timeframe IETF 88 (Vancouver)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 2359 UTC Monday, September 23, 2013. 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 teleconferece, ensuring that the Secretariat has all of the information to put the first draft of the agenda together on or before October 3.

Applications

General

rfcform (approved)

  • Long name and abbreviation: RFC Format Design Team update (rfcform)
  • Description, including whether the BoF is intended to form a WG or not: This will serve as a report out to the community and opportunity for discussion on the requirements for tool specifications for a revised RFC Format.
  • The responsible Area Director (AD): Jari Arkko
  • BoF Chairs (or the ADs as placeholders): Heather Flanagan, BoF chair
  • Number of people expected to attend: 75, + or - 25
  • Length of session (1, 1.5, 2, or 2.5 hours): 1 hour
  • Conflicts to avoid (whole Areas and/or WGs): No particular conflicts
  • Does it require WebEX? If so, why? No
  • Does it require Meetecho? If so, why? Yes, this is likely to be of interest of people unable to make it to the meeting, including Julian Reshke who is one of the design team members.
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.: rfc-interest@rfc-editor.org

igovupdate (approved)

  • Long name and abbreviation: igovupdate or icannupdate
  • Description, including whether the BoF is intended to form a WG or not: We have been talking about a BOF that would allow IETF to learn more about experiences and efforts from Internet-Governance work at ICANN where it has potentially interesting information for us on the protocol side, e.g., gTLD program experiences, the policy aspects of WHOIS/Weirds, etc. This is for sure not WG-forming, but should it be within APPSAWG, an IAB BOF, a regular non-WG forming BOF? An alternative way to think about the BOF would be to have an opportunity to talk about Internet Governance related topics, WHOIS and TLDs just being some examples.
  • The responsible Area Director (AD): TBD (APPS ADs? GEN AD?)
  • BoF Chairs (or the ADs as placeholders): TBD
  • Number of people expected to attend: TBD
  • Length of session (1, 1.5, 2, or 2.5 hours): TBD
  • Conflicts to avoid (whole Areas and/or WGs): TBD
  • Does it require WebEX? If so, why?: No
  • Does it require Meetecho? If so, why?: No
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.: TBD

Internet

6lo (approved)

  • Long name and abbreviation: IPv6 over networks of resource-constrained nodes (6lo)
  • Status: Placeholder, as it is hoped that this will be a WG at IETF-88
  • Description: This BoF will discuss a proposed working group that focuses on IP-over-foo standardization (adaptation layers) for constrained node networks, working closely with the INT area working groups and other IETF WGs focused on constrained node networks. It will be a WG-forming BoF.
  • Responsible Area Director: Brian Haberman
  • BoF Chairs: Ulrich Herberg, Samita Chakrabarti
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid (whole Areas and/or WGs)
    • First priority: 6man, homenet, 6tsch, dnssd, manet, v6ops, core, lwig, dice
    • Second priority: json, INT Area WGs, lmap, ippm, sdnrg
  • Does it require WebEX? No
  • Does it require Meetecho? No
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

dnssd (approved)

  • Long name and abbreviation: Extensions for Scalable DNS Service Discovery (dnssd)
  • Status: dnssd is currently under consideration for WG formation. This BoF request is a placeholder for a session at IETF 88 if the WG is created.
  • Description, including whether the BoF is intended to form a WG or not:
    : This BoF is a WG-forming BoF. The proposed WG will develop solutions to provide scalable DNS-SD services in multi=-link, routed networks as found in academic, enterprise, home network and mesh radio networks.
  • The responsible Area Director (AD): Ted Lemon
  • BoF Chairs (or the ADs as placeholders): Tim Chown (tjc@ecs.soton.ac.uk), Ralph Droms (rdroms@cisco.com)
  • Number of people expected to attend: 150
  • Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours
  • Conflicts to avoid (whole Areas and/or WGs):
    First priority: dnsop, v6ops, appsawg, homenet, 6man, dhc, 6lo, mboned, core, sdnrg
    Second priority: INT area WGs
  • Does it require WebEX? If so, why? No
  • Does it require Meetecho? If so, why? Yes, to enable remote participation by a couple of key participants
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc. Mailing list: mdnsext@ietf.org
    Archive: https://www.ietf.org/mailman/listinfo/mdnsext

Internet-drafts:

draft-cheshire-mdnsext-hybrid Hybrid Unicast/Multicast DNS-Based Service Discovery
draft-lynn-mdnsext-requirements Requirements for DNS-SD/mDNS Extensions

6tisch (approved)

  • Long name and abbreviation: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
  • Status: Placeholder, as it is hoped that this will be a WG at IETF-88
  • Description: This BoF will discuss a proposed working group that focuses on The Working Group will focus on enabling IPv6 over the TSCH mode of the IEEE802.15.4e standard working closely with the INT area working groups and other IETF WGs focused on constrained node networks. It will be a WG-forming BoF.
  • Responsible Area Director: Ted Lemon
  • BoF Chairs: Pascal Thubert, Thomas Watteyne
  • Number of people expected to attend: 100
  • Length of session: 1.5 hours
  • Conflicts to avoid (whole Areas and/or WGs)
    • First priority: 6lo, core, 6man
  • Does it require WebEX? Yes
  • Does it require Meetecho? No
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Internet-wide Geo-Networking (geonet) (WAS: Intelligent Transportation Systems (its)) (approved)

  • Description: This meeting intends to gather together a number of IETF participants with interest in TCP/IP protocols for vehicular communications. The goal will be to present recently submitted problem statement, requirements and scenarios drafts (MIP/DNS for vehicular, GeoNetworking? for Internet, older V2V scenarios on Vehicular Communications) as well as a generic solution for layering IPv6-straight-over-80211p. Following the presentations, a discussion will be needed to select the one single topic to work on in a potential Working Group.
  • Responsible AD: Ted Lemon
  • BoF Chairs, Alexandru Petrescu & TBD
  • Expected Attendance: Need 100. Past meetings' attendance varies. Depending on how things advance until Vancouver, one suggestion would be to hold a slot in the MANET WG (or other existing WG) unless the public ITS email list traffic grows significantly until then.
  • Length of session: 1 hour
  • CONFLICTS to avoid: DMM, 6MAN, 6lo, v6ops, MANET
  • Number of sessions: 1
  • Does it require WebEX? Yes, in the past meetings several people have expressed interest and shown skill in remote attendance. Many people do key work in this area although being able to physically attend only when on their respective continent. A remote participation tool is of utmost importance to involve people and to illustrate the size of interest.
  • Does it require Meetecho? Same as above. Meetecho can only improve the level of interaction closeness. Also it requires a good IETF chat room like with jabber.
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts
  • email list: ietf.org/mailman/listinfo/its
  • draft charter: see attached email, its-13.txt
  • relevant I-Ds: draft-liu-its-mobility-00.txt, draft-karagiannis-problem-statement-geonetworking-00, draft-petrescu-its-scenarios-reqs-02.txt, (ongoing draft-authors-ipv6-straight-over-80211p)

Operations and Management

RAI

Routing

SFC (approved)

SPRING (approved)

  • Name: Source Packet Routing in Networking (SPRING), formerly know as Stacked Tunnels for Source Routing (STATUS)
  • Status: Placeholder, as it is hoped that this will be a WG at IETF-88
  • Responsible AD: Stewart Bryant
  • Description:

This working groups will develop the use case, architecture, and in conjunction with other IETF WGs the protocol extensions necessary to support sourced based routing mechanisms.

This definition of work will be revised closer to the BoF to reflect the outcome of discussion on the Status list.

Security

PerPass? (approved)

  • Status: Approved
  • Long name and abbreviation: PerPass? - Handling Pervasive Monitoring in the IETF
  • Not WG-forming
  • Responsible AD: Stephen Farrell
  • Number of people expected to attend: Loads, say 400. (More surreptitiously;-)
  • Length of session: 2, or 2.5 hours
  • Conflicts to avoid (whole Areas and/or WGs): SEC sessions, area meetings
  • Does it require WebEX? No.
  • Does it require Meetecho? Yes please.
  • Mailing list: https://www.ietf.org/mailman/listinfo/perpass

The perpass BoF is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. The BOF is not intended to be a precursor to formation of a Working Group, but rather to (for example) discuss ways in which IETF protocols at any layer can be made more robust against pervasive passive monitoring. If subsequent protocol work is to be done in the IETF, that would likely happen in existing or new protocol-specific Working Groups.

Logistics note: The tech plenary will also discuss this topic, so this has to follow that but ideally with a session or overnight in between. This should also be before saag. This might need the biggest breakout we have.

SIESTA (not approved)

  • Long name and abbreviation: siesta - SessIon? layEr SecuriTy? Approach
  • WG forming
  • Responsible AD: Sean Turner
  • Number of people expected to attend: 50
  • Length of session: 1 hour
  • Conflicts to avoid (whole Areas and/or WGs): SEC area
  • Does it require WebEX? If so, why? Not sure yet.
  • Does it require Meetecho? If so, why? Not sure yet. Might be a good idea.
  • Mailing list: TBD

The present end-to-end application security context is tightly coupled with the underlying communication context. This is problematic for at least three reasons. First, it is not flexible: when the underlying communication context changes, the application security context must change, too. Second, in certain applications, the overhead associated with such coupling is prohivitively expensive over constrained networks (such as sensor- or cellular networks). Third, and probably most important, an attack on the communication context immediately effects the application security.

This BoFs? aims at starting the work on a solution to the above problems, with the objective of providing security context for an application, which is fully decoupled from the underlying communication methodology and is thus resilient to attacks on the communication context. With that, the security context may need to have basic understanding of the communication context to be efficient with datagram overhead and communication synchronization issues (such as sequence window management), and so it is desirable that solution supports the "hooks" into the underlying protocol .

A strawman for the approach to a solution will be presented at the BoF.

DICE (approved)

  • Status: Approved

This is a placeholder. A charter for this wg-to-be will be discussed by the IESG between the BoF call and the IETF meeting. https://datatracker.ietf.org/doc/charter-ietf-dice/

  • Responsible AD: Stephen Farrell
  • Number of people expected to attend: 50
  • Length of session: 1.5 hours
  • Conflicts to avoid (whole Areas and/or WGs): SEC area, #include <core-conflicts.h>

Transport

AQM (approved)

  • Name: AQM - Active Queue Management and Packet Scheduling
  • Status: Approved & announced as WG 2013-09-27
  • Responsible AD: Martin Stiemerling
  • Description:
    Internet routers, lower-layer switches, other middleboxes include buffers or queues to hold packets when they are not immediately able to be forwarded to the next hop.

The queues are intended to absorb bursts of traffic that may naturally occur, and avoid unnecessary losses. However, queues also cause latency and jitter in the eventual arrival times of packets. This can cause issues and complications for interactive applications.

Extremely large buffers have been noticed in some software and equipment. When these queues fill, interactive applications and other traffic can be severely impacted or completely broken, due to high and potentially oscillating delays.

The Active Queue Management and Packet Scheduling working group (AQM) is intended to work on algorithms for proactively managing queues in order to:

(1) help flow sources control their sending rates before the onset of necessary losses, e.g. through ECN

(2) help minimize delays for interactive applications

(3) help protect flows from negative impacts of other more aggressive or misbehaving flows

  • Responsible AD: Martin Stiemerling
  • BoF Chairs: Wed Eddy, Richard Scheffenegger
  • Type: WG forming
  • Number of people expected to attend: 100
  • Length of session: 1 hour
  • Conflicts to avoid: all TSV WGs, TSVAREA, and ICCRG
  • Does it require Webex: No
  • Does it require Meetecho: No
  • Links to the mailing list, draft charter, relevant I-Ds: