Subject: Re: [Gen-art] [Dots] Genart last call review of draft-ietf-dots-use-cases-23

From: Daniel Migault <[email-masked]>
Date: Thu, 2 Jul 2020 17:27:41 -0400

Hi,

Thank you for the review. These were helpful to us. I believe that all
comments have been addressed in the version we just published.
Please find more response regarding the comment inlined.

Yours,
Daniel

On Wed, Jun 10, 2020 at 12:02 PM Elwyn Davies via Datatracker <
[email-masked]> wrote:

> Reviewer: Elwyn Davies
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-dots-use-cases-23
> Reviewer: Elwyn Davies
> Review Date: 2020-06-10
> IETF LC End Date: 2020-06-11
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
> Ready wih some minor nits.
>
> Major issues:
> None
>
> Minor issues:
> None
>
> Nits/editorial comments:
> s1, para 1: Just a thought:  might be worth adding to the end of this para:
> "and increase the time for deployment in a situation where speed is often
> of
> the essence".
>
 <mglt>
 I understand that the additional time is part of the reasons that degrade
the efficacy but this is not the only reason. I propose to indicate that
efficacity highly depends on an timely reaction as below:

OLD
This greatly increases operational complexity which, in turn,
can degrade the efficacy of mitigations.
NEW
This greatly increases operational complexity which, in turn,
can degrade the efficacy of mitigations - which highly depends on  a timely
reaction.
</mglt>

>
> s1, last para: Suggest adding in reference to DOTS requirements doc which
> is
> referred to in s2: OLD:
>    This document provides sample use cases that provided input for the
>    design of the DOTS protocols [RFC8782][RFC8783].
> NEW
>    This document provides sample use cases that motivated the requirements
>    for the DOTS protocols [RFC8612] and provided input for the design of
>    those protocols [RFC8782][RFC8783].
> ENDS
>
<mglt>
I would consider the requirement as part of the process for the design of
the protocol, but it is correct that requirements coudl be included. I
propose the following change:
OLD:
This document provides sample use cases that provided input for the design
of
the DOTS protocols {{RFC8782}}{{RFC8783}}.
NEW:
This document provides sample use cases that provided input for the
requirements {{?RFC8612}} and design of
the DOTS protocols {{!RFC8782}}{{!RFC8783}}.
</mglt>

>
> s2: For more logical ordering, move the definition of DDos Mitigation
> Service
> Provider after definition of DDoS Mitigation Service.
>
>  <mglt> fixed. </mglt>

> s2, DDoS Mitigation Service:
> OLD:
>       Service subscriptions usually
>       involve Service Level Agreement (SLA) that have to be met.
> NEW:
>       Each service subscription usually
>       involves a Service Level Agreement (SLA) that has to be met.
> ENDS
>
> <mglt> fixed.</mglt>

> s3.1, para 1: The abbreviation ITP has already been defined so you
> shouldn't
> have a redefinition here.
>
> <mglt> fixed. </mglt>

> s3.1, para 7: s/thought different/though different/
>
<mglt>fixed</mglt>

>
> s3.1, 2nd set of bullets, that are below Fig 1: This woud be more elegant
> using
> (a), (b), etc as the bullet labels.
>
> <mglt>
I could not find how to do list as a) b) using kramdow but I used an
ordered list 1. 2. instead so a native list format is rendered.
</mglt>

> s3.1: Comment (not being familiar with the DOTS proposals): The text
> indicates
> that the ITP mitigation effort is an all or nothing buisness.  Is this
> always
> the case or could the client request or the server provide a proportional
> response rather than an all or nothing response?
>
> <mglt>
My understanding is that when the decision to mitigate is requested the ITP
mitigates the traffic. As far as I know it is not currently envisioned to
use DOTS for a kind of collaboration between the ITP and the local side,
that is the local site performs 20 % of the attack while the ITP takes in
charge the remaining 80 %. One reason is that it remains hard to express
the capabilities involved to mitigate the attack. Note also that the
capacity of the ITP may be capped by contract.  Overall the DOTS is more
about delegating the mitigation as opposed to collaborative mitigation.
</mglt>

> s3.2, last sentence of 2nd para after Fig 2: s/These exact/The exact/
>
>  <mglt>fixed</mglt>

> s3.3, para 2: s/various information/various sets of information/
>
>  <mglt>fixed</mglt>

> s3.3, para after Figure 4: s/monitor various network traffic/monitor
> various
> aspects of the network traffic/.
>
> <mglt> fixed</mglt>

> s3.3, 2nd para after Figure 4: s/it's/it is/
>
>  <mglt>fixed</mglt>

> s3.3, last five paras: Calling out a web interface specifically is overly
> specific.  Suggest adding 'for example'in at least one case or changing it
> to
> 'user interface'.
>
>  <mgl> I added the for example which seems closer to the most probable
implementation.</mglt>

s3.3, first para on page 11:
> OLD:
> to infer the DDoS Mitigation to elaborate and coordinate.
> NEW:
> to infer, elaborate and coordinate the appropriate DDoS Mitigation.
> ENDS
>
> <mglt>fixed</mglt>

> s3.3, 3rd and subsequent paras on page 11: The orchestrator appears to
> change
> from one DOTS server to a plurality at this point.  Please make it clear
> whether there is one or many.  If only one, then s/The orchestrator DOTS
> servers returns this information back/The orchestrator DOTS server returns
> this
> information/ and s/servers/server/ subsequently.
>
>  <mglt>good catch. There is only one server. we address this.</mglt>

s3.3, last para s/like  requesting/such as requesting/
> <mglt>fixed.</mglt>

> s7:  This is an informational document and, as such, cannot have normative
> references.  Please combine all references into one refererences section.
>
>
> <mglt> I usually like standard document to be normative, but this is
correct that for use cases, none of these document are necessary to be read
to understand the document, so I will put all reference as
informational</mglt>

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

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Thu, 2 Jul 2020 17:29:27 -0400

Thanks med for the feed back. All documents are now referenced as
informative. If the RFC editor expresses concerns we will update that.

Thanks!
Yours,
Daniel

On Wed, Jun 10, 2020 at 12:21 PM <[email-masked]> wrote:

> Dear Elwyn,
> One quick comment about:
> If we refer to the IESG statement available at:
> https://ietf.org/about/groups/iesg/statements/normative-informative-references/,
> we can read the following:
>
> "Note 3: The normative/informative distinction is relevant in any document
> that amounts to a technical specification, even if its intended status is
> Experimental or Informational."
>
> So, that's fine to have a normative ref section (if justified) for this
> document.
>
> That's said, I do personally think that at least [RFC8782][RFC8783] have
> to be moved as Informative... but not for the reasons mentioned in the
> review..
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Dots [mailto:[email-masked]] De la part de Elwyn Davies
> > via Datatracker
> > Envoyé : mercredi 10 juin 2020 18:00
> > À : [email-masked]
> > Cc : [email-masked]; [email-masked];
> > [email-masked]
> > Objet : [Dots] Genart last call review of draft-ietf-dots-use-cases-23
> >
> > Reviewer: Elwyn Davies
> > "and increase the time for deployment in a situation where speed is
> > often of
> > the essence".
> >
> > s1, last para: Suggest adding in reference to DOTS requirements doc
> > which is
> > referred to in s2: OLD:
> > s3.1, 2nd set of bullets, that are below Fig 1: This woud be more
> > elegant using
> > specific.  Suggest adding 'for example'in at least one case or
> > changing it to
> > 'user interface'.
> >
> > servers returns this information back/The orchestrator DOTS server
> > returns this
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>

-- 
Daniel Migault
Ericsson

---

From: elwynd <[email-masked]>
Date: Fri, 03 Jul 2020 18:17:04 +0100

Hi, Daniel.Thanks for your response. The changes look good to me.  A couple of minor language improvements if I may suggest:s1, para 1: s/mitigations - which highly depends on a timely reaction/mitigations that are generally highly dependent on a timely reaction by the system./s2, DDoS Mitigation Service: s/usually involve Service Level Agreement (SLA) that have to be met/usually involves a Service Level Agreement (SLA) that has to be met/Paragraph just after Figure 4: s/various aspect/various aspects/End of 4th paragraph after Figure 4: s/appropriated/appropriate/Otherwise this is all done.Hope you are keeping safe and well.Cheers,ElwynSent from Samsung tablet.
-------- Original message --------From: Daniel Migault <[email-masked]> Date: 02/07/2020  22:28  (GMT+00:00) To: Elwyn Davies <[email-masked]> Cc: [email-masked], "gen-art >> General area reviewing team" <[email-masked]>, [email-masked], dots <[email-masked]> Subject: Re: [Gen-art] [Dots] Genart last call review of draft-ietf-dots-use-cases-23 Hi, Thank you for the review. These were helpful to us. I believe that all comments have been addressed in the version we just published.  Please find more response regarding the comment inlined. Yours, Daniel On Wed, Jun 10, 2020 at 12:02 PM Elwyn Davies via Datatracker <[email-masked]> wrote:Reviewer: Elwyn Davies
Review result: Ready with Nits

Summary:

Major issues:
None

Minor issues:
None

Nits/editorial comments:
s1, para 1: Just a thought:  might be worth adding to the end of this para:
"and increase the time for deployment in a situation where speed is often of
the essence". <mglt> I understand that the additional time is part of the reasons that degrade the efficacy but this is not the only reason. I propose to indicate that efficacity highly depends on an timely reaction as below:OLDThis greatly increases operational complexity which, in turn,can degrade the efficacy of mitigations.NEWThis greatly increases operational complexity which, in turn,can degrade the efficacy of mitigations - which highly depends on  a timely reaction.. </mglt>

s1, last para: Suggest adding in reference to DOTS requirements doc which is
referred to in s2: OLD:
   This document provides sample use cases that provided input for the
   design of the DOTS protocols [RFC8782][RFC8783].
NEW
   This document provides sample use cases that motivated the requirements
   for the DOTS protocols [RFC8612] and provided input for the design of
   those protocols [RFC8782][RFC8783].
ENDS<mglt>I would consider the requirement as part of the process for the design of the protocol, but it is correct that requirements coudl be included. I propose the following change:OLD:This document provides sample use cases that provided input for the design ofthe DOTS protocols {{RFC8782}}{{RFC8783}}.NEW:This document provides sample use cases that provided input for the requirements {{?RFC8612}} and design ofthe DOTS protocols {{!RFC8782}}{{!RFC8783}}.</mglt>

s2: For more logical ordering, move the definition of DDos Mitigation Service
Provider after definition of DDoS Mitigation Service.
 <mglt> fixed. </mglt>
s2, DDoS Mitigation Service:
OLD:
      Service subscriptions usually
      involve Service Level Agreement (SLA) that have to be met.
NEW:
      Each service subscription usually
      involves a Service Level Agreement (SLA) that has to be met.
ENDS
<mglt> fixed.</mglt> 
s3.1, para 1: The abbreviation ITP has already been defined so you shouldn't
have a redefinition here.
<mglt> fixed. </mglt> 
s3.1, para 7: s/thought different/though different/<mglt>fixed</mglt> 

s3.1, 2nd set of bullets, that are below Fig 1: This woud be more elegant using
(a), (b), etc as the bullet labels.
<mglt>I could not find how to do list as a) b) using kramdow but I used an ordered list 1. 2. instead so a native list format is rendered. </mglt>  
s3.1: Comment (not being familiar with the DOTS proposals): The text indicates
that the ITP mitigation effort is an all or nothing buisness.  Is this always
the case or could the client request or the server provide a proportional
response rather than an all or nothing response?
<mglt>My understanding is that when the decision to mitigate is requested the ITP mitigates the traffic. As far as I know it is not currently envisioned to use DOTS for a kind of collaboration between the ITP and the local side, that is the local site performs 20 % of the attack while the ITP takes in charge the remaining 80 %. One reason is that it remains hard to express the capabilities involved to mitigate the attack. Note also that the capacity of the ITP may be capped by contract.  Overall the DOTS is more about delegating the mitigation as opposed to collaborative mitigation.</mglt> 
s3.2, last sentence of 2nd para after Fig 2: s/These exact/The exact/
 <mglt>fixed</mglt>
s3.3, para 2: s/various information/various sets of information/
 <mglt>fixed</mglt>
s3.3, para after Figure 4: s/monitor various network traffic/monitor various
aspects of the network traffic/.
<mglt> fixed</mglt>
s3.3, 2nd para after Figure 4: s/it's/it is/
 <mglt>fixed</mglt>
s3.3, last five paras: Calling out a web interface specifically is overly
specific.  Suggest adding 'for example'in at least one case or changing it to
'user interface'.
 <mgl> I added the for example which seems closer to the most probable implementation.</mglt>
s3.3, first para on page 11:
OLD:
to infer the DDoS Mitigation to elaborate and coordinate.
NEW:
to infer, elaborate and coordinate the appropriate DDoS Mitigation.
ENDS
<mglt>fixed</mglt> 
s3.3, 3rd and subsequent paras on page 11: The orchestrator appears to change
from one DOTS server to a plurality at this point.  Please make it clear
whether there is one or many.  If only one, then s/The orchestrator DOTS
servers returns this information back/The orchestrator DOTS server returns this
information/ and s/servers/server/ subsequently.
 <mglt>good catch. There is only one server. we address this.</mglt>
s3.3, last para s/like  requesting/such as requesting/
<mglt>fixed.</mglt> 
s7:  This is an informational document and, as such, cannot have normative 
references.  Please combine all references into one refererences section.

<mglt> I usually like standard document to be normative, but this is correct that for use cases, none of these document are necessary to be read to understand the document, so I will put all reference as informational</mglt> 

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

---

From: Daniel Migault <[email-masked]>
Date: Sun, 5 Jul 2020 21:07:36 -0400

Hi,

Thank you for the feed backs. I fixed the comments on my local copy and
will soon publish the updated version. Thank you very much for your time
and I hope you are safe as well.

Yours,
Daniel

On Fri, Jul 3, 2020 at 1:17 PM elwynd <[email-masked]> wrote:

> Hi, Daniel.
>
> Thanks for your response.
>
> The changes look good to me.  A couple of minor language improvements if I
> may suggest:
>
> s1, para 1: s/mitigations - which highly depends on a timely
> reaction/mitigations that are generally highly dependent on a timely
> reaction by the system./
>
>  <mglt>fixed</mglt>

> s2, DDoS Mitigation Service: s/usually involve Service Level Agreement
> (SLA) that have to be met/usually involves a Service Level Agreement (SLA)
> that has to be met/
>
> <mglt>fixed</mglt>

> Paragraph just after Figure 4: s/various aspect/various aspects/
>
<mglt>fixed</mglt>

>
> End of 4th paragraph after Figure 4: s/appropriated/appropriate/
>
> Otherwise this is all done.
>
> Hope you are keeping safe and well.
>
> Cheers,
> Elwyn
>
> Sent from Samsung tablet.
>
>
> -------- Original message --------
> From: Daniel Migault <[email-masked]>
> Date: 02/07/2020 22:28 (GMT+00:00)
> To: Elwyn Davies <[email-masked]>
> Cc: [email-masked], "gen-art >> General area reviewing team" <
> [email-masked]>, [email-masked], dots <
> [email-masked]>
> Subject: Re: [Gen-art] [Dots] Genart last call review of
> draft-ietf-dots-use-cases-23
>
> Hi,
>
> can degrade the efficacy of mitigations - which highly depends on  a
> timely reaction..
> </mglt>
>
>>
> My understanding is that when the decision to mitigate is requested the
> ITP mitigates the traffic. As far as I know it is not currently envisioned
> to use DOTS for a kind of collaboration between the ITP and the local side,

-- 
Daniel Migault
Ericsson

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 9 Jul 2020 10:17:38 -0400

Elwyn, thanks for your review. All, thanks for your responses. I entered a No Objection ballot.

Alissa

> On Jul 5, 2020, at 9:07 PM, Daniel Migault <[email-masked]> wrote:
> 
> Hi, 
> 
> Thank you for the feed backs. I fixed the comments on my local copy and will soon publish the updated version. Thank you very much for your time and I hope you are safe as well.
> 
> Yours, 
> Daniel
> 
> 
> On Fri, Jul 3, 2020 at 1:17 PM elwynd <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Daniel.
> 
> The changes look good to me.  A couple of minor language improvements if I may suggest:
> 
> s1, para 1: s/mitigations - which highly depends on a timely reaction/mitigations that are generally highly dependent on a timely reaction by the system./
> 
>  <mglt>fixed</mglt>
> s2, DDoS Mitigation Service: s/usually involve Service Level Agreement (SLA) that have to be met/usually involves a Service Level Agreement (SLA) that has to be met/
> 
> <mglt>fixed</mglt> 
> From: Daniel Migault <[email-masked] <mailto:[email-masked]>>
> To: Elwyn Davies <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>, "gen-art >> General area reviewing team" <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]>, dots <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [Gen-art] [Dots] Genart last call review of draft-ietf-dots-use-cases-23
> 
> Hi, 
> 
> Thank you for the review. These were helpful to us. I believe that all comments have been addressed in the version we just published.  
> On Wed, Jun 10, 2020 at 12:02 PM Elwyn Davies via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
> Reviewer: Elwyn Davies
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
> 
>  I understand that the additional time is part of the reasons that degrade the efficacy but this is not the only reason. I propose to indicate that efficacity highly depends on an timely reaction as below:
> 
> OLD
> can degrade the efficacy of mitigations - which highly depends on  a timely reaction... 
> </mglt>
> 
> I would consider the requirement as part of the process for the design of the protocol, but it is correct that requirements coudl be included. I propose the following change:
> OLD:
> This document provides sample use cases that provided input for the design of
> This document provides sample use cases that provided input for the requirements {{?RFC8612}} and design of
> I could not find how to do list as a) b) using kramdow but I used an ordered list 1. 2. instead so a native list format is rendered. 
> </mglt> 
>  
> My understanding is that when the decision to mitigate is requested the ITP mitigates the traffic. As far as I know it is not currently envisioned to use DOTS for a kind of collaboration between the ITP and the local side, that is the local site performs 20 % of the attack while the ITP takes in charge the remaining 80 %. One reason is that it remains hard to express the capabilities involved to mitigate the attack. Note also that the capacity of the ITP may be capped by contract.  Overall the DOTS is more about delegating the mitigation as opposed to collaborative mitigation.
> </mglt>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dots <https://www.ietf.org/mailman/listinfo/dots>
> 
> 
> -- 
> Daniel Migault
> Ericsson
> 
> 
> -- 
> Daniel Migault
> Ericsson
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art