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

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 8 Mar 2016 22:15:07 +0000

Hello Kaname!

(Chair hat off ...)
Thanks for your draft.  A few clarifying comments:

** Are Sections 3.1 (Distributed Architecture) and 3.2 (Centralized Architecture) presenting new use cases not currently captured in draft-ietf-dots-use-cases-00?

** Is the protocol described in Section 4 intended to be a solution for just the architecture described in Section 3, or generally applicable to all DOTS use cases/requirements?

** Page 3 – 5, Section 2,  In laying out these problems, what new requirements for draft-ietf-dots-requirements-00 are suggested?  Do you see this problems as only applicable to the use cases/architectures described in Section 3?

** Page 6, Section 3, “mitigator” definition.  The text appears to redefine the term “mitigator” that was previously defined in Section 1 of draft-ietf-dots-requirements-01.  Can you please expand upon the “reporting results” capabilities that was added to the term.  Is this draft’s mitigator term referring to the same network element as the requirements document?

** Page 6, Section 3, “flow analyzer” definition.  This term is defined as part of ecosystem, but it is not used again in the document.  Is it needed?

** Page 6 – 8, Section 3.1,  In the distributed architecture, can you clarify why the DOTS server and DOTS client need to be coupled in a controller?  Is the controller a new part of the DOTS architecture that needs to accounted for in the protocol?  Is the introduction of the term “controller” to get around the fact that the current definition of a DOTS server is “network element … [that communicates] the DOTS client’s request to a mitigator”.  Effectively, clients send requests to servers/proxies.  Servers only send requests to mitigators; not other servers?

** Page 9, Section 3.2, “Each ISP controller only communicates with [the orchestrator] for the goal of registering, coordinating, requesting and reporting”.  Are there any other activities that the DOTS client might do beyond those?

** Page 9,  Section 3.2,  Who would be the envisioned operator of an orchestrator?

** Page 9, Section 3.2, “Inter-domain coordination request message[s]” are referenced.  Is that DOTS?  I couldn’t find those messages described in Section 4 of the draft.

** Page 10, Section 4,  Editorial.  The section title is “Inter-domain DOTS Protocol”.  Just checking, is there a missing “intra-domain protocol” aspect?  I’m asking because DOTS is chartered to be inter-domain.

** Page 11, Section 4,  Editorial.  The use of the term “signaling stage” was confusing for me because DOTS has a signal channel and bulk channel, both of which likely apply here.  I’d recommend using a different term for this stage.

** Page 12, Section 4.1.1 (but also applicable to other sections), How is rejected/failed/invalid request signaled by the DOTS server?

** Page 12, Section 4.1.1 (but also applicable to other sections), What HTTP response codes are used for the various responses?

Roman

From: Dots [mailto:[email-masked]] On Behalf Of kaname nishizuka
Sent: Friday, February 19, 2016 9:42 AM
To: [email-masked]
Subject: [Dots] Fwd: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt

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]<mailto:[email-masked]>

To:

Luyuan Fang <[email-masked]><mailto:[email-masked]>, Kaname Nishizuka <[email-masked]><mailto:[email-masked]>, Jinwei Xia <[email-masked]><mailto:[email-masked]>, Dacheng Zhang <[email-masked]><mailto:[email-masked]>, Liang Xia <[email-masked]><mailto:[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: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 9 Mar 2016 06:08:00 +0000

Hi Roman,
Thanks for your comments, please see my reply inline:

B.R.
Frank

发件人: Dots [mailto:[email-masked]] 代表 Roman D. Danyliw
发送时间: 2016年3月9日 6:15
收件人: kaname nishizuka
抄送: [email-masked]
主题: Re: [Dots] Fwd: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt

Hello Kaname!

(Chair hat off ...)

** Are Sections 3.1 (Distributed Architecture) and 3.2 (Centralized Architecture) presenting new use cases not currently captured in draft-ietf-dots-use-cases-00?
[Frank]: Yes, current use cases mainly concern on the distributed architecture. We think the centralized architecture is a new option for consideration.

** Is the protocol described in Section 4 intended to be a solution for just the architecture described in Section 3, or generally applicable to all DOTS use cases/requirements?
[Frank]: Good question. At the beginning, we propose the protocol mainly for achieving the inter-domain coordination for ddos protection. But in general, we think this protocol can also be used for other DOTS use cases. And we believe there should be only one DOTS protocol finally. So, our contribution should be part of it.

** Page 3 – 5, Section 2,  In laying out these problems, what new requirements for draft-ietf-dots-requirements-00 are suggested?  Do you see this problems as only applicable to the use cases/architectures described in Section 3?
[Frank]: Good question. In this part, we try to list all the problems related with the ddos protection coordination. Some of them are general (i.e., Bootstrapping, coordination, provision, etc), some are more specific with inter-domain condition (i.e., near source protection, billing, etc). So, these problems are not only applicable for Section 3 and more broad than it. If necessary, it should be synchronized with the DOTS use cases/requirements drafts.

** Page 6, Section 3, “mitigator” definition.  The text appears to redefine the term “mitigator” that was previously defined in Section 1 of draft-ietf-dots-requirements-01.  Can you please expand upon the “reporting results” capabilities that was added to the term.  Is this draft’s mitigator term referring to the same network element as the requirements document?
[Frank]: Yes, it should be the same term. We will reference the term definition in the requirements drafts.

** Page 6, Section 3, “flow analyzer” definition.  This term is defined as part of ecosystem, but it is not used again in the document.  Is it needed?
[Frank]: I think it’s not yet decided whether DOTS should cover the work related to the interface/protocol of flow analyzer. But in reality, it is widely used for the ddos attack detection.

** Page 6 – 8, Section 3.1,  In the distributed architecture, can you clarify why the DOTS server and DOTS client need to be coupled in a controller?  Is the controller a new part of the DOTS architecture that needs to accounted for in the protocol?  Is the introduction of the term “controller” to get around the fact that the current definition of a DOTS server is “network element … [that communicates] the DOTS client’s request to a mitigator”.  Effectively, clients send requests to servers/proxies.  Servers only send requests to mitigators; not other servers?
[Frank]: From our viewpoint, “The ISP controller should support the functions of DOTS server and DOTS client at the same time in order to participate in the system of inter-domain DDoS protection service.  In other words, as the representative for an ISP's DDoS protective service, the ISP controller manages and provides DDoS mitigation service to its customer in one hand, but may require helps from other ISPs under some situation especially when the attack volume exceeds its capacity or the attack is from other ISPs. ”, especially for the inter-domain ddos protection scenario.

** Page 9, Section 3.2, “Each ISP controller only communicates with [the orchestrator] for the goal of registering, coordinating, requesting and reporting”.  Are there any other activities that the DOTS client might do beyond those?
[Frank]: You are right. This statement is too restrictive. The activities list here is not exhausted, there should be some other activities in the future.

** Page 9,  Section 3.2,  Who would be the envisioned operator of an orchestrator?
[Frank]: some trustworthy third-party operator or organization, or others.

** Page 9, Section 3.2, “Inter-domain coordination request message[s]” are referenced.  Is that DOTS?  I couldn’t find those messages described in Section 4 of the draft.
[Frank]: it should be the mitigation request message in Section 4.

** Page 10, Section 4,  Editorial.  The section title is “Inter-domain DOTS Protocol”.  Just checking, is there a missing “intra-domain protocol” aspect?  I’m asking because DOTS is chartered to be inter-domain.
[Frank]: maybe and not sure right now. It needs more consideration and discussion.

** Page 11, Section 4,  Editorial.  The use of the term “signaling stage” was confusing for me because DOTS has a signal channel and bulk channel, both of which likely apply here.  I’d recommend using a different term for this stage.
[Frank]: Agree. Thanks for the remind and we will be careful of this point and correct it in next version.

** Page 12, Section 4.1.1 (but also applicable to other sections), How is rejected/failed/invalid request signaled by the DOTS server?
[Frank]: in this version, we haven’t specify all the message details. Will complete them in the future work.

** Page 12, Section 4.1.1 (but also applicable to other sections), What HTTP response codes are used for the various responses?
[Frank]: will add these contents in the future work, thanks!

Roman

From: Dots [mailto:[email-masked]] On Behalf Of kaname nishizuka
Sent: Friday, February 19, 2016 9:42 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Fwd: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt

Hi all,

Summary of the draft:

thanks in advance,
kaname

-------- Forwarded Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:     00

Pages:        22

Abstract:

The IETF Secretariat

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Mar 2016 14:04:50 +0700

On 9 Mar 2016, at 13:08, Xialiang (Frank) wrote:

> I’m asking because DOTS is chartered to be inter-domain.

DOTS is intended to function both inter- and intra-domain.  All the 
requirements for inter-domain operation mesh with the requirements for 
intra-domain operation, and vice versa.

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

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 9 Mar 2016 07:48:39 +0000

Roland, agree with your point in general. But not sure if inter-domain and intra-domain have the totally same requirements right now.

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
发送时间: 2016年3月9日 15:05
收件人: [email-masked]
主题: Re: [Dots] Re Fwd: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt

> [Frank]: maybe and not sure right now. It needs more consideration and 

DOTS is intended to function both inter- and intra-domain.  All the requirements for inter-domain operation mesh with the requirements for intra-domain operation, and vice versa.

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Mar 2016 15:02:10 +0700

On 9 Mar 2016, at 14:48, Xialiang (Frank) wrote:

>  But not sure if inter-domain and intra-domain have the totally same 
> requirements right now.

I am.

---

From: Pavel Odintsov <[email-masked]>
Date: Wed, 9 Mar 2016 17:04:21 +0300

Hello!

You have done nice work! I really love json from developer point of view.
We definitely will integrate this draft protocol as proof of concept into
our DDoS mitigation solution.

Do you have reference implementations or some code?

On Fri, Feb 19, 2016 at 5:42 PM, kaname nishizuka <[email-masked]> wrote:

> 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]> <[email-masked]>, Kaname
> Nishizuka <[email-masked]> <[email-masked]>, Jinwei Xia
> <[email-masked]> <[email-masked]>, Dacheng Zhang
> <[email-masked]> <[email-masked]>, Liang Xia
> <[email-masked]> <[email-masked]>
>

-- 
Sincerely yours, Pavel Odintsov

---

From: Kristian Larsson <[email-masked]>
Date: Wed, 9 Mar 2016 15:21:24 +0100

I wonder, have we discussed using YANG to model the messages/RPCs? I'm 
not sure why I haven't brought this up earlier, but it sure would be 
nice to reuse the most popular modelling language IETF has at its disposal.

And just to be clear, I'm not implying a particular transport like 
NETCONF or RESTCONF. Obviously we have very specific requirements in 
there so one might have to invent something new but I don't think this 
prevents using YANG to describe the message content.

Kind regards,
    Kristian.

On 09/03/16 15:04, Pavel Odintsov wrote:
> Hello!
>
> You have done nice work! I really love json from developer point of
> view. We definitely will integrate this draft protocol as proof of
> concept into our DDoS mitigation solution.
>
> On Fri, Feb 19, 2016 at 5:42 PM, kaname nishizuka <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     From: 	[email-masked] <mailto:[email-masked]>
>     To: 	Luyuan Fang <[email-masked]>
>     <mailto:[email-masked]>, Kaname Nishizuka <[email-masked]>
>     <mailto:[email-masked]>, Jinwei Xia <[email-masked]>
>     <mailto:[email-masked]>, Dacheng Zhang
>     <[email-masked]> <mailto:[email-masked]>,
>     Liang Xia <[email-masked]>
>     <mailto:[email-masked]>
>
>
>
>     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:
>     until the htmlized version and diff are available attools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 9 Mar 2016 14:35:22 +0000

Hello!

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
> Sent: Wednesday, March 09, 2016 2:05 AM
> To: [email-masked]
> Subject: Re: [Dots] Re Fwd: New Version Notification for draft-nishizuka-
> dots-inter-domain-mechanism-00.txt
> 

Right.  I misspoke.  DOTS is absolutely chartered to be inter and intra-domain.

I meant to ask whether draft-nishizuka-dots-inter-domain-mechanism-00 is proposing different protocols for each instance -- intra vs. inter.

Roman

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Mar 2016 22:58:25 +0700

On 9 Mar 2016, at 21:35, Roman D. Danyliw wrote:

> I meant to ask whether draft-nishizuka-dots-inter-domain-mechanism-00 
> is proposing different protocols for each instance -- intra vs. inter.

Gotcha.

There are several concerns with this draft, as noted previously.  It 
wasn't apparent that proposing different protocols for inter- vs. 
intra-domain communications was one of those concerns, but perhaps I 
missed something?

Both stateful and stateless transport options should be available for 
both inter- and intra-domain communications, due to local variations in 
network access policies, etc.

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 10 Mar 2016 02:25:51 +0000

Hi Roland,
You understanding is correct. In principle, we hope they both share the same protocols. But it needs more consideration and discussion.
I also agree with your statement about transport protocol choice.

B.R.
Frank

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
发送时间: 2016年3月9日 23:58
收件人: [email-masked]
主题: Re: [Dots] Re Fwd: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt

Gotcha.

There are several concerns with this draft, as noted previously.  It wasn't apparent that proposing different protocols for inter- vs. 
intra-domain communications was one of those concerns, but perhaps I missed something?

Both stateful and stateless transport options should be available for both inter- and intra-domain communications, due to local variations in network access policies, etc.

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 10 Mar 2016 09:30:06 +0700

On 10 Mar 2016, at 9:25, Xialiang (Frank) wrote:

>  But it needs more consideration and discussion.

No, it doesn't.  The requirements are identical.

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 10 Mar 2016 17:59:44 +0900

Hi Pavel,

On 2016/03/09 23:04, Pavel Odintsov wrote:
> Hello!
>
> You have done nice work! I really love json from developer point of view. We definitely will integrate this draft protocol as proof of concept into our DDoS mitigation solution.
>
Thank you!

> Do you have reference implementations or some code?
We'd like to implement it, though, there is no reference implementation yet.
Actually, a part of content of the format is based on an implementation internally used in my service which is using xml format.

best regards,
kaname nishizuka

> On Fri, Feb 19, 2016 at 5:42 PM, kaname nishizuka <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     Subject: 	New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt
>     To: 	Luyuan Fang <[email-masked]> <mailto:[email-masked]>, Kaname Nishizuka <[email-masked]> <mailto:[email-masked]>, Jinwei Xia <[email-masked]> <mailto:[email-masked]>, Dacheng Zhang <[email-masked]> <mailto:[email-masked]>, Liang Xia <[email-masked]> <mailto:[email-masked]>
>
>
>

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 10 Mar 2016 22:17:43 +0000

Hello Frank!

(Chair hat off …)

> From: Dots [mailto:[email-masked]] On Behalf Of Xialiang (Frank)

> 主题: Re: [Dots] Fwd: New Version Notification for draft-nishizuka-dots-

> inter-domain-mechanism-00.txt

[snip]

> ** Page 3 – 5, Section 2,  In laying out these problems, what new

> requirements for draft-ietf-dots-requirements-00 are suggested?  Do you

> see this problems as only applicable to the use cases/architectures described

> in Section 3?

> [Frank]: Good question. In this part, we try to list all the problems related

> with the ddos protection coordination. Some of them are general (i.e.,

> Bootstrapping, coordination, provision, etc), some are more specific with

> inter-domain condition (i.e., near source protection, billing, etc). So, these

> problems are not only applicable for Section 3 and more broad than it. If

> necessary, it should be synchronized with the DOTS use cases/requirements

> drafts.

I think that synchronization would help.  From the problem statement in Section 2, articulating the requirements that they suggest would help clarify the unique needs of these use cases (if any).

[snip]

> ** Page 6, Section 3, “flow analyzer” definition.  This term is defined as part

> of ecosystem, but it is not used again in the document.  Is it needed?

> [Frank]: I think it’s not yet decided whether DOTS should cover the work

> related to the interface/protocol of flow analyzer. But in reality, it is widely

> used for the ddos attack detection.

To clarify, do you mean that the WG hasn't discussed the data channel sufficiently, or that there is an additional element (flow analyzer?) in the DOTS architecture (per the requirements draft) that needs to be described (beyond a client, server, relay and mitigator).

> ** Page 6 – 8, Section 3.1,  In the distributed architecture, can you clarify why

> the DOTS server and DOTS client need to be coupled in a controller?  Is the

> controller a new part of the DOTS architecture that needs to accounted for in

> the protocol?  Is the introduction of the term “controller” to get around the

> fact that the current definition of a DOTS server is “network element … [that

> communicates] the DOTS client’s request to a mitigator”.  Effectively, clients

> send requests to servers/proxies.  Servers only send requests to mitigators;

> not other servers?

> [Frank]: From our viewpoint, “The ISP controller should support the functions

> of DOTS server and DOTS client at the same time in order to participate in the

> system of inter-domain DDoS protection service.  In other words, as the

> representative for an ISP's DDoS protective service, the ISP controller

> manages and provides DDoS mitigation service to its customer in one hand,

> but may require helps from other ISPs under some situation especially when

> the attack volume exceeds its capacity or the attack is from other ISPs. ”,

> especially for the inter-domain ddos protection scenario.

Thanks for the clarification. In figure 1, why are there multiple DOTS clients/servers in ISP 1?  Could there be two servers one client; or two clients and one server; one client and one server?  I'm trying to understand what DOTS considerations exists between what appears to be a tight 1:1 coupling of server/client in the orchestrator.  Like noted above with the flow analyzer, in the view of the draft, is the orchestrator is an additional element of the DOTS architecture?

Roman

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 11 Mar 2016 10:48:38 +0700

On 11 Mar 2016, at 5:17, Roman D. Danyliw wrote:

> or that there is an additional element (flow analyzer?) in the DOTS 
> architecture (per the requirements draft) that needs to be described 
> (beyond a client, server, relay and mitigator).

No - this is just one particular detection/classification/traceback 
mechanism.  As we've discussed previously on this list and in WG 
meetings, the actual mechanisms utilized for 
detection/classification/traceback/mitigation are beyond the scope of 
this WG.

> Thanks for the clarification. In figure 1, why are there multiple DOTS 
> clients/servers in ISP 1?

There certainly could and most likely should be multiple DOTS clients, 
relays, and servers within any organization.

> Like noted above with the flow analyzer, in the view of the draft, is 
> the orchestrator is an additional element of the DOTS architecture?

Per the above, no - that is outside our remit.

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Fri, 11 Mar 2016 05:41:57 +0000

Hi Roman,
Please see my response inline:

发件人: Roman D. Danyliw [mailto:[email-masked]]
发送时间: 2016年3月11日 6:18
收件人: Xialiang (Frank)
抄送: [email-masked]; kaname nishizuka
主题: RE: [Dots] Re Fwd: New Version Notification for draft-nishizuka-dots-inter-domain-mechanism-00.txt

Hello Frank!

(Chair hat off …)

[snip]

[Frank]: Ok, we will do it in next version.

[snip]

[Frank]: I mean both. I hope we can include this part of work in DOTS WG.

[Frank]: Good question. In general, one ISP can have multiple DOTS systems to be responsible for its multiple domains respectively. It can relieve the traffic pressure to one DOTS system in the ISP network, and provide the optimized near-source mitigation in certain level. I also think different deployment ways as you mentioned above can work in various occasions. 1:1 coupling of server/client in the orchestrator is now a simple model but is enough for most occasions. I think the orchestrator should be an additional element for the DOTS architecture.

Roman

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 11 Mar 2016 12:51:28 +0700

> [Frank]: I mean both. I hope we can include this part of work in DOTS 

We can refer to it in deployment examples, but not prescribe it.

> [Frank]: Good question. In general, one ISP can have multiple DOTS 
> systems to be responsible for its multiple domains respectively. It 
> can relieve the traffic pressure to one DOTS system in the ISP 
> network, and provide the optimized near-source mitigation in certain 
> level. I also think different deployment ways as you mentioned above 
> can work in various occasions. 1:1 coupling of server/client in the 
> orchestrator is now a simple model but is enough for most occasions. I 
> think the orchestrator should be an additional element for the DOTS 
> architecture.

Once again, this is something to which we can refer in deployment 
models, but not prescribe.

The purpose of this WG is to design a communications protocol that will 
be useful in most any DDoS mitigation scenario, not to prescribe 
elements beyond those required for the communications protocol itself to 
function (e.g., client, relay, server).

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 11 Mar 2016 13:41:05 +0700

> models, but not prescribe.

To expand this point - an orchestrator can be a DOTS server, relay, 
client, or any combination thereof.

An orchestrator is not in and of itself a necessary or desirable element 
of DOTS.  DOTS must be usable in scenarios where orchestrators are 
present, as well as scenarios in which no orchestrators are involved.

This also applies to flow collectors/analyzers.  They can be DOTS 
servers, relays, clients, or any combination thereof.  They are not 
required elements of DOTS itself.