Skip to main content

Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
RFC 8783

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc:, The IESG <>,,, Roman Danyliw <>,,,
Subject: Protocol Action: 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification' to Proposed Standard (draft-ietf-dots-data-channel-31.txt)

The IESG has approved the following document:
- 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Data
   Channel Specification'
  (draft-ietf-dots-data-channel-31.txt) as Proposed Standard

This document is the product of the DDoS Open Threat Signaling Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

   This document specifies the DOTS data channel, one of two protocols
   (the other being the DOTS signal channel --
   draft-ietf-dots-signal-channel) that enables the exchange of
   information necessary to mitigate a DDoS attack.  This data channel
   protocol allows the exchange of information that is not appropriate
   to send under attack conditions.

   This is a companion document to the DOTS signal channel

Working Group Summary

   This document received substantial feedback from a WGLC initiated on
   the -18, leading up to the publication of several revisions through
   -21.  The shpeherd review produced further feedback for the -22 and
   the WG has been active in following subsequent updates stemming from
   AD review, directorate reviews, and last-call reviews.

Document Quality

   There have been three implementations of the draft, one open source
   and two proprietary from the following vendors:
   ** go-dots (NTT) --
   ** NCC Group
   ** Huawei

   Older versions of the draft were used in interops at the Hackathons
   of IETF 100 and 101 to enable end-to-end testing for DOTS agents.  At
   the IETF 102 Hackathon, there was an inter-op specifically focused on
   testing between these three implementations per the -16 of the draft.
   Identified issues were fixed in draft versions -17 and -18.

   There was early coordination with the NETCONF WG for the usage of ACL
   YANG modules.


   The document shepherd is Roman Danyliw. The responsible Area Director
   is Benjamin Kaduk.

RFC Editor Note

RFC Editor Note

In Section 3.4, in the text:

     o  Otherwise, the DOTS agent MUST update or insert the "Via" header
        by appending its own information.

please replace "header" with "header field".