Re: [Dots] AD Review of draft-ietf-dots-architecture-14

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Thanks Med, will update text.

Cheers,
-Tiru

> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: Friday, January 10, 2020 3:19 PM
> To: Konda, Tirumaleswar Reddy
> <[e-mail]>; Roman Danyliw
> <[e-mail]>; [e-mail]
> Subject: RE: AD Review of draft-ietf-dots-architecture-14
> 
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> Hi Tiru, all,
> 
> Two minor comments inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots [mailto:[e-mail]] De la part de Konda,
> > Tirumaleswar Reddy Envoyé : vendredi 10 janvier 2020 10:05 À : Roman
> > Danyliw; [e-mail] Objet : Re: [Dots] AD Review of
> > draft-ietf-dots-architecture-14
> >
> > Hi Roman,
> >
> > Thanks for the review. Please see inline
> >
> > > -----Original Message-----
> > > From: Dots <[e-mail]> On Behalf Of Roman Danyliw
> > > Sent: Friday, January 10, 2020 3:00 AM
> > > To: [e-mail]
> > > Subject: [Dots] AD Review of draft-ietf-dots-architecture-14
> > >
> > > CAUTION: External email. Do not click links or open attachments
> > > unless
> > you
> > > recognize the sender and know the content is safe.
> > >
> > > Hello!
> > >
> > > The following is my AD review of draft-ietf-dots-architecture-14:
> ...
> > >
> > > ** Section 2.1  Per "It is not until this point that the mitigation
> > service is
> > > available for use.", this closing point about a mitigation service
> > follows from
> > > the previous description.  However, I wanted to point out, the
> > > notion
> > of a
> > > "mitigation service" being available after a fully configured DOTS
> > client is not
> > > a construct previously used in the document or the terminology.
> > > It's
> > likely
> > > worth relating it to the previously defined terms like mitigator.
> >
> > "mitigation service" is already used in Sections 2 and 1.2
> 
> [Med] Given that only "mitigation" and "mitigator" are defined in the
> terminology inherited from RFC8612, I suggest to make this simple change:
> 
> OLD:
>    A simple example instantiation of the DOTS architecture could be an
>    enterprise as the attack target for a volumetric DDoS attack, and an
>    upstream DDoS mitigation service as the mitigator.
> 
> NEW:
>    A simple example instantiation of the DOTS architecture could be an
>    enterprise as the attack target for a volumetric DDoS attack, and an
>    upstream DDoS mitigator. The service provided by the mitigator is called:
> DDoS mitigation service.
> 
> >
> > >
> > > ** Section 2.1.  To avoid confusion on terms (i.e., from HTTP),
> > perhaps
> > > replace s/basic authorization/authorization/.
> >
> > Okay, replaced.
> >
> > >
> > > ** Section 2.2.2.  Per "For a given DOTS client (administrative)
> > domain, the
> > > DOTS server needs to be able to determine whether a given target
> > resource
> > > is in that domain.", what is a "target resource" isn't clear.  I
> > > think
> > it is meant to
> > > be the resource that is the target of the attack (that the DOTS
> > > client
> > is
> > > signaling about).
> >
> > Yes.
> >
> > > Also, the idea that DOTS clients have "domains" is a new concept
> > > here that needs clarification.
> >
> > I have simplified the text as follows:
> > For a given DOTS client (administrative) domain, the DOTS server needs
> > to be able to determine whether a given resource is in that domain.
> > For example, this could take the form of associating a set of IP
> > addresses and/or prefixes per DOTS client domain.
> 
> [Med] Please make sure that the same wording is consistently used in the
> document. Typically, please make these changes in many places of the
> document:
> 
> s/DOTS client's domain/DOTS client domain s/DOTS server's domain/DOTS
> server domain
> 
> This is also to be aligned with the signal channel document. Thanks.