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

[<[e-mail]>]

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.