Shepherd writeup
draft-ietf-dots-signal-channel-25

1. Summary
The document shepherd is Liang Xia. The responsible Area Director is Benjamin Kaduk.
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. The working group has the consensus to publish it as a Proposed Standard since it is a protocol draft, which is stable in technical aspect and enjoy enough community interest to be considered valuable.

2. Review and Consensus
The -00 version of this WG draft has been submitted in 2017-04, and it has fast evolved into its -25 version now. 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 guarantee their consistency. Until now, there are three demo implementations for it (open source go-dots from NTT, two proprietary demos from NCC and Huawei) and several rounds of interop test 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.

This draft firstly specifies the DOTS signal channel messages and the related behaviors (e.g., DOTS mitigation management messages: request, status exchange, withdraw, DOTS signal channel session configuration messages, redirection and heartbeat messages), then defines all the signal channel messages format with YANG data model and their mapping CBOR scheme. Besides, other related issues are also discussed (e.g., (D)TLS protocol profile and AA). Among them, several topics may need further review because of the complexity or importance:
* The definition of 'cuid', 'cdid' and 'mid' parameters for DOTS client/client domain identity and mitigation session, as well as various means of using them together;
* the conflict resolution mechanisms for the mitigation request messages with the overlapping mitigation scope, which can be sent from the same DOTS client or different DOTS clients;
* DOTS heartbeat mechanism and the related NAT traversal consideration;
* DOTS messages YANG data model, and the corresponding CBOR schema mapping.

In summary, this draft has been extensively reviewed and discussed within the working group by mailing list and github, and I believe all technical issues raised have been resolved till this version (-25). So, the latest document is well written and reaches a broad consensus in WG.


3. Intellectual Property
Each author has confirmed conformance with BCPs 78 and 79.  There are no IPR disclosures on the document.

4. Other Points
By performing the idnits check, there are just one minor problem (the referenced WG draft has been updated to next version).

In general, I believe the IANA Considerations are clear and ready. There are totally 4 IANA requests: 
1) a service port number (4646);
2) a new Well-Known URIs registry (dots);
3) a new URI in "IETF XML Registry" (urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel) for a new "YANG Module Names" registry (ietf-signal);
4) the initial DOTS signal channel CBOR mappings registry and the registration template for new CBOR mapping

No early expert review has been requested for the above IANA allocation.

Back