Subject: [Dots] AD review of draft-ietf-dots-use-cases-17

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 Jul 2019 17:36:54 -0500

First off, a few housekeeping items:

(1) This document lists seven authors, and per RFC 7322 I/the IESG needs
to specially consider this and essentially make an exception to have
more than five authors.  Can you please confirm that all listed authors
have made substantial contributions, so that I can take that to the IESG
and get it approved?

(2) The shepherd writeup indicates that three authors (Stefan, Bob, and
Nik) have not indicated conformance with BCPs 78 and 79.  I don't think
I can issue the IETF LC until that gets straightened out, so please
confirm that we're all squared away!

(3) Recently the IESG has been trying to exert some gentle backpressure
against publishing Informational use-cases/requirements drafts, when they
serve only as input to future protocol specifications and do not have
lasting archival value on their own.  I do see in the shepherd writeup that
the working group did reach consensus to publish this document and think
there's enough value in it to be worth publishing; I just mention this so
that people aren't surprised if the IESG evaluation comes back with
questions about whether we should be publishing the document at all.

Other than those, the document is generally in good shape; there's just
a few substantive questions buried in the editorial nits.

On to the section-by-section comments:

Section 2

   o  DDoS Mitigation Service: designates a DDoS mitigation service
      provided to a customer and which is scoped to mitigate DDoS
      attacks.  [...]

I don't really think that using the lowercase-'s' version to define the
uppercase-'S' version of the term is going to help anyone.

Section 3.1

It's a little surprising that we have the two bullet points near the top
about the enterprise DMS acting as a DOTS client for the first kind of
service but as a DOTS server for the second kind, but then we never seem
to talk about that second kind of service again in the document.
Perhaps we should just explicitly say that it's similar to the first
kind and not covered further?

   When the enterprise DMS detects an inbound DDoS attack targeting its
   resources ( e.g. servers, hosts or applications), it immediately
   begins a DDoS Mitigation.

I'd consider clarifying that this mitigation is entirely local within
the enterprise, so that contacting the ITP in the next step is a clear
escalation.

   related information.  Once the DDoS attack has ended, or decreased to
   the certain level that the DOTS client can handle by itself, the DOTS
   server signals the enterprise DMS DOTS client that the attack has
   subsided.

I think it's the enterprise DMS that is handling the attack, not the
DOTS client directly...

   The enterprise DMS then requests the ITP to terminate the DDoS
   Mitigation.  The DOTS server on the ITP receives this request and

... but this one is the DOTS client.

   o  (a) A DDoS attack is initiated against resources of a network
      organization which has deployed a DOTS-capable DMS - typically a
      DOTS client.

We probably want to reiterate in a parenthetical "network organization
(here, the enterprise)" the terminology we're using.

   o  (d) The DOTS server which receives the DOTS Mitigation request
      determines that it has been configured to honor requests from the
      requesting DOTS client, and honored its DDoS Mitigation by
      orchestrating its DMS.

nit: I think s/honored/honors/ to stay in the present tense.

   o  (e) While the DDoS Mitigation is active, DOTS server regularly
      transmits DOTS DDoS Mitigation status updates to the DOTS client.

nit: "the DOTS server" or "servers regularly transmit".

Section 3.2

   As such, this use case likely to match large enterprises or large
   data centers, but not exclusively.  [...]

nit: "is likely"

   In this scenario, an Enterprise Network has entered into a pre-
   arranged DDoS mitigation assistance agreement with one or more other
   DDoS Mitigation Service Providers in order to ensure that sufficient
   DDoS mitigation capacity and/or capabilities may be activated in the
   event that a given DDoS attack threatens to overwhelm the ability of
   a given DMS to mitigate the attack on its own.

We could perhaps say "overwhelm the ability of the enterprise's or any
other given DMS" since in most cases the enterprise DMS is the one at
risk of first being overwhelmed.

Is the fact that the C<-->S DOTS traffic does not go through the ITP in
Figure 3 an intentional change from Figure 2 (in that they are expected
to be communicating "out of band" or not through the enterprise's normal
transit)?  Some readers might see this and get confused if this
communication is still supposed to be going along the regular transit
path.

Section 3.3

   In this use case, one or more DDoS telemetry systems or monitoring
   devices monitor a network - typically an ISP network, an Enterprise
   network, or a data center.  Upon detection of a DDoS attack, these
   DDoS telemetry systems alert an orchestrator in charge of
   coordinating the various DMS within the domain.  [...]

nit: do we have a standard plural form for "DMS"?  (Is it just "DMS"?)

   ITP.  DDoS Mitigation System selection and DDoS Mitigation technique
   may depends on the type of DDoS attack.  In some case, a manual

nit: "techniques" plural

   The communication between a network administrator and the
   orchestrator is also performed using DOTS.  The network administrator
   via its web interfaces implements a DOTS client, while the
   Orchestrator implements a DOTS server.

nit: as written, this is saying that the network administrator has a
web interface.  I think "its" is supposed to refer to something else.

nit: Figure 4 lists "DDoS mitigation systems" in both the interprise and
the ITP, but only the enterprise side has a "stack" of boxes to indicate
there is more than one.

   These systems are configured so that when an event or some
   measurement indicators reach a predefined level to send DOTS
   mitigation request to the orchestrator.  The DOTS mitigation request

nit: the grammar here is a bit off; I think s/to send DOTS mitigation
request/they send a DOTS mitigation request/ would fix it.

   Upon receipt of the DOTS mitigation request from the DDoS telemetry
   system, the orchestrator responds with an acknowledgment, to avoid
   retransmission of the request for mitigation.  The orchestrator may
   begin collecting additional fined grain and specific information from

nit: "fine-grained"

   and provide an analysis of the event.  Eventually, the orchestrator
   may ask additional information to the DDoS telemetry system, however,
   the collection of these information is out of scope.

nit: s/ask additional information to/ask for additional information
from/
nit: semicolon before "however" instead of comma
nit: "this information"

   Upon receiving a request to mitigate a DDoS attack performed over a
   target, the orchestrator, may evaluate the volumetry of the attack as

nit: no comma after "the orchestrator"

   well as the value that represent the target.  The orchestrator may

nit: "the value that the target represents"

                          When DDoS Mitigation is requested, the status
   indicates the DDoS Mitigation is starting while not effective.  The
   DOTS client of the orchestrator will later be notified that the DDoS
   Mitigation is effective.

I'm not entirely sure what this last sentence is trying to say.

   Orchestration of the DDoS mitigation systems works similarly as
   described in Section 3.1.  The orchestrator indicates with its status
   whether the DDoS Mitigation is effective.

Is this intended to specifically refer to the external (ITP) DMS?

Also, my understanding is that for this interaction the orchestrator is
acting as a DOTS client, but the rest of the document only has status
messages being generated by the DOTS server.  Am I confused?

Section 4

It feels incomplete to list three primary attacks but only discuss
mitigations for two of them.  Perhaps "preconfigured mitigation steps to
take on the loss of keepalive traffic can partially mitigate signal
blocking, but in general it is impossible to comprehensively defend
against an attacker that can selectively block any or all traffic".

Section 6

Is Med's name spelled correctly?

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Jul 2019 15:29:07 -0500

> confirm that we're all squared away!

Oops, I didn't find
https://mailarchive.ietf.org/arch/msg/dots/M7gWTMUWUB8X6niaYCimlN127fE
until after I posted the initial review.  Thanks, Nik!

-Ben

---

From: <[email-masked]>
Date: Thu, 4 Jul 2019 14:11:27 +0000

Hi Ben, all,

Please see one comment inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Benjamin Kaduk
> Envoyé : mercredi 3 juillet 2019 00:37
> À : [email-masked]
> Cc : [email-masked]
> Objet : [Dots] AD review of draft-ietf-dots-use-cases-17
> 

[Med] FWIW, the WG discussed this point early in the process and made a decision to publish. Please check https://mailarchive.ietf.org/arch/msg/dots/l0phQdpmSc4j6XhfxUyx-lrrDzk. This pointer may be added to the write-up, IMO.

---

From: Nik Teague <[email-masked]>
Date: Thu, 04 Jul 2019 16:00:32 +0000

Hi,

I thought I had issued this already but if not - I am not aware of any IPR in relation to this draft.

Thanks,

-Nik

-------- Original Message --------
On 2 Jul 2019, 23:36, Benjamin Kaduk wrote:

> (1) This document lists seven authors, and per RFC [7322](tel:7322) I/the IESG needs
> .... but this one is the DOTS client.
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Nik Teague <[email-masked]>
Date: Thu, 04 Jul 2019 16:04:54 +0000

Hi,

The extended number of authors was assigned by the chairs, however, all contributed significantly IMO.

Thanks,

-Nik

---

From: Daniel Migault <[email-masked]>
Date: Thu, 4 Jul 2019 16:13:38 -0400

Hi,

Thank you for the review. Please find my response in line as well as on the
git repo [1].  WG, co-authors, please review section 3.3 by Friday EOB.

In summary we addressed all comments, major changes are:

a) Figure 2 with a channel from DOTS client and DOTS server with th
eaddition of the following text:
"""
In some cases the communication between the enterprise DOTS client and
the DOTS server of the DDoS Mitigation Service Provider may go through
the ITP carrying the DDoS attack, which would affect the
communication. On the other hand, the communication between the DOTS
client and DOTS server may take a path that is not undergoing a DDoS
attack.
"""

b) telemetry

We clarified DOTS client/server involved.

c) it was unclear to me how to address the following comment.

> <mglt>
What we are trying to say is that the network administrator sees its web
interface, and instruct the DOTS client from that interface. I have not
made any change to address that concern, as I do not clearly see what is
confusing.
</mglt>

Yours,
Daniel

[1]
https://github.com/dotswg/dots-use-cases/commit/e251fb8abb51ba0c68471e847037daf2e81d38aa

> uppercase-'S' version of the term is going to help anyone.
<mglt>
The text has been replaced by the following:

* DDoS Mitigation Service: designates a service provided to a
customer to mitigate DDoS attacks.  Services usually involve Service
Level Agreement (SLA) that have to be met.  It is the responsibility of
the DDoS Service provider to instantiate the DDoS Mitigation System to
meet these SLAs.

</mglt>

> <mglt>
I agree that could be mentioned explicitly. Here is the proposed text to
address that concern.

 The two scenarios, thought different, have similar interactions between
the DOTS client and server. For the sake of simplicity, only the first
scenario will be detailed in this section.
</mglt>

> <mglt>
To address the concern we specify that the mitigation is handled locally as
well as we explicitly indicate the escalation procedure.  I believe the
following text address your concern:

When the enterprise DMS locally detects an inbound DDoS attack targeting
its resources ( e.g. servers, hosts or applications), it immediately
begins a DDoS Mitigation.

During the course of the attack, the inbound traffic volume exceeds the
50% threshold and the enterprise DMS escalates the DDoS mitigation.  The
enterprise DMS DOTS client signals the DOTS server on the upstream ITP
to initiate DDoS Mitigation. The DOTS server signals the DOTS client
that it can serve this request, and mitigation is initiated on the ITP
network by the ITP DMS.
</mglt>

> I think it's the enterprise DMS that is handling the attack, not the
<mglt>
This is correct. This has been corrected as follows:

Over the course of the attack, the DOTS server of the ITP periodically
informs the DOTS client on the enterprise DMS mitigation status,
statistics related to DDoS attack traffic mitigation, and related
information. Once the DDoS attack has ended, or decreased to the certain
level that the enterprise DMS can handle by itself, the DOTS server
signals the enterprise DMS DOTS client that the attack has subsided.
</mglt>

> <mglt>

Yes we sometime probably abused metonymy, but I agree the more specific
the better. I believe the following text is clarifying.

The DOTS client on the enterprise DMS then requests the ITP to terminate
the DDoS Mitigation. The DOTS server on the ITP receives this request
and once the mitigation has ended, confirms the end of upstream DDoS
Mitigation to the enterprise DMS DOTS client.

</mglt>

> <mglt>
Here is the current text:

* (a) A DDoS attack is initiated against resources of a
network organization (here, the enterprise) which has deployed a
DOTS-capable DMS - typically a DOTS client.
</mglt>

> <mglt>
I agree. here is the proposed text:

* (d) The DOTS server which receives the DOTS Mitigation request
determines that it has been configured to honor requests from the
requesting DOTS client, and honors its DDoS Mitigation by orchestrating
its DMS.

</mglt>

> <mglt>
I agree, here is the corrected text:

* (e) While the DDoS Mitigation is active, the DOTS server
regularly transmits DOTS DDoS Mitigation status updates to the DOTS
client.
</mglt>

> <mglt>
This has been added as follows:

As such, this use case is
likely to match large enterprises or large data centers, but not
exclusively.
</mglt>

> <mglt>
I agree that is better. Here is the modified text:

In this scenario, an Enterprise Network has entered into a pre-arranged
DDoS mitigation assistance agreement with one or more other DDoS
Mitigation Service Providers in order to ensure that sufficient DDoS
mitigation capacity and/or capabilities may be activated in the event
that a given DDoS attack threatens to overwhelm the ability of the
enterprise's or any other given DMS to mitigate the attack on its own.
</mglt>

> <mglt>
The intention was to indicate the DDoS Mitigation Service Provider is not
the upstream ITP and thus communication MAY have to transit through the
ITP.  I understand from your comment that it might be interpreted as the
communication MUST go through the ITP.

I propose to have the DMS communicating directly via a distinct channel and
mention explicitly that the DOTS channel MAY transit via the ITP or may use
a dedicated path.

Here is the updated figure and the additional text:

       +------------------+        +------------------+
       | Enterprise       |        | Upstream         |
       | Network          |        | Internet Transit |
       |                  |        | Provider         |
       |      +--------+  |        |             DDoS Attack
       |      | DDoS   |  | <=================================
       |      | Target |  | <=================================
       |      +--------+  |        |                  |
       |                  |        |                  |
       |                  |        +------------------+
       |                  |
       |                  |        +------------------+
       |                  |        | DDoS Mitigation  |
       |                  |        | Service Provider |
       |                  |        |                  |
       |  +------------+  |        |  +------------+  |
       |  | DDoS       |<------------>| DDoS       |  |
       |  | Mitigation |C |        | S| Mitigation |  |
       |  | System     |  |        |  | System     |  |
       |  +------------+  |        |  +------------+  |
       +------------------+        +------------------+

           * C is for DOTS client functionality
           * S is for DOTS server functionality

       Figure 2: DDoS Mitigation between an Enterprise Network and Third
                 Party DDoS Mitigation Service Provider

[...]

In some cases the communication between the enterprise DOTS client and
the DOTS server of the DDoS Mitigation Service Provider may go through
the ITP carrying the DDoS attack, which would affect the
communication. On the other hand, the communication between the DOTS
client and DOTS server may take a path that is not undergoing a DDoS
attack.

</mglt>

> <mglt>
Seems that DMS's is more appropriated. This has been changed.

Upon detection of a DDoS attack, these DDoS
telemetry systems alert an orchestrator in charge of coordinating the
various DMS's within the domain.

</mglt>

> <mglt>
Corrected:

DDoS Mitigation System selection and DDoS Mitigation techniques may
depends on the type of DDoS attack.
</mglt>

> <mglt>
What we are trying to say is that the network administrator sees its web
interface, and instruct the DOTS client from that interface. I have not
made any change to address that concern, as I do not clearly see what is
confusing.
</mglt>

> the ITP, but only the enterprise side has a "stack" of boxes to indicate
 <mglt>
Both have two DMS's now.

</mglt>

> <mglt>
Thanks. This has been corrected accordingly:

These systems are configured so that when an event or some measurement
indicators reach a predefined level they send a DOTS mitigation request
to the orchestrator.

</mglt>

> <mglt>
Thanks for the nits. All have been addressed in the text below:

The orchestrator may
begin collecting additional fine-grained and specific information from
various  DDoS telemetry systems in order to correlate the measurements
and provide an analysis of the event. Eventually, the orchestrator may
ask for additional information from the DDoS telemetry system; however,
the collection of this information is out of scope.

</mglt>

> <mglt>
The text has been corrected as follows:
Upon receiving a request to mitigate a DDoS attack performed over a
target, the orchestrator may evaluate the volumetry of the attack as
well as the value that the target represents.
</mglt>

> <mglt>
Initially, I believe we wanted to distinguish between accepting the
mitigation and having the mitigation effective. I do not think that
necessary here as such details are provided in section 3.1.

The orchestrator requests a DDoS Mitigation to the selected
DDoS mitigation systems via its DOTS client, as described in Section
3.1.
</mglt>

> <mglt>
We did not see any differences between the DMS. I believe that the text
above clarify the DMS is the one selected by the orchestrator.

</mglt>

> messages being generated by the DOTS server.  Am I confused?
<mglt>
The orchestrator got DOTS client and DOTS servers. I updated the section to
clarify which entity is involved in term of DOTS. I believe that clarifies
the concern.

</mglt>

> <mglt>
Just added this sentence.
</mglt>

> <mglt>
Now it is spelt correctly! Thanks.
</mglt>

---

From: <[email-masked]>
Date: Fri, 5 Jul 2019 06:01:15 +0000

Hi Daniel,

FWIW, changes to fix some nits can be found at:

https://github.com/dotswg/dots-use-cases/pull/10/files

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Daniel Migault
Envoyé : jeudi 4 juillet 2019 22:14
À : Benjamin Kaduk
Cc : [email-masked]; dots
Objet : Re: [Dots] AD review of draft-ietf-dots-use-cases-17

Hi,

Thank you for the review. Please find my response in line as well as on the git repo [1].  WG, co-authors, please review section 3.3 by Friday EOB.

a) Figure 2 with a channel from DOTS client and DOTS server with th eaddition of the following text:
"""

b) telemetry

nit: as written, this is saying that the network administrator has a
web interface.  I think "its" is supposed to refer to something else.
<mglt>
What we are trying to say is that the network administrator sees its web interface, and instruct the DOTS client from that interface. I have not made any change to address that concern, as I do not clearly see what is confusing.
</mglt>

Yours,
Daniel

[1] https://github.com/dotswg/dots-use-cases/commit/e251fb8abb51ba0c68471e847037daf2e81d38aa

On Tue, Jul 2, 2019 at 6:37 PM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:
First off, a few housekeeping items:

Section 2

Section 3.1

I agree that could be mentioned explicitly. Here is the proposed text to address that concern.

I'd consider clarifying that this mitigation is entirely local within
the enterprise, so that contacting the ITP in the next step is a clear
escalation.
<mglt>
To address the concern we specify that the mitigation is handled locally as well as we explicitly indicate the escalation procedure.  I believe the following text address your concern:

..... but this one is the DOTS client.
<mglt>

Section 3.2

nit: "is likely"
<mglt>

The intention was to indicate the DDoS Mitigation Service Provider is not the upstream ITP and thus communication MAY have to transit through the ITP.  I understand from your comment that it might be interpreted as the communication MUST go through the ITP.

I propose to have the DMS communicating directly via a distinct channel and mention explicitly that the DOTS channel MAY transit via the ITP or may use a dedicated path.

[...]

</mglt>

Section 3.3

</mglt>

nit: "techniques" plural
<mglt>
Corrected:

nit: as written, this is saying that the network administrator has a
web interface.  I think "its" is supposed to refer to something else.
<mglt>
What we are trying to say is that the network administrator sees its web interface, and instruct the DOTS client from that interface. I have not made any change to address that concern, as I do not clearly see what is confusing.
</mglt>

</mglt>

</mglt>

nit: "fine-grained"

The orchestrator may

I'm not entirely sure what this last sentence is trying to say.
<mglt>
Initially, I believe we wanted to distinguish between accepting the mitigation and having the mitigation effective. I do not think that  necessary here as such details are provided in section 3.1.

Is this intended to specifically refer to the external (ITP) DMS?
<mglt>
We did not see any differences between the DMS. I believe that the text above clarify the DMS is the one selected by the orchestrator.

</mglt>

<mglt>
The orchestrator got DOTS client and DOTS servers. I updated the section to clarify which entity is involved in term of DOTS. I believe that clarifies the concern.

</mglt>
Section 4

Thanks,

Ben

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

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 5 Jul 2019 16:21:41 +0900

Hi Daniel,

Thank you for the correction and clarification.

 > WG, co-authors, please review section 3.3 by Friday EOB.
I've reviewed it.
DOTS client/server involved was clarified and how the DDoS Orchestration usecase work is described as it was originally intended.

nit: (Line 539, 540)
The orchestrator implements a DOTS Client while the DDoS mitigation systems implement a DOTS Server.
Client->client, Server->server

thanks!
Kaname Nishizuka

On 2019/07/05 5:13, Daniel Migault wrote:
> On Tue, Jul 2, 2019 at 6:37 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Daniel Migault <[email-masked]>
Date: Fri, 5 Jul 2019 08:23:05 -0400

Thanks Med! Just merged them!
Yours,
Daniel

On Fri, Jul 5, 2019 at 2:01 AM <[email-masked]> wrote:

> *De :* Dots [mailto:[email-masked]] *De la part de* Daniel Migault
> *Envoyé :* jeudi 4 juillet 2019 22:14
> *À :* Benjamin Kaduk
> *Cc :* [email-masked]; dots
> *Objet :* Re: [Dots] AD review of draft-ietf-dots-use-cases-17
>
>
>
> Hi,
>
>
>
> Thank you for the review. Please find my response in line as well as on
> the git repo [1].  WG, co-authors, please review section 3.3 by Friday EOB.
>
>
>
> To address the concern we specify that the mitigation is handled locally
> as well as we explicitly indicate the escalation procedure.  I believe the
> I propose to have the DMS communicating directly via a distinct channel
> and mention explicitly that the DOTS channel MAY transit via the ITP or may
> use a dedicated path.
>
>
>
> The orchestrator got DOTS client and DOTS servers. I updated the section
> to clarify which entity is involved in term of DOTS. I believe that
> clarifies the concern.
>
>
>
> </mglt>
>
> Section 4
>

---

From: Daniel Migault <[email-masked]>
Date: Fri, 5 Jul 2019 08:23:50 -0400

Thanks, just pushed the update.
Yours,
Daniel

On Fri, Jul 5, 2019 at 3:21 AM kaname nishizuka <[email-masked]> wrote:

> DOTS client/server involved was clarified and how the DDoS Orchestration
> usecase work is described as it was originally intended.
>
> nit: (Line 539, 540)

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 5 Jul 2019 09:06:59 -0400

Sorry that I cannot review this until Wednesday.  Family in for the 
weekend and cataract surgery (2nd eye) Monday.  It is amazing how 
cataract surgery is 'no big deal' compared to when my parents had it 
done.  20 min under the knife and back in business (except for the eye 
drops for a week) in 24 hours.

I suspect that you all caught all the nits that need to be fixed.

Have a good weekend and check out the hotRFC I am helping out with.

On 7/5/19 8:23 AM, Daniel Migault wrote:
> On Fri, Jul 5, 2019 at 3:21 AM kaname nishizuka <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Daniel,
>
>     DOTS client/server involved was clarified and how the DDoS
>     Orchestration usecase work is described as it was originally intended.
>
>     nit: (Line 539, 540)
>     The orchestrator implements a DOTS Client while the DDoS
>     mitigation systems implement a DOTS Server.
>>     Thank you for the review. Please find my response in line as well
>>     as on the git repo [1].  WG, co-authors, please review section
>>     3.3 by Friday EOB.
>>
>>     What we are trying to say is that the network administrator sees
>>     its web interface, and instruct the DOTS client from that
>>     interface. I have not made any change to address that concern, as
>>     I do not clearly see what is confusing.
>>     </mglt>
>>
>>
>>     Yours,
>>     Daniel
>>
>>     [1]
>>     To address the concern we specify that the mitigation is handled
>>     locally as well as we explicitly indicate the escalation
>>     procedure.  I believe the following text address your concern:
>>
>>     The intention was to indicate the DDoS Mitigation Service
>>     Provider is not the upstream ITP and thus communication MAY have
>>     to transit through the ITP. I understand from your comment that
>>     it might be interpreted as the communication MUST go through the
>>     ITP.
>>
>>     I propose to have the DMS communicating directly via a distinct
>>     channel and mention explicitly that the DOTS channel MAY transit
>>     via the ITP or may use a dedicated path.
>>
>>     What we are trying to say is that the network administrator sees
>>     its web interface, and instruct the DOTS client from that
>>     interface. I have not made any change to address that concern, as
>>     I do not clearly see what is confusing.
>>     </mglt>
>>
>>     measurement
>>     Initially, I believe we wanted to distinguish between accepting
>>     the mitigation and having the mitigation effective. I do not
>>     think that  necessary here as such details are provided in
>>     section 3.1.
>>
>>     We did not see any differences between the DMS. I believe that
>>     the text above clarify the DMS is the one selected by the
>>     orchestrator.
>>     </mglt>
>>
>>     The orchestrator got DOTS client and DOTS servers. I updated the
>>     section to clarify which entity is involved in term of DOTS. I
>>     believe that clarifies the concern.
>>
>>     </mglt>
>>
>>         Section 4
>>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Jul 2019 19:40:32 -0500

> made any change to address that concern, as I do not clearly see what is

I don't think anyone is actually confused about the meaning; this was just
a pedantic comment about the grammar.  "its web interface"  has to belong
to something/someone, and with the current wording we are forced to parse
the sentence as "the network administrator's web interface", which is
surprising since a network administrator is a human and a web interface is
usually provided by a webserver.  Perhaps we want to say "The network
administrator uses a web interface that implements a DOTS client"?

-Ben

---

From: Daniel Migault <[email-masked]>
Date: Fri, 12 Jul 2019 08:12:05 -0400

Thanks for the follow up Ben. So I think your concern has been addressed by
other changes in the document.
Though I am not saying I do not introduced other nits of the same kind, I
checked throughout the document
and I believe any time web interface is mentioned it is currenlty clear it
does not belong to the network admin.

Maybe some english native co-authors could do a last proof-reading of the
document to remove these sort of nits.
the cuurent version is at:

The current text is:

"""
The analysis from the
orchestrator is reported to the network administrator via a web
interface. If the network administrator decides to start the
mitigation, the network administrator triggers the DDoS mitigation
request using the web interface of a DOTS client communicating to the
orchestrator DOTS server. This request is expected to be associated with
a context that provides sufficient information to the orchestrator DOTS
server to infer the DDoS Mitigation to elaborate and coordinate.
"""

Yours,
Daniel

---

From: Daniel Migault <[email-masked]>
Date: Fri, 12 Jul 2019 08:13:50 -0400

wit the link:
https://github.com/dotswg/dots-use-cases

Yours,
Daniel

On Fri, Jul 12, 2019 at 8:12 AM Daniel Migault <[email-masked]>
wrote:

> Thanks for the follow up Ben. So I think your concern has been addressed
> by other changes in the document.