[ieee-ietf-coord] BoFs for IETF 105

Russ Housley <housley@vigilsec.com> Wed, 12 June 2019 18:46 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: ieee-ietf-coord@ietfa.amsl.com
Delivered-To: ieee-ietf-coord@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 491681200FA for <ieee-ietf-coord@ietfa.amsl.com>; Wed, 12 Jun 2019 11:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bTM8r5bWla-n for <ieee-ietf-coord@ietfa.amsl.com>; Wed, 12 Jun 2019 11:46:45 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAFE120180 for <ieee-ietf-coord@ietf.org>; Wed, 12 Jun 2019 11:46:38 -0700 (PDT)
Received: from localhost (localhost []) by mail.smeinc.net (Postfix) with ESMTP id 74AD0300A91 for <ieee-ietf-coord@ietf.org>; Wed, 12 Jun 2019 14:27:20 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([]) by localhost (mail.smeinc.net []) (amavisd-new, port 10026) with ESMTP id Ao6-ilx8TeAn for <ieee-ietf-coord@ietf.org>; Wed, 12 Jun 2019 14:27:18 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown []) by mail.smeinc.net (Postfix) with ESMTPSA id 4384B3004A7 for <ieee-ietf-coord@ietf.org>; Wed, 12 Jun 2019 14:27:18 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_18D370E8-6A9F-42B7-AC90-0E03DAAC6B3F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <1CD7FECA-5483-497D-A694-4ABCD22B0904@vigilsec.com>
Date: Wed, 12 Jun 2019 14:46:35 -0400
To: "<ieee-ietf-coord@ietf.org>" <ieee-ietf-coord@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ieee-ietf-coord/X_rgMFHSU_0PteYFKeicdoBRnD4>
Subject: [ieee-ietf-coord] BoFs for IETF 105
X-BeenThere: ieee-ietf-coord@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Management-level discussions between IEEE and IETF on topics of interest to both SDOs <ieee-ietf-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ieee-ietf-coord>, <mailto:ieee-ietf-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ieee-ietf-coord/>
List-Post: <mailto:ieee-ietf-coord@ietf.org>
List-Help: <mailto:ieee-ietf-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ieee-ietf-coord>, <mailto:ieee-ietf-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jun 2019 18:46:50 -0000

The list of approved BoFs and descriptions can be found here:

Here is a brief summary...

Applications and Real-Time

    ADD - Applications Using DoH - Discussions at the DoG WG and a side
    meeting at IETF104 suggest there appears to be significant interest
    in examining in the operational aspects of DoH deployment,
    particularly in operator and enterprise networks. This lead to
    the creation of the ADD mailing list where some of these issues
    have been discussed. The proposed BoF intends to establish if
    there are sufficient potential work items and enough interest at
    the IETF to justify the creation of a new Working Group which
    would focus on these topics.


    NETRQMTS - IETF Meeting Network Requirements - NOT WG Forming - The
    IETF meeting network has a long history of pushing beyond the bounds
    of normal event networks. This BoF will gather community input on
    the network requirements for IETF meetings, including prioritization
    and the resource implications associated those requirements.


Operations and Management

    MOPS - Media OPerationS - The purpose of this BoF is to highlight the
    many existing video activities that are leveraging IETF protocol work,
    identify gaps in IETF work and/or areas of incompatibility with video
    technology development efforts being carried out elsewhere, and
    identify a core group of IETF participants working on video activities
    across the IETF’s technology areas.



    CACAO - Collaborative Automated Course of Action Operations (CACAO)
    for Cyber Security - To defend against threat actors and their 
    tactics, techniques, and procedures, organizations need to manually
    identify, create, and document prevention, mitigation, and
    remediation steps.  These steps when grouped together into a course
    of action (COA) / playbook are used to protect systems, networks,
    data, and users.  The problem is, once these steps have been created
    there is no standardized and structured way to document them, verify
    they were correctly executed, or easily share them across
    organizational boundaries and technology stacks.  The intent is to
    charter a working group that will create a standard that implements
    the playbook model for cybersecurity operations.

    LAKE - Lightweight Authenticated Key Exchange - Constrained
    environments using OSCORE in network environments such as NB-IoT,
    6TiSCH, and LoRaWAN need a 'lightweight' authenticated key exchange 
    that enables forward security. 'Lightweight' refers to resource
    consumption, measured by bytes on the wire, wall-clock time to
    complete, or power consumption; and the the amount of new code
    required on end systems which already have an OSCORE stack. 


    LOOPS - Local Optimizations on Path Segments - Performance Enhancing
    Proxies (PEPs) have been used to improve performance over paths with
    links of varying quality, often peeking (and poking!) into the
    transport protocol.  Encryption is putting an end to this practice.
    At the same time, more powerful network nodes are becoming available,
    making it more viable to trade processing power in network nodes
    against path quality.  Transport protocols and their implementations
    are moving towards playing better with forwarding node functions such
    as ECN marking and AQM.