[Dots] draft-ietf-dots-signal-channel-25 has been submitted for IESG processing, and the ID shepherd has been written up:

"Xialiang (Frank, Network Integration Technology Research Dept)" <frank.xialiang@huawei.com> Thu, 20 September 2018 06:04 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2271E130DDC for <dots@ietfa.amsl.com>; Wed, 19 Sep 2018 23:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiq2eV25sJCP for <dots@ietfa.amsl.com>; Wed, 19 Sep 2018 23:04:42 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF16130DC4 for <dots@ietf.org>; Wed, 19 Sep 2018 23:04:42 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D2025BE52F531 for <dots@ietf.org>; Thu, 20 Sep 2018 07:04:38 +0100 (IST)
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 20 Sep 2018 07:04:21 +0100
Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.211]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0399.000; Thu, 20 Sep 2018 14:04:16 +0800
From: "Xialiang (Frank, Network Integration Technology Research Dept)" <frank.xialiang@huawei.com>
To: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: draft-ietf-dots-signal-channel-25 has been submitted for IESG processing, and the ID shepherd has been written up:
Thread-Index: AdRQp1HOTbmwF7rpR1qNGVmqbZnHZA==
Date: Thu, 20 Sep 2018 06:04:15 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12C86BCD2@dggemm511-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.159.76]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12C86BCD2dggemm511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/22_FGQms6gQL4LNSkmjN0Q-w__U>
Subject: [Dots] draft-ietf-dots-signal-channel-25 has been submitted for IESG processing, and the ID shepherd has been written up:
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Sep 2018 06:04:45 -0000

Hi all,
The ID shepherd is as below:


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.


Thanks!

B.R.
Frank