Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: draft-ietf-dots-signal-channel@ietf.org, The IESG <iesg@ietf.org>, dots@ietf.org, frank.xialiang@huawei.com, kaduk@mit.edu, dots-chairs@ietf.org, rfc-editor@rfc-editor.org, Liang Xia <frank.xialiang@huawei.com>
Subject: Protocol Action: 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification' to Proposed Standard (draft-ietf-dots-signal-channel-41.txt)

The IESG has approved the following document:
- 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
   Channel Specification'
  (draft-ietf-dots-signal-channel-41.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:

Technical Summary

    This document specifies the DOTS signal channel, a protocol for signaling
    the need for protection against Distributed Denial-of-Service (DDoS)
    attacks to a server capable of enabling network traffic mitigation on
    behalf of the requesting client.
    This is a companion document to the DOTS data channel specification.

Working Group Summary
    This draft has been extensively reviewed and discussed within the
    working group by mailing list and github.  The latest document is
    well written and reaches a broad consensus in WG.

Document Quality

   The co-authors are from some of the leading vendors and operators in
   DDoS protection industry with extensive experience with the related
   technologies and implementations; they are also the core authors of
   the DOTS requirements WG drafts, which guarantees consistency between
   the core DOTS protocol documents.  Until now, there are three demo
   implementations for it (open source go-dots from NTT and two
   proprietary demos from NCC and Huawei), and several rounds of interop
   tests during IETF hackathon activities. All the technical issues
   identified by these demos and the finished tests have been addressed
   and reflected into the latest draft, which are very helpful for the
   completeness and quality improvement of the draft.

   IANA port number expert review is ongoing; the expert is seeking
   additional justification that a dedicated port is needed, which has
   been provided by the document authors.


    The document shepherd is Liang Xia. The responsible Area Director is
    Benjamin Kaduk.