Status updates

RTG Routing Area

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. An RFC7432bis will start to be prepared soon to fix the known issues in the original specification of EVPN.
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 to be published while multiple optional procedures are under discussions within the WG [2] [3] [4] [13] [14].
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. [10] will be soon submitted to the IESG for a final review.
The WG has recently started working on secure VPNs to ensure a secured transport of VPN services [11] [12]. However it has been identified that other working groups (IDR and I2NSF) are also working on similar technology building blocks. The chairs will synchronize to ensure that the minimum set of building blocks is created to enable the various use cases.

[Last Updated: April 2019.]

 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-26].
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].  

The WG is progressing the work related to use of PCE (and PCEP) for the hierarchy of controllers (as per the Abstraction and Control of TE networks (ACTN) framework). 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]. We have made progress in moving the Stateful operations for P2MP TE tunnels [7] (used by Multicast applications) and automatic bandwidth adjustments [8].  

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 central 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: March 26, 2019.]

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 still discussed in the WG, but changes are being done so to solve the majority (if not all) of the security concerns raised by the IESG review.

[Last Updated: March 25, 2019]
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 either on the RFC queue or in the final review cycle. 

   - OSPF Segment Routing Extensions -
   - IS-IS Segment Routing Extensions -
   - OSPFv3 Segment Routing Extensions -
   - Segment Routing in the MPLS Data Plane -

 * Segment Routing Extensions based for IPv6 are being developed. 

   - 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:

 * The following YANG models are awating AD Review:     

    - YANG Data Model for OSPF Protocol -
    - YANG Data Model for IS-IS Protocol -

 *  The following are being developed.

    - 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 -

 * Link Attribute Advertisement: OSPF and ISIS will allow application specific link attributes. These drafts will be WG last called shortly after IETF 104. 

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

 * Data Center (DC) Routing Optimizations - We have adopted the base dynamic flooding draft. This draft doesn't specify the algorithm and work on algorithms can now proceed in separate drafts. 

 * The following are WG documents with updates at Prague: 

    - IS-IS Spine Leaf -
    - Dynamic flooding -

At IETF 104, there will be updates on existing WG documents as well as presentations on following new work:

     - IS-IS Invalid TLV -
     - Update to IS-IS SRv6 -
     - OSPFv3 BIER Extensions -
     - OSPF Admin Tags -
     - OSPF Reverse Metric -
     - OSPF BFD Strict Mode -
     - Updates to Flooding Reduction -
     - OSPFv3 Extended LSA YANG Model -
     - Hierarchial IS-IS -
     - IS-IS Area Abstraction -

Document Status:

  * Since the last IETF in Bangkok, the following RFC have been published:

    - RFC 8444 - OSPFv2 Extensions for Bit Index Explicit Replication (BIER) – BIER WG Document
    - RFC 8476 – Signaling Maximum SID Depth (MSD) using OSPF
    - RFC 8491 – Signaling Maximum SID Depth (MSG) using ISIS
    - RFC 8500 – IS-IS with Reverse Metric
    - RFC 8510 - OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement
    - RFC 8570 – RFC 7810 Correction of IS-IS TE Metric Extensions encoding 

  * The following drafts are on the RFC Queue waiting for missed references:

    - Advertising L2 Bundle Member Link Attributes in IS-IS -  draft-ietf-isis-l2bundles-07.txt– Waiting on ISIS SR Extensions. 
    - The Tunnel Encapsulations OSPF Router Information draft-ietf-ospf-encapsulation-cap-09 – Waiting on IDR Tunnel Encap Draft (To be presented in IDR) 
    - OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions-27 - Waiting on “Segment Routing with MPLS Data Plane” and “Segment Routing InterOp with LDP"
    -  OSPFv3 Extensions for Segment Routing  - draft-ietf-ospf-ospfv3-segment-routing-extensions-23 – Also waiting on same drafts. 

  * The following drafts are in the AD review process:

    - H-bit Support for OSPFv2 draft-ietf-ospf-ospfv2-hbit-06 – Waiting on authors for revised update for simple comments for over 100 days!
    - IS-IS Extensions for Segment Routing draft-ietf-isis-segment-routing-extensions-22 – Comments recently provided and revised ID required
    - YANG Data Model for OSPF Protocol - draft-ietf-ospf-yang-21 – Waiting on AD Review
    - YANG Data Model for IS-IS Protocol - draft-ietf-isis-yang-isis-cfg-35 – Waiting on AD Review
    - OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-05 – Publication just requested. 

  * The following drafts are in WG last call:

    - Restart Signaling for IS-IS - draft-ietf-lsr-isis-rfc5306bis-01
  * The following drafts will be WG last called soon:

    - IS-IS TE Attributes per application - draft-ietf-isis-te-app-05.txt 
    - OSPF Link Traffic Engineering (TE) Attribute Reuse - draft-ietf-ospf-te-link-attr-reuse-06.txt 

   * The following are new WG documents:

    - Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding-00
    - IS-IS Routing for Spine-Leaf Topology - draft-ietf-lsr-isis-spine-leaf-ext-01 
    - OSPF Extension for Prefix Originator - draft-ietf-lsr-ospf-prefix-originator-00 
    - IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-00

   * The following are existing WG documents:

    - Signaling Entropy Label Capability and Entropy Readable Label Depth Using - IS-IS draft-ietf-isis-mpls-elc-06 - Authors need to bring forward
    - Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF - draft-ietf-ospf-mpls-elc-07 - Authors need to bring forward
    - IGP Flexible Algorithm draft-ietf-lsr-flex-algo-01.txt - Work on implementations in progress
    - YANG Data Model for OSPF SR (Segment Routing) Protocol draft-ietf-ospf-sr-yang-07 - To be progressed now that base YANG documents are with AD
    - YANG Data Model for IS-IS Segment Routing draft-ietf-isis-sr-yang-05 - To be progressed now that base YANG documents are with AD 

Date: March 24th, 2019


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  accepted a proposal that describes RPL protocol design issues, consequences and implementation choices, with the goal of producing new documents that solve those problems.  One document from the result is draft-rahul-roll-mop-ext. 

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 new 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.

RPL performance is presented focusing in asymmetric links, such as deaf nodes.

[Last Updated: March 22, 2018.]
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:
- Refining client protocol semantics for BFD liveness vs. protocol liveness in BGP and OSPF.
- Considering BFD for the Geneve transport protocol.
- 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.
- Providing RFC 5880/5881 services without explicit IP endpoint configuration.

and finally:
- Considering whether it's time to extend BFD to provide a more general framework for carrying additional information.

The status of the Working Group is always available at

[Last Updated: March 19, 2019]

Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them.

The Link-State Vector Routing (LSVR) Working Group is chartered to develop and document a hybrid routing protocol utilizing a combination of link-state and path-vector routing mechanisms. The LSVR WG will utilize existing IPv4/IPv6 transport, packet formats and error handling of BGP-4 consistent with BGP-LS NLRI encoding mechanisms (RFC7752) to facilitate Link-State Vector (LSV) routing information distribution. 

The LSVR specification is initially focused on operation within a single datacenter (DC) as a single distribution domain, LSVR Routing protocol functionality would be typically used for routing within a datacenter’s underlay routing plane. The work will include coexistence considerations with BGP IPv4/IPv6 unicast address families installing and advertising routes into the same RIB.

The main workgroup deliverable is the actual LSVR technical specification, together with a description of "how & where" LSVR can be used. Both of these key deliverable documents are currently in relative stable state, ready for a first implementation.  In addition, recently LSoE (Link-State-over-Ethernet, a new Layer-2 discovery protocol) has been adopted into the LSVR working group. The goal of LSoE is to assist in LSVR neighbor discovery and to feed interface and neighbor information into the LSVR Link-State information constructions.  

The LSVR working group has only few documents found under the LSVR WG page documents tab.

[Last Updated: March 19, 2019.]
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 has been 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. We're keeping the WG open for a little while longer to see if this draft gels, and also to cover anything else that may come up in the short term. It will not be meeting at IETF 104.

[Last Updated: March 19, 2019.]
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.
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

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) 

SEC Security Area

EdDSA has been published as RFC8420, Split DNS finally managed to get approved by the IESG, and is now in the RFC editor queue. Publication requested has been issued for Implicit IV. Quantum resistance should be ready for IETF last call.

About the new chartered items the ipv6 and ipv4 status codes is progressing nicely, and should be ready for WGLC soon. The labeled IPsec and Intermediate Exchange drafts were adopted as WG documents. The hybrid qske draft already have some implementation experience, and should be adopted as WG draft very soon.

G-DOI IKEv2 work will hopefully start going forward again as there are some external organizations which would like to refer to it. Diet ESP work is still work in progress. We also have one new draft to clean up some entries from the IANA registries, and to make statemenent that IKEv1 is really deprecated.
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.
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

During IETF 104, RMCAT discussed revisions to the congestion control feedback draft based on implementation experience at the hackathon. Coupled congestion control was brought back to the working group based on feedback received at IETF 103 and the chairs are working with the authors to help address the issue. The NADA congestion control algorithm is complete, and ready to go to the IESG. The remaining drafts are resolving minor issues, and should advance shortly.
Following completion of a set of drafts on Explicit Congestion Notifictaion, Working Group Last Calls (WGLC) are expected for work on L4S.  

Work continues on development of SCTP, including replacing RFC 4960.

The working group remains the home for work on UDP.

It is also responsible for maintaining DiffServ, PLPMTUD, and other mechanisms that apply across transport protocols.

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.
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