Subject: [Dots] Fwd: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt

From: kaname nishizuka <[email-masked]>
Date: Fri, 19 Feb 2016 23:42:24 +0900

Hi all,

We submitted a new draft regarding to a cooperative DDoS protection.

Summary of the draft:
    As DDoS attack evolves rapidly in the aspect of volume and
    sophistication, cooperation among operators for sharing the capacity
    of the protection system to cope with it becomes very necessary.
    This document describes some possible solutions to the cooperative
    DDoS protection problems.
    The inter-domain protocol (or signaling mechanism) for the goal of
    DDoS protection coordination is the main focus of this document.

We're all happy to have discussions. Any comments and suggestions are welcome.

thanks in advance,
kaname

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt
Date: 	Fri, 19 Feb 2016 06:32:13 -0800
From: 	[email-masked]
To: 	Luyuan Fang <[email-masked]>, Kaname Nishizuka <[email-masked]>, Jinwei Xia <[email-masked]>, Dacheng Zhang <[email-masked]>, Liang Xia <[email-masked]>

A new version of I-D, draft-nishizuka-dots-inter-domain-mechanism-00.txt
has been successfully submitted by Kaname Nishizuka and posted to the
IETF repository.

Name:		draft-nishizuka-dots-inter-domain-mechanism
Revision:	00
Title:		Inter-domain cooperative DDoS protection problems and mechanism
Document date:	2016-02-19
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-nishizuka-dots-inter-domain-mechanism-00.txt
Status:         https://datatracker.ietf.org/doc/draft-nishizuka-dots-inter-domain-mechanism/
Htmlized:       https://tools.ietf.org/html/draft-nishizuka-dots-inter-domain-mechanism-00

Abstract:
    As DDoS attack evolves rapidly in the aspect of volume and
    sophistication, cooperation among operators for sharing the capacity
    of the protection system to cope with it becomes very necessary.
    This document describes some possible solutions to the cooperative
    inter-domain DOTS problems.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 20 Feb 2016 00:03:17 +0700

On 19 Feb 2016, at 21:42, kaname nishizuka wrote:

> Any comments and suggestions are welcome.

This draft is partially or wholly duplicative of 
draft-ietf-dots-use-cases-00, draft-ietf-dots-requirements-00, and 
draft-reddy-dots-transport-02; it is overly prescriptive (e.g., talk 
about flow telemetry); premature (e.g., talk about JSON, certs, message 
formats, and so forth); incomplete (doesn't mention relays at all); and 
contains factually incorrect statements (e.g., that provisioning must 
take place prior to an attack; in point of fact, one of the rationales 
for DOTS is that it allows for dynamic registration and 
auto-provisioning even during an attack).

Have the submitters been following the discussions around the three 
drafts mentioned above?

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: kaname nishizuka <[email-masked]>
Date: Tue, 23 Feb 2016 11:21:51 +0900

Hi Roland,

I appreciate your comments.
We are following discussions about those drafts on the ML,
then, we thought that the problems of cooperative DDoS protection are not documented clearly so far.
Thus we wrote that part in our draft and included mechanism part straightforwardly.
The comparison between centralized and distributed architecture of coordination of DDoS protection service providers is useful especially for operators and will be on the track of discussion in course of time.
Our draft is not intended to bypass the existing drafts but to extend important discussion points for specification.

thank you,
kaname

On 2016/02/20 2:03, Roland Dobbins wrote:
> This draft is partially or wholly duplicative of draft-ietf-dots-use-cases-00, draft-ietf-dots-requirements-00, and draft-reddy-dots-transport-02; it is overly prescriptive (e.g., talk about flow telemetry); premature (e.g., talk about JSON, certs, message formats, and so forth); incomplete (doesn't mention relays at all); and contains factually incorrect statements (e.g., that provisioning must take place prior to an attack; in point of fact, one of the rationales for DOTS is that it allows for dynamic registration and auto-provisioning even during an attack).
>
> Have the submitters been following the discussions around the three drafts mentioned above?
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 24 Feb 2016 15:52:31 +0700

On 23 Feb 2016, at 9:21, kaname nishizuka wrote:

> Our draft is not intended to bypass the existing drafts but to extend 
> important discussion points for specification.

It does not accomplish this goal, IMHO.  Instead, it makes several 
unwarranted assumptions and factually incorrect statements about both 
the current state of DDoS mitigation and the projected enhancements to 
DDoS mitigation which are the goal of the DOTS WG.