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