* 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 https://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)
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Template for BOF Entry - Please do not edit the BoF Example Page directly.

Timeframe IETF 106 (Singapore)

The current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 23:59 UTC Friday, 2019-10-04. 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 2019-10-11.

Approved for IETF 106

Applications and Real-Time

ABCD

Long name: Application Behavior Considering DNS

Abbreviation: abcd

Description:
See charter proposal below.

Status: WG Forming

Responsible Area Director (AD): Barry Leiba

BoF Chairs (or the ADs as placeholders): TBD

BoF Proponents: Barry Leiba, Warren Kumari, Éric Vyncke, Alissa Cooper, Jari Arkko

Number of people expected to attend: 200

Length of session (1, 1.5, 2, or 2.5 hours): 2 hours

Conflicts to avoid (whole Areas and/or WGs): ART Area, DNSOP, DPRIVE

Rough Draft Agenda: TBD

Mailing list: https://www.ietf.org/mailman/listinfo/add

Draft charter:

Application Behavior Considering DNS (ABCD)

DNS over TLS (DoT) [RFC 7858], DNS over DTLS [RFC 8094], and DNS over
HTTPS (DoH) [RFC 8484] provide confidentiality and tamper-resistance to
thwart on-path attacks against DNS queries flowing between clients and
recursive resolvers. Along with the deployment of these new transports,
various application providers have been exploring having the application
configure its own DNS services rather than using DNS services configured
by the network operator. (The working group considers a network operator
to include Internet service providers, enterprises, and any businesses
that provide network access.) Together, these developments may represent
a set of shifts depending on how the new protocols are deployed: from
cleartext to encrypted transports; from use of unique port numbers for
DNS resolution to ports that support significant other traffic (e.g.,
HTTPS); from network operator control of DNS configuration to control by
clients, third-party resolvers, or others; and from the use of a large,
dispersed set of network operator resolvers to a smaller set of more
centralized resolvers operated by other parties.

This potential set of shifts raises questions about the actual impacts on
user privacy (both positive and negative) and might change the pervasive
surveillance situation, given the changed set of actors that are capable
of seeing the users’ queries.  The shifts also raise other questions
given the long history and current status of DNS operational practices.
Network operators have historically used DNS services for a variety of
purposes beyond simple query resolution: to mitigate network and security
threats, to enforce enterprise policy, to provide parental controls and
other filters, and to comply with relevant laws and regulations, among
others. Achieving these objectives while providing confidentiality and
tamper-resistance will generally require that network operators shift to
one of the available encrypted transports for their resolvers and that
clients include configuration options to select them. Given the historic
prevalence of unencrypted DNS transport, supporting that transition may
require specifying protocols, guidance, and best practices. This working
group will be the locus of that work, focusing on work items that support
the smooth operation of encrypted DNS transports across diverse networks
with potentially diverse and changing arrangements concerning where the
control of DNS service configuration is located.

Specific initial areas of focus include:

- Resolver discovery
- Expression of resolver policy
- Query routing in the presence of resolver choice
- Best Current Practices for the deployment and operation of encrypted
  DNS transport, including:
     - recommendations on detailed protocol usage
     - best practices for running a DNS service with encrypted transport
     - guidelines for deployment models that minimize issues with pervasive
       monitoring, commercial use of DNS data, and other privacy concerns

This working group will coordinate with the DNSOP (OPS Area), DPRIVE (INT
Area), and DOH (ART area) working groups, and all last-call announcements
(including Working Group Last Calls issued by the chairs) will be copied
to all four working groups to ensure thorough and careful review. The
working group will also coordinate with the SEC Area, and will be
assigned a security advisor.

WPACK

Long name: Web Packaging

Abbreviation: wpack

Description:
Today's websites rely on multiple resources. If a user visits https://www.bbc.co.uk/ they will need to fetch about 300 resources to view the whole page. The HTML page they download at http://www.bbc.co.uk/ contains references to stylesheets, scripts, images and other files, each of which may contain references to further files themselves. Many of these resources will themselves have been originally developed as separate resources and merged to improve performance: CSS and Javascript files are concatenated together; images are merged and used with CSS spriting. This could be more efficient if the client could see the original structure of the merged resources.

Users should have a way to save and share these multi-resource websites and web apps as a single comprehensible unit that's more efficient and safe than MHTML. If the original origin cooperates, the recipients should be able to determine that the content wasn't modified and execute the content in the context of its original origin.

Using the above ability, users with very expensive or sometimes-absent data connections should be able to use web content without using that data connection, if they have a peer-to-peer route back to the web.

Caches like AMP's should show the right URLs.

This BoF proposes that the IETF charter a working group to:

  • Define a packaging format for HTTP resources.
  • Study and document how origin trust and object-based security affect the security and privacy models of the web.
  • Define a way to sign package contents, and maybe arbitrary HTTP responses, as an origin, and document the risks and mitigations. If possible, allow signing as other sorts of authorities as well.

Status: WG Forming

Responsible Area Director (AD): Alexey Melnikov

BoF Chairs (or the ADs as placeholders): TBD

BoF Proponents: Jeffrey Yasskin <jyasskin@google.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): HTTPBIS, QUIC, DISPATCH, SECDISPATCH, SAAG, TLS, ACME, Monday morning

Rough Draft Agenda

  1. 10min Introduction — Chairs
  2. Use cases:
    1. 10min Community Networking Use Cases — Spencer Sevilla
    2. 10min Pre-installed websites — speaker TBD
    3. 10min AMP — speaker TBD
    4. 10min Resource combining, e.g. JS modules — speaker+detailed topic TBD
  3. 15min Charter review — Chairs
  4. 40min Charter Discussion — BoF attendees
  5. 15min Polls — Chairs

Mailing list: https://www.ietf.org/mailman/listinfo/wpack

Draft charter: https://trac.tools.ietf.org/bof/trac/wiki/WPACK

Related Internet-Drafts:

Protocols or practices that already exist in this space: Lots of Javascript bundlers exist to concatenate JS modules and embed CSS and images in that Javascript, including Webpack, Parcel.js, and Rollup. MHTML is a streamable package of HTTP resources in a text file. ZIP is a random-access package of files.

Modifications to existing protocols or practices: draft-yasskin-http-origin-signed-responses suggests an HTTP header to provide signatures.

Entirely new protocols or practices: draft-yasskin-wpack-bundled-exchanges suggests an entirely new format for random-access and streamable packages of HTTP resources.

Open source implementations: Chromium has an implementation of a preliminary version of origin-signed resources, which is being used by Google Search and the Google AMP Cache. Chromium is also working on an implementation of bundles.

WEBTRANS

Long Name: WebTransport

Abbreviation: webtrans

Description: WebTransport complements WebSocket by providing Web applications access to better performing network communications allowed by modern protocols such as HTTP/3 and QUIC. WebTransport provides a mechanism for reliable and unreliable bidirectional client-server transmission of data in a way that provides security guarantees and fits into the Web security model. There is interest in the W3C to make a WebTransport API available to the Web, the potential new WEBTRANS IETF Working Group would define the protocols and protocol extensions underlying this new Web API.

This is a NON-working-group-forming BoF.

Responsible Area Directors: ART area ADs

BoF Proponents:

Number of people expected to attend: 100

Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours

Conflicts to avoid: quic httpbis core tls dnssd tsvarea taps ice

Links:

Relevant Internet Drafts:

Protocols or practices that already exist in this space: WebSocket (RFC 6455) -- WebTransport intends to compliment what WebSocket did for QUIC and other transport protocols More related work described in https://tools.ietf.org/html/draft-vvv-webtransport-overview-00#section-1.1

Modifications to existing protocols or practices: The plan is to define extensions to QUIC and HTTP/3. The proposed extensions are described in draft-vvv-webtransport-quic and draft-vvv-webtransport-http3, respectively.

Entirely new protocols or practices: draft-vvv-webtransport-quic defines a new application-level protocol on top of QUIC. The proposed working group would have to design a TCP-based fallback protocol with QUIC-compatible semantics, for cases where UDP is blocked.

Open source implementations: Chromium is currently implementing a client Google QUIC library will support both client and server

General

GENDISPATCH (placeholder)

  • Name: General Area Dispatch (GENDISPATCH)
  • Description: DISPATCH-style working group (see RFC 7957) proposed to consider proposals for new work in the GEN area. This is a placeholder BOF; a proposed charter for a WG is already in the system.
  • Status: WG Forming
  • Responsible AD: Alissa Cooper
  • BoF proponents: Alissa Cooper
  • BoF chairs: Francesca Palombini <francesca.palombini@ericsson.com>, Pete Resnick <resnick@episteme.net>
  • Number of people expected to attend: 75
  • Length of session (1, 1.5, 2, or 2.5 hours): 1 hour
  • Conflicts to avoid (whole Areas and/or WGs): ART Area, GEN Area, cbor, ace, core, lake, quic, all BoFs?, dprive, anima, opsawg, spring, tls

Internet

TM-RID

  • Name: Trustworthy Multipurpose Remote ID
  • Description: Amend HIP to support TM-RID for UAS (Unmanned Aircraft Systems)
  • Status: WG Rechartering
  • Responsible AD: Eric Vyncke
  • BoF proponents: Robert Moskowitz, Stewart Card, Adam Wiethuechter
  • BoF chairs: Gonzalo Camarillo
  • Number of people expected to attend: 30
  • Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours
  • Conflicts to avoid (whole Areas and/or WGs):
    • Eric Vyncke & Benjamin Kaduk attend
    • cfrg, saag, ipsecme, rats, anima, t2trg, cose
  • Rough Draft Agenda
    1. 5 min Agenda bashing — Chairs
    2. 10 min UAS background (RemoteID, NetworkID, and Command & Control) - Stu Card
    3. 10 min UAS/HIP use case - Stu Card
    4. 10 min Hierarchical HITs and HIT Registries - Bob Moskowitz
    5. 5 min New Crypto in HIP (and new ESP Transform: Diet-ESP and Keyak cipher) - Bob Moskowitz
    6. 10 min RemoteID HIP Authenticated Messages - Adam Wiethuechter
    7. 5 min Hackathon report - Stu Card
    8. 15min Charter review — Chairs
    9. 15min Charter Discussion — BoF attendees
    10. 5 min Next steps — Chairs

Governmental agencies worldwide, including the United States Federal Aviation Administration (FAA), are embarking on rule making processes to define Remote Identification (RID) requirements for Unmanned Aircraft Systems (UAS). ASTM International (formerly the American Society for Testing and Materials) F38 Committee Work Item WK65041, “Standard Specification for UAS Remote ID and Tracking”, addresses such anticipated requirements. Broadcast RID defines a set of messages for UAS to send one-way over Bluetooth or IEEE 802.11. Network RID defines how the same information (and potentially more) can be made available via the Internet. The ASTM draft does not address how to ensure or at least assess trustworthiness of information communicated via RID.

The Host Identity Protocol (HIP) Host Identity Tag (HIT) is ideally suited to work within this RID effort. For each Unmanned Aircraft (UA), a HIT can consolidate the 4-tuple of (UA ID, UA physical location, UA onboard host ID, UA onboard host logical location [IP address list]) to a 3-tuple (HIT, UA physical location, UA onboard host logical location) and thereby provide significant benefits.

For HIP to be used effectively in this environment, it needs updates.

  • Hierarchical HITs (HHIT) enabling scalable and trustable registration: HHIT was part of the original design of HIP, but was dropped for lack of a clear use case. RID messages containing HHITs will enable use of DNS to access information about the UAS.
  • expanded HIP Registration for HHITs: This registration process will provide proof of authenticity and prevent duplicate HHITs from occurring. Further, these Registries will provide the UAS DNS information and other services (including support of RVS for Network RID and related applications).
  • new cryptographic algorithms: Extremely compact keys and signatures (such as are enabled by EdDSA and Keccak functions) are needed to meet the severely constrained UAS environment.

Additionally, tm-rid will offer specifications for HIP-augmented ASTM RID messages. Initially this will consist of additional RID Authentication Messages that use the HI in public key signing operations: to prove UAS ownership of the HHIT; to authenticate other claims made via RID, such as position and velocity, as having been made by the owner of that HHIT; and to provide observers lacking current Internet connectivity with locally verifiable UAS proof-of-registration objects.

Further work will emerge as experience is gained in using HIP for UAS RID. For example, some UAS Traffic Management (UTM) systems envision using OAuth for Ground Control Systems (GCS) and authorized safety personnel. HIP as an OAuth method may help in merging HIP into these systems.

The goal is to complete these updates to HIP by the end of 2020.

Operations and Management

MOPS (placeholder)

  • Name: Media OPerationS
  • Description: This is a placeholder BoF - we may charter the WG before IETF106, but if not it will meet as a WG Forming BoF.
  • Status: WG Forming
  • Responsible AD: Warren Kumari
  • BoF proponents: Eric Vyncke
  • BoF chairs: Leslie Daigle <​ldaigle@thinkingcat.com>, Glenn Deen <​glenn.deen@nbcuni.com>
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): QUIC, CDNI, MBONED, PIM, RTCWEB, MMUSIC, HTTPBIS, DOH, TAPS, anything for which Eric is RAD.

Agenda: Finalizing the charter (below), getting started on work...

Internet- and Internet-protocol-delivered media is widespread, leading to significant technology development across industries not traditionally thought of as Internet technology developers or operators, as well as considerable quantities of traffic on local and transit networks. MOPS’ focus is on identifying areas where existing protocols and/or networks are challenged by these updated requirements.

MOPS will solicit input on operational issues and practices, existing and proposed technologies related to the deployment, engineering, and operation of media streaming and manipulation protocols and procedures in the global Internet, inter-domain and single domain networking. In this case, media is considered to include the transport of video, audio, objects and any combination thereof, possibly non-sequentially. The scope is media and media protocols’ interactions with the network, but not the technologies of control protocols or media formats.

The premise of MOPS is that continued development of Internet-using technologies should be properly coordinated in order to ensure that the existing technologies are well-utilized, and new ones are developed in sympathy with the Internet’s core protocols and design. MOPS acts as a clearinghouse to identify appropriate venues for further protocol development, where necessary.

MOPS goals include documenting existing protocol and operational issues with media on the Internet, and identifying requirements for potential IETF work.

To those ends, MOPS will:

1/ Solicit regular updates from other media technology developing consortia/standards bodies working with IETF-developed protocols.

2/ Solicit input from network operators and users to identify operational issues with media delivery in and across networks, and determine solutions or workarounds to those issues.

3/ Solicit discussion and documentation of the issues and opportunities in media acquisition and delivery, and of the resulting innovations developed outside the IETF

4/ Document operational requirements for media acquisition and delivery.

5/ Develop operational information to aid in operation of media technologies in the global Internet.

These activities should document media operational experience, including global Internet, inter-domain and within-domain operations.

Media operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the MOPS Working Group may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to MOPS operational and deployment problems.

Future work items within this scope will be adopted by the Working Group only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF.

There must be a continuous expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items.

Milestones:

  • Feb 2020 Draft of edge network operational considerations for streaming media (was Taxonomy of Issues in Internet Media)
  • Feb 2020 Initial draft operational considerations for low latency streaming video applications
  • Mar 2020 Draft documenting Streaming Video Alliance (SVA) reliance on IETF protocols
  • Mar 2020 Draft documenting Society of Motion Picture and Television Engineers (SMPTE) protocol reliance on IETF protocols
  • Jul 2020 Last-call document on Streaming Video Alliance (SVA) reliance on IETF protocols (including explicit outreach to SVA)
  • Jul 2020 Last-call document on Society of Motion Picture and Television Engineers (SMPTE) protocol reliance on IETF protocols (including explicit outreach to SMPTE)
  • Jul 2020 Revised draft of edge network operational considerations for streaming media
  • Jul 2020 Revised draft operational considerations for low latency streaming video applications
  • Nov 2020 Last-call document on edge network considerations for streaming media
  • Nov 2020 Last-call document on operational considerations for low latency streaming video applications
  • Nov 2020 Develop work items specific to media acquisition and delivery

--

Routing

RAW

Name: Reliable and Available Wireless (RAW)

Description: Due to uncontrolled interferences, including the self-induced multipath fading, deterministic networking is difficult to achieve on wireless links. The radio conditions may change -way- faster than a centralized routing paradigm can adapt and reprogram, in particular when the controller is distant and connectivity is slow and limited. RAW separates the routing time scale at which a complex path is recomputed from the forwarding time scale at which the forwarding decision is taken for an individual packet. RAW operates at the forwarded time scale. The RAW problem is to decide, within the redundant solutions that are proposed by the routing, which will be used for each individual packet to provide a DetNet service while minimizing the waste of resources. A RAW solution would consist of a set of protocols that evaluate the media in real time and another that controls the use of redundancy and diversity attributes that are available along the path.

RAW intersects with protocols or practices in development at the IETF as follows:

  • MANET defines DLEP that can be leveraged at each hop to derive generic radio metrics (e.g., based on LQI, RSSI, queueing delays and ETX) on individual hops
  • OAM work at DetNet observes the state of MPLS and IPv6 pseudowires in the direction of the traffic. RAW needs feedback that flows on the reverse path and gathers instantaneous values from the radio receivers at each hop to inform back the source and PREOF relays so they can make optimized forwarding decisions. The work named ICAN may be related
  • SPRING and BIER define in-band signaling that influences the routing when decided at the head-end on the path. There's already one RAW-related draft at BIER, more may follow.
  • RAW will need new in-band signaling when the decision is distributed, e.g., required chances of reliable delivery to destination within latency. This signaling enables relays to tune retries and replication to be met.
  • CCAMP defines protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling in technology-specific networks. RAW would be a source of requirements for CCAMP to define metrics that are significant to the focus radios.

Status: WG Forming

  • Responsible AD: Deborah Brungard
  • BoF proponents: Pascal Thubert <pthubert@cisco.com>, Ethan Grossman <eagros@dolby.com>, Corinna Schmitt <corinna.schmitt@unibw.de>
  • BoF chairs: Erik Nordmark, Rick Taylor
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): 6TiSCH, DetNet, LPWAN, MANET, SPRING, BIER, CCAMP. As IEEE meets the week before, to allow travel time, do not schedule for Monday.

Agenda

  • Review techs and problem statement
  • deep dive into the proposed charter, prioritize and focus
  • time permitting, describe early proposed solutions

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

Security

TXAuth

Name: Transactional Authorization and Delegation

Description: The OAuth protocol and its extensions have provided a powerful set of security capabilities for the internet over the last decade. A transactional model for collecting user consent, describing authorization requests, and delegating authority to another party could provide additional flexibility and power in ways that extending the existing OAuth 2.0 framework does not allow. Additionally, OAuth 2’s many extensions provide point solutions to similar problems that could be better addressed by a unified underlying design. The goal of this BoF is to discuss the additional needs in delegated authorization protocols, gauge the current thinking on how to address them, and to examine how some current and proposed efforts approach such problems. The goal of this BoF is not to discuss how to extend the OAuth 2 protocol itself.

  • Status: Non-WG Forming
  • Responsible AD: Roman Danyliw
  • BoF proponents: Justin Richer <jricher@mit.edu>
  • BoF chairs: TBD
  • Number of people expected to attend: 150
  • Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): Security Area WGs, HTTPBis, QUIC

Agenda

  • Discuss use cases on the edges of and outside the reach of OAuth 2.0
  • Discuss current and future projects that seek to address these use cases

Pointers

MATHMESH

Name: MatheMatical Mesh (MATHMESH)

Description:

To discuss scope of work to specify Mathemetical Mesh technologies. The Mesh consists of a user-centric PKI and a set of component technologies that are used to build it. The IETF (and/or IRTF) might choose to form a Working Group to pursue some, all or none of these.

The component technologies of the Mesh include a naming mechanism (UDF), a cryptographic syntax (DARE) and the use of 'metacryptography' for threshold encryption and key provisioning. Each of these component technologies is closely related to prior IETF work with improved implementation and functionality.

UDF provides a generalization of OpenPGP fingerprints using Base32 encoding (instead of hex), modern digest algorithms (SHA2/3) and addressing semantic substitution attacks. The mechanism is also extended to support symmetric keys, nonces, secret sharing and embedding in URIs and QR codes.

DARE provides an envelope format that approximates to PKCS #7 in JSON. DARE envelopes are designed to stack in DARE Sequences which afford blockchain like incremental integrity assurance through use of a Merkle Tree and incremental encryption by means of a salted Key Derivation Function.

Metacryptography is marketecture for the use of the 'new' cryptography based on the new CFRG Elliptic Curves. Threshold encryption affords a novel approach to cloud security by splitting the private decryption key. This allows a cloud service to control the ability to decrypt without having the ability to decrypt. The key composition mechanism enables the novel approach to key provisioning employed in the Mesh.

The Mesh itself is a user centric PKI that applies the above technologies to make computers easier to use by making them more secure. It also represents the use case that motivated the development of the component technologies and is built on that foundation. While the IETF may choose to work on any or all of the component technologies and not work on the Mesh itself, the reverse is not practical.

  • Status: Non-WG Forming
  • Responsible AD: Benjamin Kaduk, Roman Danyliw
  • BoF proponents: Phillip Hallam-Baker <phill@hallambaker.com>
  • BoF chairs: TBD
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 2.5 hours
  • Conflicts to avoid (whole Areas and/or WGs): WEBPACK, SECURITY

Agenda

  • TBD

Pointers

LAKE (placeholder)

Name: Lightweight Authenticated Key Exchange

Description: [Placeholder for the nascent LAKE WG currently undergoing chartering.] Protocols for constrained environments, and OSCORE specifically, require a lightweight key exchange mechanism to produce authenticated shared secrets with forward secrecy for use to key the protocol used for bulk data protection. LAKE will formulate requirements for such a solution and, if no suitable solutions are already available, produce a solution for the OSCORE use case.

  • Status: WG-forming
  • Responsible AD: Benjamin Kaduk
  • BoF proponents: Goeran Selander
  • BoF chairs: Stephen Farrell
  • Number of people expected to attend: 100
  • Length of session: 1.5 hours
  • Conflicts to avoid: Security Area, 6TiSCH, LPWAN, CORE, CBOR, LWIG, ROLL

Transport

NONE

IAB Sessions

RSEME

  • Long Name: "Community Process for RSE Model Evolution"
  • Abbreviation: RSEME
  • Responsible Area: IAB
  • Chairs: Heather Flanagan
  • Length: 90 minutes
  • Conflicts: Any BoFs? or GEN area meetings; as small a number of other conflicting attendees as possible.
  • Mailing list: rfc-interest@rfc-editor.org
  • Number of people: 150
  • Description: As a follow-on to the virtual interim meetings convened to gather community input on the process for RSE model evolution, this meeting will discuss proposals for the structure of the process.

Previous meeting BOFs

Timeframe IETF 106 (Singapore)?

Timeframe IETF 105 (Montreal)

Timeframe IETF 104 (Prague)

Timeframe IETF 103 (Bangkok)

Timeframe IETF 102 (Montreal)

Timeframe IETF 101 (London)

Timeframe IETF 100 (Singapore)

Timeframe IETF 99 (Prague)

Timeframe IETF 98 (Chicago)

Timeframe IETF 97 (Seoul)

Timeframe IETF 96 (Berlin)

Timeframe IETF 95 (Buenos Aires)

Timeframe IETF 94 (Yokohama)

Timeframe IETF 93 (Prague)

Timeframe IETF 92 (Dallas)

Timeframe IETF 91 (Honolulu)

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)