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 <elw...@folly.org.uk> 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 <mglt.i...@gmail.com> > Date: 02/07/2020 22:28 (GMT+00:00) > To: Elwyn Davies <elw...@dial.pipex.com> > Cc: last-c...@ietf.org, "gen-art >> General area reviewing team" < > gen-art@ietf.org>, draft-ietf-dots-use-cases....@ietf.org, dots < > d...@ietf.org> > 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 < > nore...@ietf.org> 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 >> d...@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
