Subject: [Dots] draft DOTS WG Charter [updated]

From: "Teague, Nik" <[email-masked]>
Date: Wed, 20 May 2015 17:02:33 +0000

Hi,

Please see below an updated draft charter based on the received
comments/feedback.  The milestone dates are there for discussion and are
possibly much more aggressive than strictly necessary but feel free as
always to comment.

I¹ve added in Andrew¹s suggestion for the 3rd element definition which I
think may cover Frank and Ning¹s concerns.  I have deliberately omitted
capabilities from the charter as I believe that¹s something to be
discussed in line with requirements/use cases.

Thoughts/feedback of course valued and welcome.

-Nik

‹[Charter for Working Group]‹

The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards
based approach for the real time signaling of DDoS related telemetry and
threat handling data between elements concerned with attack mitigation.

The elements may be described as:
* On-premise DDoS mitigation platforms
* Service provider DDoS mitigation platforms
* Other devices/platforms with network perspective engaged in traffic
analysis

The elements may be chained for communication to construct a larger
collaborative system.

These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for connection oriented approaches and more generalized
signaling and telemetry solutions.  Robustness under these conditions is
paramount while ensuring appropriate regard for authentication,
authorization, privacy and data integrity.  Elements may be deployed as
part of a wider strategy incorporating multiple points of detection and
mitigation, both on premise or service provider based.  Should mitigation
need to move between elements in the chain, then effective signaling of
telemetry and current threat handling is essential.  Feedback between
participating elements is required for increased awareness supporting
effective decision making.

The WG will, where appropriate, reuse or extend existing standard
protocols and mechanisms, for instance IPFIX and its templating mechanism.
 The WG may coordinate with other working groups and initiatives that
compliment the DOTS effort E.G. SACM, MILE, SUPA, I2NSF.

The charter of the working group is to produce one or more standards track
specifications to provide for this open signaling in the DDoS problem
space.  While the resulting standards should be designed so they apply to
network security applications beyond DDoS mitigation, this working group
will focus on DDoS mitigation.  This streamlined focus of the charter is
intended to lead to an earlier result due to community interests in having
such capability in a short timeframe.  The specification(s) produced by
the WG will include a standard mechanism for authentication and
authorization, for data integrity, and for providing for privacy in
operation.

The WG will produce the following deliverables and milestones:

* Document or Documents describing the problem space, use cases, protocol
requirements and other qualifying information as the WG sees fit.
* Document or Documents specifying a protocol and associated data models
to address the WG stated goal.

* Nov-2015: Requirements/use case document as information RFC
* Apr-2016: Transport document as proposed standard RFC
* May-2016: Data model document as proposed standard RFC

* Periodically re-examine/scrutinise milestones (3x month intervals)

---

From: John Schiel <[email-masked]>
Date: Thu, 21 May 2015 11:57:53 -0600

Looks great, a few nits inline.

On 05/20/2015 11:02 AM, Teague, Nik wrote:
> such capability in a short timeframe.

Re "This streamlined..." sentence. I had to read this 3 or 4 times but I 
think what you are trying to convey is the thought of a streamlined 
focus in order to get to a standard sooner due to the desire of the 
community wanting this standard. Is this what you meant?

>   The specification(s) produced by

Don't need all of the 'for' (s) listed above, for applies to all items 
in the list.

Change to:

"The specification(s) produced by the WG will include a standard mechanism
  for authentication and authorization, data integrity, and providing
  for privacy in operation."

--John Schiel

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

---

From: Sean Turner <[email-masked]>
Date: Fri, 22 May 2015 10:32:13 -0400

On May 21, 2015, at 13:57, John Schiel <[email-masked]> wrote:

> Re "This streamlined..." sentence. I had to read this 3 or 4 times but I think what you are trying to convey is the thought of a streamlined focus in order to get to a standard sooner due to the desire of the community wanting this standard. Is this what you meant?

I hope it’s saying the WG is going to concentrate on DDoS to get something done sooner rather than later or in IETF parlance we’re doing it to avoid boiling the ocean.  How about:

  Focusing the WG’s efforts on DDoS is intended to meet
  the community’s desire for solution in the shorter term.

Alternatively I could see dropping the last sentence and adding the phrase “to avoid boiling the ocean” to the penultimate sentence ;)

> Don't need all of the 'for' (s) listed above, for applies to all items in the list.
> 
> Change to:
> 

I’d tweak the milestones to be when the drafts are expected to be adopted by the and when they are expected to get to the IESG.  After it gets to the IESG, the timeline is pretty much out of the WG’s hands:

Date - WG document for Requirements/Use Cases (informational)
Date - WG document for Transport (proposed standard)
Date - WG document for Data Model (proposed standard)
Date - Requirements/Use Cases draft to IESG
Date - Transport draft to IESG
Date - Data Model draft to IESG

lgtm otherwise

spt