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

[Daniel Migault <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> Date: 02/07/2020 22:28 (GMT+00:00)
> To: Elwyn Davies <[e-mail]>
> Cc: [e-mail], "gen-art >> General area reviewing team" <
> [e-mail]>, [e-mail], dots <
> [e-mail]>
> 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 <
> [e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dots
>>
>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson