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, Elwyn Sent from Samsung tablet. -------- Original message -------- From: Daniel Migault <mglt.ietf@xxxxxxxxx> Date: 02/07/2020 22:28 (GMT+00:00) To: Elwyn Davies <elwynd@xxxxxxxxxxxxxx> Cc: last-call@xxxxxxxx, "gen-art >> General area reviewing team" <gen-art@xxxxxxxx>, draft-ietf-dots-use-cases.all@xxxxxxxx, dots <dots@xxxxxxxx> 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 <noreply@xxxxxxxx> wrote: Reviewer: Elwyn Davies <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>
<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>
<mglt> fixed. </mglt> s2, DDoS Mitigation Service: <mglt> fixed.</mglt> s3.1, para 1: The abbreviation ITP has already been defined so you shouldn't <mglt> fixed. </mglt> s3.1, para 7: s/thought different/though different/ <mglt>fixed</mglt>
<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 <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 <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 <mgl> I added the for example which seems closer to the most probable implementation.</mglt> s3.3, first para on page 11: <mglt>fixed</mglt> s3.3, 3rd and subsequent paras on page 11: The orchestrator appears to change <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 <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>
Daniel Migault Ericsson |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
