Status updates

RTG Routing Area

The LISP WG is chartered to continue work on the Locator/Id Separation Protocol (LISP) base specifications and produce standard-track documents.
Indeed, experimental specification exists, but they need to be completed with on the field experience.
In addition, the LISP WG is also chartered to tackle LISP related issues like Multi-protocol support; Alternative Mapping System Design;  Mobility;  Multicast; Data-Plane Encryption; NAT-Traversal.

The working group is actually pretty close to finishing its main task, the main specifications. 
The following documents are the core of the lisp specifications and are under IETF review.
- LISP Data Plane:
- LISP Control Plane: 

The IESG raised a bunch of security-related concerns, which the authors addressed in a huge effort just before IETF 103.
Part of the concerns are solved by the LISP-SEC document
This document is on hold in the WG for no other reason to wait for the final version of control- and data-plane of LISP so to be able to double check consistency with those documents.

[Last Updated: November 27, 2018]
 The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).  SPRING WG serves as a forum to discuss SPRING networks operations, define new applications of, and specify extensions of Segment Routing technologies.

The Segment Routing architecture has been recently published as RFC 8402 and inter-working between SR-MPLS and LDP-MPLS is in RFC editor queue. SPRING has been recently re-chartered (2018-10) and is currently finishing SR-MPLS and its YANG model. SPRING is currently working on SR policy routing, which is a framework on how SR components could be bound together and used for implementation of a scalable source based routing mechanism (draft-ietf-spring-segment-routing-policy).

Candidate future works items are around management, performance monitoring, network and service programming.

[Last updated 2018-11-20]. 
PIM (Protocols for IP Multicast) is chartered to work on multiple IP multicast protocols. The Working Group is responsible for the maintenance of PIM, IGMP, and MLD. We work on the related YANG models. We actively review multicast work that occurs in other WGs, such as MBONED, BESS and BIER. For instance, with the SPRING charter not including work on multicast, we have also been reviewing new proposed work related to Segment Routing and Multicast until such time that SPRING does include multicast in their charter. At our most recent meeting in Bangkok we had a presentation that went into good detail reviewing the various options available for multicast within Segment Routing. We are also now starting the process of progressing IGMPv3/MLDv2 onto standards track. A small team is being formed to begin polling the multicast communities about features they do/don't use  and provide information needed to justify progressing these protocols to Internet Standards. We performed a similar work for PIM a few years ago. We continue working on our existing drafts and recently adopted new work on reserved-bits, null-register-packing and bfd-p2mp-use-case. We look forward to continuing work on the mailing list as we prepare for our next meeting in Prague.
The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP. In particular it focuses on BGP based L2VPN, L3VPN, EVPN, multicast VPN.

The current WG focus is mainly on EVPN which remains a brand new technology while still doing housekeeping on the other topics.
The WG has a significant amount of work on flexible Designated Forwarder Election (DF election) procedures to forward Broadcast Unknown Multicast traffic within an EVPN. Such flexibility is required to accommodate various use cases. The framework for the flexible DF election [1] is almost ready while multiple optional procedures are under discussions within the WG [2] [3] [4].
The WG is also actively working on YANG models for the VPN services [5] [6] [7] [8]. We expect this work to be closed in 2019.
The WG is also working on service function chaining based on BGP [9] [10]. We expect this work to be closed in 2019.
The WG has recently started working on secure VPNs to ensure a secured transport of VPN services [11] [12].

[Last Updated: November 15, 2018.]

Scope of the MPLS wg responsibility
The MPLS working group is responsible for standardizing technology
for label switching and for the implementation of label-switched 
paths over packet based link-level technologies.

The working group's responsibilities include procedures and protocols
for the distribution of labels between Label Switching Routers 
(LSRs), MPLS packet encapsulation, and for Operation, Administration,
and Maintenance (OAM) for MPLS systems including the necessary 
management objects expressed as YANG models or MIB modules.

Current Focus
The MPLS working group are currently working on YANG models for the MPLS
key protocols, MPLS resilient rings (RMR), MPLS data plane documents for Service
Function Chaining (SFC) and Segment Routing, and Deterministic Networking 

The latest RFCs published were:
RFC 8320 "LDP Extensions to Support Maximally Redundant Trees" 2018-02 
RFC 8372 "MPLS Flow Identification Considerations" 2018-05


MIB     Management Information Base
OAM   Operations, Adminstration and Maintenance
wg       working group

The BFD Working Group standardizes the Bi-directional Forwarding Detection protocol specified in RFC 5880 and its related documents.  BFD is typically used by "client protocols" in order to provide sub-second continuity verification, typically augmenting much slower protocols.  An example of this is providing sub-second detection of link failures for IGPs (Interior Gateway Protocols).  A "seamless" version of BFD, S-BFD, is specified in RFC 7880 and its extensions to provide for BFD functionality in environments where endpoints are potentially unknown to each other.

New work under consideration for BFD includes:
- Optimized authentication procedures to permit authentication to be used with high granularity session timers.
- Validation of path MTU over the links utilized by a BFD session.
- Operating in demand mode in MPLS environments.
- Providing RFC 5880/5881 services without explicit IP endpoint configuration.

The status of the Working Group is always available at

[Last Updated: November 8, 2018]

IDR is resposible for the BGP protocol. 

IDR WG had interim prior to IETF 103 on 10/26/2018. 
The recording is available here: (streaming) (download)

Chairs plan to hold 1+ interim with discussions on: 
-	Auto-discovery topic 
-	Bgp-attribute use 

1document at RFC editor:  draft-ietf-idr-bgp-gr-notification-15.txt 
   (Jie Dong Shepherd) 

The following 3 documents sent to IESG for publication
-	draft-ietf-idr-bgpls-segment-routing-epe-17 [Susan Hares Shepherd] 
-	draft-ietf-idr-bgp-ls-segment-routing-ext-11 [Susan Hares Shepherd] 
-	draft-ietf-idr-bgp-te-pm-bgp-14  [Susan Hares Shepherd] 

Two new documents adopted: 
-	draft-ietf-idr-capabilities-registry-change-00.txt 
-	draft-ietf-idr-bgpls-inter-as-topology-ext

One documents with implementation waiting  for Revised ID after WG input 
-	draft-ietf-idr-rfc5575bis-09 (Jie Dong Shepherd) 

The followign three drafts with implementations waiting for Shepherd write-up  
-	draft-ietf-idr-bgp-optimal-route-reflection (John Scudder)
-	draft-ietf-idr-tunnel-encaps (John Scudder) 

The following drafts have past WG LC and these documents are waiting for implementation 
-	draft-ietf-idr-rs-bfd-06 (Susan Hares) 
-	draft-ietf-idr-bgp-bestpath-selection-criteria-09.txt (Susan Hares Shepherd) 
-	draft-iettf-idr-rtc-no-rt-10  (John Scudder) 
-	draft-ietf-idr-ls-trill-05 (John Scudder) 

We have received three requests for adoption pending 
-	draft-ketant-idr-bgp-ls-app-specific-attr
-	draft-ketant-idr-bgp-ls-flex-algo
-	draft-li-idr-bgpls-sbfd-extensions 

One WG LC did reach consensus (draft-ietf-eag-distribution-08).

The IDR chairs WG will do requested WG LC in following priority 
-	registry drafts (draft-ietf-idr-capabilities-registry-change-00.txt)
-	operator critical drafts (based on OPS/grow feedback)  
-	drafts with existing implementations,  and 
-      drafts regarding existing work (flow-spec, bgp-ls, segment routing, and communities) 

The PCE working group is responsible for the Path Communication Element Communication Protocol (PCEP).  PCEP allows a Path Computation Client (PCC - for example, a head-end router) to request paths from, or have paths created by, a Path Computation Server (PCE).

The WG is concluding the recent effort on generalizing PCEP to include segment routing paths for an MPLS data plane [1].  Another piece of work reaching its conclusion is the extension of PCEP for GMPLS networks [2].  We are also concluding the protocol extensions to allow for a hierarchical structure of PCEs (H-PCE) which provides a parent PCE to coordinate the operation of per-domain child PCEs [3].

The WG is actively working on adding to PCEP the concept of an "association group" which binds together arbitrary sets of LSPs and/or policies for the purposes of path computation.  The base draft for this [4] is very flexible and allows for many follow-on innovations, ranging from associations reflecting common policies to those mandating resource diversity and other relationships such as bidirectionality and resource sharing. Another significant piece of work in progress is the extension that allows a PCE to act as a network controller, by instantiating path state on each hop in an LSP [5] and using a flow specifier to add traffic classification to the head-end node of the LSP [6].

[Last Updated: November 8, 2018.]

The PALS WG defines, specifies, and extends network services based on pseudowires and/or signaled using the Label Distribution Protocol (LDP). It is a continuation of work that originated in the now-concluded PWE3 and L2VPN WGs.

The WG has primarily been working on wrapping up its work. It has published all of its extant working group drafts as RFCs, and is currently discussing an individual draft that intends to make it easier to incrementally introduce the pseudowire control word into networks that don't currently support it.

[Last Updated: November 7, 2018.]
The Link-State Routing (LSR) Working Group is chartered to document current protocol implementation practices and improvements, protocol usage scenarios, maintenance and extensions of the link-state interior gateway routing protocols (IGPs) - specifically IS-IS, OSPFv2, and OSPFv3. The LSR Working Group was formed by merging the ISIS and OSPF WGs and assigning all their existing adopted work at the time of chartering to LSR.

Current areas of interest in the LSR WG include:

 * Segment Routing Extensions: The IS-IS, OSPFv2, and OSPFv3 extensions for the MPLS data plane are all nearly completion. The are all dependent on a normative reference to the "Segment Routing in the MPLS Data Plane" draft. Extensions for Segment Routing on the IPv6 data plane are under way. The salient LSR Segment Routing drafts are:

   - OSPF Segment Routing Extensions -
   - IS-IS Segment Routing Extensions -
   - OSPFv3 Segment Routing Extensions -
   - Segment Routing in the MPLS Data Plane -
   - IS-IS Extensions to Support Routing over IPv6 Data Plane -

* YANG Modeling: The base OSPF YANG Model has completed WG last call and is ready for publication request. The base IS-IS model will follow shortly. We have various model drafts for extensions that can be progressed now that the base models are nearly publication. The relevant YANG model drafts include:
    - YANG Data Model for OSPF Protocol -
    - YANG Data Model for IS-IS Protocol -
    - YANG Data Model for OSPF Segment Routing -
    - YANG Data Model for IS-IS Segment Routing -
    - YANG Model for OSPFv3 Extended LSAs -

* Computation Optimizations: There are both WG documents and individual proposals to improve the LSR route computation. These include: 

    - IGP Flexible Algorithm -
    - OSPF Routing with Cross-Address Family Traffic Engineering Tunnels -
    - Preferred Path Routing (PPR) in IS-IS -
    - Preferred Path Routing (PPR) in OSPF -
    - Preferred Path Route Graph Structure -
 * Link Attribute Advertisement: OSPF and ISIS will allow application specific link attributes. 

    - IS-IS TE App -
    - OSPF Link Traffic Engineering (TE) Attribute Reuse -

 * Data Center (DC) Routing Optimizations: We have multiple proposals to reduce the flooding overhead in densely meshed data center topologies. Many of these will be presented at IETF 103 in Bangkok. A list of drafts in this area is included below:

    - IS-IS Spine Leaf -
    - Dynamic flooding -
    - IS-IS Sparse Link-State Flooding -
    - OSPF Flooding Reduction -
    - Distributed Algorithm for Constrained IGP Flooding -
    - IS-IS Support for Openfabric -

  While there is much differentiation in these proposals there is also a significant amount of overlap. This is an area of WG debate and there may be in interim on the topic. 

At IETF 103, there will also be some key presentations relating to IS-IS protocol enhancements. These have been talked about in the past but no formal proposals have gone forward. These could be the start of some exciting new protocol enhancements: 

     - IS-IS over TCP -
     - Level 1 IS-IS Area Abstraction -
     - Hierarchial IS-IS -

Document Status:

  Since the last IETF in Montreal, there have not been in RFC published. However, the following drafts have have completed IESG review since Montreal and will be published "soon":

      - Signaling MSD (Maximum SID Depth) using IS-IS -
      - Signaling MSD (Maximum SID Depth) using IS-IS -
      - OSPF LLS Extensions for Local Interface ID Advertisement -
The following draft is currently in the IESG Evaluation process:

       - IS-IS Routing with Reverse Metric  -

 The following draft is in IETF last call: 

         - OSPFv3 Segment Routing Extensions -

   Publication has been requested for the following drat: 

         - H-bit Support for OSPFv2 -

Date: November 1st, 2018


ROLL focuses on routing issues for Low Power and Lossy Networks (LLN) and maintaining the protocols already developed, including RPL and MPL. The focus is on IPv6 work only. 

The WG recently accepted a proposal that describes RPL protocol design issues, consequences and implementation choices, with the goal of producing new documents that solve those problems. The WG finalized the work that solves the issues of the mechanisms used for a route invalidation system. The WG is in the final stage to approve a proposal that uses a reactive P2P    route discovery mechanism for both hop-by-hop routing and source  routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL  protocol,  when some of the links between source and target node are  asymmetric.

Additionally, in the WG a proposal is presented to select the appropriate  parents to achieve ultra-low latency and jitter. Another proposal describes an objective function based on a metric that represents the amount of remaining traffic handling capacity that the node has. In The WG also, we have a proposal that describes the unicast routing  service in a RPL domain to 6LoWPAN ND nodes that are not RPL  protocol aware.

[Last Updated: November 4, 2018.]

SEC Security Area

On Monday we discussed several of the current drafts and made some progress in understanding the design options and moving the documents forward. The architecture document was presented by Emad Omara, which was mostly uncontroversial.

The protocol document took most of the time at this meeting. The big problem of group members having access to the keys of multiple group members (the double-join problem) was discussed at length. Most of the issues were around efficiency and making sure that any double-join protection mechanism continues to be logarithmic instead of devolving into linear time. New ideas were introduced around group initialization and giving a special exception to the group initializer --- which was a promising idea. Nadim Kobeissi presented remotely about authentication which illustrated how derived signature keys could improve the situation where authentication keys are compromised.
On Thursday we reviewed the message protection draft, recapping the work that was presented at the interim about message protection. This led to a vigorous debate about forward secrecy. We also discussed a potential interim in January in San Jose, CA in order to take advantage of the presence of Real World Crypto.
IETF 103 Status Report

The EMU WG met on Monday (November 5) between 16:10 - 18:10.

Updates to the following two working group documents were presented:

1. EAP-TLS with TLS 1.3 - draft-ietf-emu-eap-tls13-02

2. Improvements to EAP-AKA' (RFC5448bis) - draft-ietf-emu-rfc5448bis-03 .

There was consensus in the room to issue WGLC for 

We also discussed PFS enhancements to EAP-AKA' and problems in using 
large certificates with EAP-TLS. There was consensus in the room to 
adopt the work on PFS enhancements to EAP-AKA'.

Lastly, we also had presentations on two non-chartered items: EAP-NOOB, 
and BRSKI with TEAP.
The WG discussed remaining outstanding issues for draft-ietf-tls-dtls13-29.  Version -30 was posted and will enter WGLC shortly.  draft-ietf-tls-dtls-connection-id and draft-ietf-tls-exported-authenticator are now in WGLC. With some minors tweaks draft-ietf-tls-grease will also be ready for WGLC. 

draft-ietf-tls-oldversions-deprecate, which was adopted since IETF102, will be revised to indicate which RFCs normatively depend on TLS 1.0 and 1.1 and then will likely be ready for WGLC. 

Changes to draft-ietf-tls-esni (i.e., using ENSI RRType instead of TXT record) and its operational issues (i.e., hardfails and multi-CDNs) were discussed. The draft needs additional reviews from DNS folks.

draft-housley-tls-tls13-cert-with-extern-psk was scoped down to be for external PSKs for initial handshakes.  The sense of the room was to adopt the draft as a WG Item. This will be confirmed on list.

draft-tls-certieee1609 will be used as the basis for a TLS Certificate Type code point request. The WG will not consider it for adoption. 

draft-wood-tls-external-psk-importer was discussed as a way forward for external PSKs with TLS 1.3. More discussion and comparison to draft-davidben-tls-universal-psk is needed.

Updates to draft-wood-tls-ticketrequests were discussed. The WG considers it a potential WG item. This will be confirmed on list.

The WG had a lengthy discussion about draft-ietf-tls-dnssec-chain-extension and there was WG consensus to drop the draft as a WG item.
EdDSA is in the RFC editor queue,  Publication requested has been issued for Split DNS, and now the AD comments should be resolved. Implicit IV is past WGLC, and should be ready for publication really soon now (waiting for writeup). Quantum resistance is currently in WGLC. Rechartering is now in the IESG and should be finished soon.

We have already started working on the some of the new items in new charter, i.e., ESP compression, Post-quantum key exchanges (including making IKE_AUX exchange to allow transporting large objects before IKE_AUTH exchange) etc.
As of 2018-7-19:

SecEvent will be meeting on Friday.

The baseline SET (security event token) specification, our first document, was published since London as RFC 8417.
The group is working on two documents about delivery of SETs, and those will be discussed Friday.
As of IETF 102:
ACME met Tuesday afternoon.  It was a very productive meeting.  This status also serves as a reminder that we need 90 minutes next time. :)  Or the chair(s) need to be more ruthless about enforcing the unreasonable time limits.
The agenda was augmented by two last-minute presentations, from the ANRW/hotRFC and SECDISPATCH. The first was on scope and some mitigation for IP address use-after-free, and the second was on using ACME for STAR.  Both had good discussion, and are likely to be taken up by the WG soon.  So this is a point in favor of those forums.
In other work, the WG accepted a PR that addresses the last AD comments, and is redoing WGLC in parallel with IESG review.  The ALPN and IP documents will be moved to WGLC. The email docs need another draft and then hopefully move to WGLC.  Everyone should read the Authority Token documents.
The ACE working group met on Monday in the first session.

The CWT document has gone to the RFC Editor since the last meeting and the associated POP CWT draft is expected to progress to the IESG before Montreal.

The WG adopted the EST over CoAP draft after some heavy modifications with some of the work going to the ANIMA group.

During the week there has been a start at getting some interop testing done with the OAuth framework using the DTLS profile which has started to show some promise.  We are going to try to have a couple of virtual interop events over the next couple of months with the goal of having enough by Montreal to be able to be comfortable with going to WGLC then.  As part of this work we will need to look at getting the OSCORE profile tested as well.

There were some non-working (future work) presented dealing with group messaging authorization scenarios that was presented where some re-factorization work had been done to combine pieces that are common between the two drafts.

The WG then has some discussions on a key establishment protocol EDHOC with comparison of message sizes and numbers between that proposal and using TLS to do key establishment transporting the TLS messages inside of CoAP.  While the two protocols have similar results under the UDP scenario, they have different results when looking at the 6TiSH world where packets are restricted in size.

The lamps WG met on Monday of IETF 100. The current status of the WG
documents was covered. The Internationalization updates for RFC5280 has
been approved for publication. The other three original drafts are in the
process of going from the WG to the IESG.

We had a presentation on the CAA Discovery algorithm and what the current
problems are. The group indicated that it would like to get a document for
what the current algorithm is with the errata applied, and would then
entertain a new document to deal with problems found using that algorithm.

The final presentations dealt with getting SHAKE added as a hash algorithm
to the various signature algorithms being used in PKIX and CMS applications
today. Discussion on the current state of DSA indicated that the WG was not
interested in adding SHAKE to DSA.
trans met Monday afternoon.  Our three deliverables are nearing
completion, with two having successfully completed wglc and one
requiring a revision before restarting wglc.  During the session
we talked about label redaction in CT logs (still contentious)
and problems around logging short-lived certificates.  Over the
coming months we'll be deciding whether to take on new work or
to shut down.
The Software Updates for Internet of Things (SUIT) BoF was held on Monday during the afternoon II session [1]. This proposed WG intends to focus on defining a firmware update solution that will be usable on Class 1 devices (as defined in RFC 7228), which may also apply to more capable devices as well. 

The BoF was well attended both in-person and remotely. The discussion focused on review of the charter, with a series of hums leading to some changes to the charter text. The revised charter has been posted [2]. Comments to the SUIT list supporting the charter or focused on charter text changes are appreciated. 


Updates since Prague: draft-ietf-kitten-rfc5653bis went through IETF LC and is waiting for AD writeup.
The WG-related work draft-ietf-curdle-des-des-des-die-die-die also went through IETF LC and is waiting for
a decision from the IESG on the right way to update/obsolete/move-to-historic an Informational document
such as RFC 4757 (the RC4 kerberos enctypes).

Our main active work items are draft-ietf-kitten-krb-spake-preauth and draft-ietf-kitten-channel-bound-flag,
both of which hit some stumbling blocks as we gained implementation experience.  Some coordination is needed
between draft-ietf-kitten-krb-spake-preauth and draft-irtf-cfrg-spake2, which is underway.

Lower priority ongoing work is to move more GSSAPI and Kerberos registries to IANA control, and publish
draft-ietf-kitten-pkinit-alg-agility and draft-ietf-kitten-krb-service-discovery (which have deployed implementations).

We received proposals for some potential new work items: a "hashed token" (i.e., resumption) SASL mechanism,
and a generic way to communicate password quality/attribute requirements, and are assessing whether there
is sufficient interest to merit WG adoption.
SACM met on Tuesday (2016-11-15) at 9:30 for 2.5 hours, and we discussed our architectural approach, how to get software identifiers collected from endpoints, and open issues with our information model.  We also started considering how we can keep our information model minimized but extendable based on some real-world state collection data.  

Next steps include enumerating the functions/interfaces and data that we need flowing through the SACM environment to support our vulnerability assessment scenario. 
MILE met at IETF 96 at 10:00 on Thursday.
There were about 45 - 50 attendees in the room and Jabber.

[working group drafts]

1. RFC5070-bis will be published as an RFC soon.

Update after the WGLC was shared during the session, and the attendee seems to very happy to publish the draft as an RFC.

2. implement draft will be published as an RFC soon.

Though no presentation was done this time, we see no problem to proceed.

3. ROLIE draft was refined so that we can pursue submission to IESG by November.

The original ROLIE draft will be divided into two documents.
One is for general information exchange purpose, while the other is for incident-response specific purposes.

4. Review was requested for xmpp-grid and guidance drafts.

The content of the drafts seem to be good, but we need more review. We have seen quite many candidate reviewers for the drafts.

[individual draft]

1. the draft on JSON binding of IODEF is considered to be an WG draft.

The attendee today seem to be happy to make it as a WG draft, but we will ask consensus on this on the mailing list.
CURDLE did not meet at IETF-96. A discussion about OID assignments for curves will be held as part of the LAMPS session.

TSV Transport Area

As of IETF 103, RMCAT had completed working group last call on the evaluation and video traffic model drafts, noting only minor issues. These drafts will be updated, a brief WG last call done to confirm the changes, then sent to the IESG in the November/December 2018. The NADA draft has two implementations, that perform as expected. There were implementations of the congestion control feedback draft at the hackathon, resulting in suggestions for minor updates.
In Singapore, the IPPM WG:

- discussed maintenance of its framework for IPv6 (WGLC is done and requires a writeup from the shepherd), 
- continued discussion of the WG IOAM data model and registry drafts
- moved to adopt Advanced Unidirectional Route Assessment and the Simple Two-way Active Measurement Protocol (STAMP), i.e. TWAMP without TWAMP-Control.

IPPM continues maintenance of OWAMP/TWAMP,  is moving toward publication of the registry, and continues work on IOAM.
Four TSVWG drafts have been published as RFCs:  Circuit Breakers, UDP Guidelines GRE in UDP and Diffserv Interconnection. There are two TSVWG drafts at the RFC Editor in MISSREF state (waiting for referenced RFCs to arrive):WebRTC Diffserv usage and DTLS encapsulation of SCTP.

Working Group Last Calls (WGLC) have been completed for three drafts: Tunnel Congestion Feedback (follow-up with the authors), 802.11 (WiFi) Diffserv (reviews received, a revised ID is needed) and SCTP stream scheduling/interleaving (a revised ID is needed).  

The ECN experimentation enablement draft and the Diffserv LE (Lower Effort) PHB drafts were recently adopted, but are close to done.   

The following drafts require feedback and work by the working group:
* RFC 4960 Errata
* SCTP NAT Support
* ECN Encaps Guidelines (recently discussed in external liaisons).
* RFC 6040 Update

The L4S drafts are likely to be an active area of WG activity in 2017.

The AQM (Active Queue Management and Packet Scheduling) WG is nearing the end of its life - future AQM-related work is likely to be done in TSVWG.
The WG drafts on the encryption negotiation option (TCP-ENO) and unauthenticated encryption mechanism (tcpcrypt) have completed WG Last Call - the RFC publication requests for both drafts are expected to be submitted by the end of the Chicago meeting week or earlier.  The TLS-based work for tcpinc has been postponed because finishing TLS 1.3 is higher priority for the TLS experts.

A draft on (sockets) API extensions, primarily for TCP-ENO, has been adopted by the WG - the chairs are looking for additional interest in working on that draft, as well as interest in additional implementation(s) of TCP-ENO and tcpcrypt.
Editors are working on -01 drafts in preparation for Chicago; we continue to work through a healthy issues list.
TCPM works on some standards-track documents as well as several experimental and informational documents, which are all comprehensively reviewed prior to publication.

Currently the working group finishes the documents that describe the CUBIC congestion control and Datacenter TCP (DCTCP). The working group will met during IETF 98 in Chicago.
Since IETF95 meeting, draft-ietf-taps-transports (addressing the first deliverable) is in the IESG evaluation state and after addressing reviews it is now scheduled for telechat. The UDP transport usage draft has been updated and there was discussions on merger of this to draft-fairhurst-taps-transports-usage draft or keeping this as a separate draft. There was at least no opposition on keeping it separate. In the IETF95 meeting, it was said that if they are separate they should be moved together. 

The group is picking up on the third milestone. There has been discussion on the "northbound" information in IETF96 meeting, draft-grinnemo-taps-he discusses the happy-eye ball approach for transport protocol selection, recently a draft (draft-trammell-post-sockets) has been posted addressing the possibilities of post socket era, industry player like Apple - talking about the considerations transport protocol for real-world API, real-time applications are in the discussions too (draft-mcquistin-taps-low-latency-services). This give an indication that TAPS could nurse number of interesting ideas which can be very useful for transport protocol evolution and could be good input to the newly formed working group like QUIC.     
A productive meeting was held on July 18th at IETF96 Berlin, with presentations on the status of BPBis, TCP-CL, BPSec, and numeric node ids.  There were also two presentations on potential approaches to solve the charter item of static routing in DTNs.  The BPbis presentation covered changes to the latest draft, particularly around the use of CBOR encoding and clarification of Customdy Transfer, with general consensus that the CBOR encoding should be specified as the standard bundle representation, and that convergence layer requirements should be stated in the draft, but specific details left to transport-specific drafts, for example TCP-CL. The TCP-CL presentation covered changes to the existing TCP-CLv3 experimental draft to align it with the latest BPbis work, and meeting consensus suggested it as a working group document, as it is a charter item.  The rest of the meeting involved several presentations concerning addressing and forwarding of bundles through a heterogenous DTN, and although the discussion was productive, no consensus on a way forward was noted.

A well attended interim meeting was held on September 28th, via WebEx, with presentations and discussion on the progress of BPbis and TCPCL.  Scott Burleigh reported that good progress was being made with the CBOR encoding.  Brian Sipos reported on the work on TCP-CL, and valuable discussion was had around backwards compatibility and hop-by-hop encryption using TLS.  Consensus from the meeting was that TCP-CL should be accepted as a WG document, if there was consensus on the mailing list, which there was after the meeting.

Minutes of both meetings are available on the DTN datatracker.
Both TURN bis and STUN bis are really close to being ready for WGLC. Most of the other working group items are either ready for WGLC or past-WGLC. So, we TRAM WG will likely be able to complete its chartered work, declare victory, and close down in the near future.

IRTF Internet Research Task Force