> -----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
