and for me Scott > On Nov 26, 2018, at 5:11 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx> wrote: > >> -----Original Message----- >> From: mohamed.boucadair@xxxxxxxxxx <mohamed.boucadair@xxxxxxxxxx> >> Sent: Monday, November 26, 2018 1:02 PM >> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx>; >> Scott Bradner <sob@xxxxxxxxx>; ops-dir@xxxxxxxx >> Cc: draft-ietf-dots-requirements.all@xxxxxxxx; ietf@xxxxxxxx; dots@xxxxxxxx >> Subject: RE: 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. >> >> Hi Tiru, all, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Dots [mailto:dots-bounces@xxxxxxxx] De la part de Konda, >>> Tirumaleswar Reddy Envoyé : lundi 26 novembre 2018 06:16 À : Scott >>> Bradner; ops-dir@xxxxxxxx Cc : >>> draft-ietf-dots-requirements.all@xxxxxxxx; ietf@xxxxxxxx; >>> dots@xxxxxxxx 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@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. >> >> [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." > > Works for me. > > -Tiru > >> >> >>> -Tiru >>> >>>> >>> >>> _______________________________________________ >>> Dots mailing list >>> Dots@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/dots
