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

Daniel Migault <> Thu, 02 July 2020 21:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 267F73A0BD3; Thu, 2 Jul 2020 14:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ry8hUvvZBF9g; Thu, 2 Jul 2020 14:27:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84F6B3A0BD0; Thu, 2 Jul 2020 14:27:53 -0700 (PDT)
Received: by with SMTP id m25so16033971vsp.8; Thu, 02 Jul 2020 14:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iiov+cf0VRFE+7Y6d75J107JK/pvK4UXrVG6d8KAxvc=; b=tDjBDsf9KvWQiDak9e+CbfUgeZ2W7N4cCq3GRycwjwXtdiynVUyyTH9n3pR7DjtoxP vW71N23NtdvuafXrzDod+8toJXCMDo+iW8IkRiP8E3HHwCd1Sb7OKaAa2QJ6J0WKDt5H 4Lig6yxwf+FH4D9HnP2Ul9Pj1xZv41M/u4A3l4QTguv4C2w1arWAqfQbf2I1dyNPanSb mt4ZoVBvxqkO2fc4c1cM4Jm8TBodKEgJgY60nzQRBCOHNLsrBj0fOwucgR7dfJOEETjG 6dqHANtSlFgPXwa/Wk1q3CXlP/+iSlOSddx0siNNTs8HtQM6Z8mY8TMprf0LsIBA1Yye RiKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iiov+cf0VRFE+7Y6d75J107JK/pvK4UXrVG6d8KAxvc=; b=n2pVnvjKpNHlIUIS90fhFBlsUxEcJMs8cpu6SXrlxdsAdyotGnKAe8ujFHG+oKzSJw srC1Iy5gLdoxFJEIGf32rzaGmRAmbXHopqVG1nIcuXmqeAHt+4NNq5luA2YyUWay8+bl ZhTBtI1hcNt20JAGyo16jixLzM5dnHGAYBSMqHC/olgOG4LGrhy8jecK0NCABNDx7Ord ORdyczuzxwuNbH8mwj95Fni9P5mZTgEBYtc6IQG7aios8dFpIdZZs7sDYszu1H0iLDip tVHFbm6/wxTF7TkJS+FLA5kTa0RLg9DyPqp0OBec9CqAKdvqSn5Bu5+wSn1IC6rVIAiV NbSQ==
X-Gm-Message-State: AOAM5319zX+iqvD70yGBlu4xRAPYcohfAej3yFv2UNH4rtcq9TTZAJY/ 8P7kqJRO4rd/aQgtQUa4CQWYWna/9+N9q41k2Ig=
X-Google-Smtp-Source: ABdhPJzyxU30CATMowaLiGZn46276ryHnvJ7pR60XF2jAqIgIMrZ8hHmruUKXNsy/Ts2XLlgL8Ix5z0hbyVfHfQY31E=
X-Received: by 2002:a67:6546:: with SMTP id z67mr17976615vsb.169.1593725272331; Thu, 02 Jul 2020 14:27:52 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Thu, 02 Jul 2020 17:27:41 -0400
Message-ID: <>
To: Elwyn Davies <>
Cc: "gen-art >> General area reviewing team" <>,,, dots <>
Content-Type: multipart/alternative; boundary="000000000000ba186705a97c14ee"
Archived-At: <>
Subject: Re: [Gen-art] [Dots] Genart last call review of draft-ietf-dots-use-cases-23
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Jul 2020 21:27:56 -0000


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.


On Wed, Jun 10, 2020 at 12:02 PM Elwyn Davies via Datatracker <> 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
> <>.
> 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".
 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:

This greatly increases operational complexity which, in turn,
can degrade the efficacy of mitigations.
This greatly increases operational complexity which, in turn,
can degrade the efficacy of mitigations - which highly depends on  a timely

> 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].
>    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].
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:
This document provides sample use cases that provided input for the design
the DOTS protocols {{RFC8782}}{{RFC8783}}.
This document provides sample use cases that provided input for the
requirements {{?RFC8612}} and design of
the DOTS protocols {{!RFC8782}}{{!RFC8783}}.

> 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.
> <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/

> 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.

> 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.

> 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

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.
> <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

> _______________________________________________
> Dots mailing list

Daniel Migault