Re: [Dots] Opsdir last call review of draft-ietf-dots-requirements-16

Hi Tiru, all,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar
> Reddy
> Envoyé : lundi 26 novembre 2018 06:16
> À : Scott Bradner; ops-dir@ietf.org
> Cc : draft-ietf-dots-requirements.all@ietf.org; ietf@ietf.org; dots@ietf.org
> Objet : Re: [Dots] Opsdir last call review of draft-ietf-dots-requirements-16
> 
> Hi Scott,
> 
> Thanks for the review, Please see inline
> 
> > -----Original Message-----
> > From: Scott Bradner <sob@sobco.com>
> > Sent: Sunday, November 25, 2018 2:03 AM
> > To: ops-dir@ietf.org
> > Cc: draft-ietf-dots-requirements.all@ietf.org; ietf@ietf.org; dots@ietf.org
> > Subject: Opsdir last call review of draft-ietf-dots-requirements-16
> >
> > This email originated from outside of the organization. Do not click links
> or
> > open attachments unless you recognize the sender and know the content is
> safe.
> >
> > Reviewer: Scott Bradner
> > Review result: Has Nits
> >
> > This is an OPS-DIR review of Distributed Denial of Service (DDoS) Open
> Threat
> > Signaling Requirements (draft-ietf-dots-requirements)
> >
> > This document lists requirements for a protocol to used between providers
> of
> > DDOS mitigation services and users of such services, as such there can be
> no
> > direct operational issues with the document.  I also did not find any
> indirect
> > operational issues.
> >
> > I think the document would benefit from the addition of a section before
> the
> > requirements section that specifically describes the setup assumed by the
> > document. The descriptions before there hint at a presumed setup but a new
> > section that clearly states the setup would be helpful. (the setup appears
> to be
> > one where all network traffic to and from a protected entity flows through
> a
> > DDoS mitigation service provider.  The provider includes one or more DOTS
> > servers.  The protected entity includes one or more DOTS clients that
> > communicate with the DOTS servers)
> 
> The requirements drafts refers to the DOTS architecture draft that discusses
> the architectural relationships, components and concepts used in a DOTS
> deployment.
> 
> >
> > Requirement SIG-005 addresses channel redirection – maybe there needs to be
> > a way that clients can move to a new server on their own if they lose
> hearbeat
> > from the server they were using – that might include a way for a server to
> > provide a list of alternative servers to the clients
> 
> We can update SIG-004 requirement to say the following:
> 
> The DOTS client may be provided with a list of DOTS servers.

[Med] IMHO given that the requirements I-D points to the architecture I-D, we don't need to be redundant:

   The DOTS client may be provided with a list of DOTS servers, each
   associated with one or more IP addresses.  These addresses may or may
   not be of the same address family.  The DOTS client establishes one
   or more sessions by connecting to the provided DOTS server addresses.

But, of course it is not harmful to restate it if it helps the reader.

  If the DOTS
> client considers the signal channel is defunct due to the extended absence of
> DOTS server heartbeat, the DOTS client can establish  a new DOTS signal
> channel with the other DOTS servers in the list.
> 

[Med] Some comments here:
* I would not mix server selection/server migration with server redirection. That is, the proposed text is to be placed somewhere else in the I-D, not under SIG-004.
* I would not describe the behavior (e.g., if xxx, establish a new session) in the Requirements I-D, but focus on the expected functionality if we really need to say something. 
* A DOTS client provisioned with multiple dots server may already have other sessions established. How those sessions are established is policy-based. 
* Establishing a new session should be carefully considered to avoid, e.g., leaking information among servers not belonging to the same domain or oscillate between servers.

We can include a generic text such as the following:

  "Additional means to enhance the resilience of DOTS protocols, including when multiple DOTS servers are provisioned to the DOTS clients, SHOULD be considered." 

> -Tiru
> 
> >
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots