RE: Opsdir last call review of draft-ietf-dots-requirements-16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Scott,

Thanks for the review, Please see inline 

> -----Original Message-----
> From: Scott Bradner <sob@xxxxxxxxx>
> Sent: Sunday, November 25, 2018 2:03 AM
> To: ops-dir@xxxxxxxx
> Cc: draft-ietf-dots-requirements.all@xxxxxxxx; ietf@xxxxxxxx; dots@xxxxxxxx
> 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.  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.

-Tiru

> 





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux