Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt

From: [email-masked]
Date: Mon, 19 Oct 2015 09:22:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DDoS Open Threat Signaling Working Group of the IETF.

        Title           : Use cases for DDoS Open Threat Signaling
        Authors         : Roland Dobbins
                          Stephane Fouant
                          Daniel Migault
                          Robert Moskowitz
                          Nik Teague
                          Liang Xia
	Filename        : draft-ietf-dots-use-cases-00.txt
	Pages           : 22
	Date            : 2015-10-19

Abstract:
   This document delineates principal and ancillary use cases for DDoS
   Open Threat Signaling (DOTS), a communications protocol intended to
   facilitate the programmatic, coordinated mitigation of Distributed
   Denial of Service (DDoS) attacks via a standards-based mechanism.
   DOTS is purposely designed to support requests for DDoS mitigation
   services and status updates across inter-organizational
   administrative boundaries.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dots-use-cases-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dave Dolson <[email-masked]>
Date: Mon, 2 Nov 2015 18:48:14 +0000

Is it intentional that the use-cases effectively lay out the protocol, not in the message format but in the sense of who says what to whom, which commands and information are conveyed from client to server and vice versa?

Example: it seems that the use-cases document requires a server-pushes model (vs. a client-polls model) for the status updates.
Was that level of specificity intended?

-Dave

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 20, 2015 1:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt

Abstract:

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 03 Nov 2015 08:16:24 +0900

On 3 Nov 2015, at 3:48, Dave Dolson wrote:

> Is it intentional that the use-cases effectively lay out the protocol, 
> not in the message format but in the sense of who says what to whom, 
> which commands and information are conveyed from client to server and 
> vice versa?

Yes, in terms of operationally-significant information flow and 
informational checkpoints.

> Example: it seems that the use-cases document requires a server-pushes 
> model (vs. a client-polls model) for the status updates.

Server can push from its perspective, client can push from its 
perspective, both can poll.

In the examples in question, status updates regarding ongoing mitigation 
are natural and expected from the system(s) doing the actual mitigating. 
  Likewise, updates on the efficacy of said mitigation are natural and 
expected from the system(s) southbound of said mitigation.

Does this make sense?

> Was that level of specificity intended?

Yes, in the context of the specific examples in question - but not as a 
limitation - see above.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: Dave Dolson <[email-masked]>
Date: Tue, 3 Nov 2015 20:27:35 +0000

Roland,
Thanks.
It seems to me that the use-cases document is actually an architecture document, in the sense that it describes all of the architectural components and interfaces. I don't see any architectural freedom.
I'm not saying that's inherently bad, just my sense of it.

-Dave

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Tuesday, November 03, 2015 8:16 AM
To: [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-00.txt

> which commands and information are conveyed from client to server and 

Yes, in terms of operationally-significant information flow and informational checkpoints.

> model (vs. a client-polls model) for the status updates.

Server can push from its perspective, client can push from its perspective, both can poll.

In the examples in question, status updates regarding ongoing mitigation are natural and expected from the system(s) doing the actual mitigating. 
  Likewise, updates on the efficacy of said mitigation are natural and expected from the system(s) southbound of said mitigation.

Does this make sense?

> Was that level of specificity intended?

Yes, in the context of the specific examples in question - but not as a limitation - see above.