DDoS Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-18

[Ballot comment]
Thanks for this well-written document!  It's a great high-level summary of
DOTS and I just have some fairly minor comments.

There might be a bit of mismatch between describing the signal channel
session as associated with "an ephemeral security association" in Section
3.1 and as "expected to be long-lived" in Section 3.2.4.1.

Section 2.2.3

  The DOTS gateway MUST perform full stack DOTS session termination and
  reorigination between its client and server side.  The details of how
  this is achieved are implementation specific.  The DOTS protocol does
  not include any special features related to DOTS gateways, and hence
  from a DOTS perspective, whenever a DOTS gateway is present, the DOTS
  session simply terminates/originates there.

Does the 'cdid' count as a "special feature"?

Section 2.3.1

  An example is a DOTS gateway at the network client's side, and
  another one at the server side.  The first gateway can be located at
  a CPE to aggregate requests from multiple DOTS clients enabled in an

nit: "CPE" does not appear as "well known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt and should be
expanded on first use.

Section 3.2.3

We could mention that the recursing gateway (e.g., Cn in Figure 12) must
still be authorized to request mitigation for the resources (also)
controlled by client Cc (though perhaps the closing discussion about there
typically being a SLA among client, recursed, and recursing domain suffices).

Section 3.2.4.1

  DOTS client to initialize a new DOTS session.  This challenge might
  in part be mitigated by use of resumption via a PSK in TLS 1.3
  [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in
  TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must
  be available to all DOTS servers sharing the anycast Service Address
  in that case.

"which has operational challenges of its own", perhaps.

  session may involve diverting traffic to a scrubbing center.  If the
  DOTS session flaps due to anycast changes as described above,
  mitigation may also flap as the DOTS servers sharing the anycast DOTS
  service address toggles mitigation on detecting DOTS session loss,
  depending on whether the client has configured mitigation on loss of
  signal.

I am not sure if we've mentioned configuring mitigation on loss of signal,
yet.  A forward reference to Section 3.3.3 might help.

Section 3.2.5

  Network address translators (NATs) are expected to be a common
  feature of DOTS deployments.  The Middlebox Traversal Guidelines in
  [RFC8085] include general NAT considerations for DOTS deployments
  when the signal channel is established over UDP.

nit: the guidelines in 8085 are not specifically about DOTS deployments, so
probably we should say "that are applicable to" DOTS deployments.

Section 3.2.5.1

  request accurate mitigation scopes.  To that aim, the DOTS client can
  rely on mechanisms, such as [RFC8512] to retrieve static explicit
  mappings.  This document does not prescribe the method by which

nit: no comma.

Section 3.3.3

  The impact of mitigating due to loss of signal in either direction
  must be considered carefully before enabling it.  Signal loss is not
  caused by links congested with attack traffic alone, and as such
  mitigation requests triggered by signal channel degradation in either

nit: I think this could be parsed as "links are congested by attack traffic
and other traffic", whereas we intend to say that "attack traffic is not the
only possible cause of link congestion".  Perhaps "Attack traffic congesting
links is not the only reason why signal could be lost" is more clear.

Section 5

  DOTS is at risk from three primary attack vectors: agent
  impersonation, traffic injection and signal blocking.  These vectors

We seem to only partially discuss countermeasures for these attacks in the
rest of the section; one piece that seems noteworthy in its absence is the
requirement (already described in the body text) to authenticate the peer
and perform authorization checks on client requests.  Mitigating against
signal blocking is in general hard, but we could consider mentioning again
that the automated mitigation on loss of signal discussed in Section 3.3.3
is an option, albeit one with risks of its own.

Section 8.2

One could perhaps argue that RFC 4033 and RFC 6887 should be normative
("[RFC4033] must be used where [...]", "[RFC6887] may be used to [...]").

There's a stronger case that RFC 4786 should be normative, as we use a BCP
14 keyword allowing its deployment.

[Ballot comment]
Section 3.2.5.4: "as long as the name is internally and externally resolvable by the same name." I get what this means but I think it could be stated in a less circular fashion.

[Ballot comment]
Firstly, thank you for a well written, and easy to understand document -- I personally always find architecture type documents helpful...

I do have a few non-blocking comments:
1: "For example, if the DOTS client domain leverages the DDoS mitigation service of its Internet Transit Provider (ITP), the ITP knows the prefixes assigned to the DOTS client domain. However, if the DDoS Mitigation is offered by a third party DDoS mitigation service provider, it does not know the resources owned by the DOTS client domain."
This is vastly oversimplifying the real-world, to the point that it is harmful / propagates dangerous misconceptions. ISPs may or may not know the prefixes assigned to their customers - they really *should* know the prefixes that the client is choosing to announce to them, but the client may have other prefixes which they only announce through other transits (yes, in this case this ISP would only be providing mitigations for prefixes announced to it, but this isn't clear). In addition, if the DDoS mitigation is provides by a 3rd party, it could know what resources are owned by the client -- in fact, it kind of has to if it is going to agree to mitigate for those prefixes. Note that I *almost* made this a DISCUSS point - I really really think that this bit should be either carefully revised, or, better yet, just struck...

2: "Signal loss is not caused by links congested with attack traffic alone, and as such mitigation requests triggered by signal channel degradation in either direction may incur unnecessary costs, in network performance and operational expense alike."
The "operational expense" is vary vague - enabling DDoS mitigations is almost definitely going to cause a user visible impact, especially in the case where the  mitigator announces a BGP route to attract traffic. Is this covered by 'operational expense'? This section also leaves out the fact that there is likely a financial impact.

3: "The signal and data channels are loosely coupled, and may not terminate on the same DOTS server." - s/may not/might not/. Every-time I'm sitting on a plane and the safety briefing says that oxygen mask will fall from the ceiling and that "the bag may not inflate" I have visions of IETFers (and similar pedants!) sitting there and squeezing the bag to ensure that it doesn't... "the bag *might* not inflate" is what is intended, and is also what you want :-P

[Ballot comment]
A well done document; thanks,  I have just a few minor comments:

— Section 1.1.1 —
You don’t *quite* have the BCP 14 boilerplate verbatim; please fix that.

— Section 1.3 —

  o  The signal and data channels are loosely coupled, and may not
      terminate on the same DOTS server.

I suggest “might not”, lest someone misread it to mean that they are not permitted to (the strict English meaning of “may not”).  Look for “may not” elsewhere also: I saw it in Section 2 as well, and one or two other places.

— Section 2 —

  Thus, DOTS neither specifies how an attack target decides it is under
  DDoS attack, nor does DOTS specify how a mitigator may actually
  mitigate such an attack.

The structure of this “neither...nor” doesn’t work.

NEW
  Thus, DOTS specifies neither how an attack target decides it is under
  DDoS attack, nor how a mitigator may actually mitigate such an attack.
END

[Ballot comment]
Thanks for the work that went into creating this architecture document.
I found it a useful introduction to DOTS.

---------------------------------------------------------------------------

§3.2.5:

Without needing to go into too much detail, it seems that this section would
benefit from citations to RFC 6886, RFC 7659, and ISO/IEC 29341-1-2:2017 as
alternate means to learn about NAT mappings.

[Ballot comment]
Dear authors,

Thank you for the work put into this document. As a side note, I really liked the section about the manual/over-the-phone part of it.

Until now, I have read only this document (dots-architecture) from the dots WG, so, please accept my ignorance for details. But, I have a couple of non-blocking questions where your reply will be welcome and appreciated:

Q1) is the monetary cost part of the DOTS signaling ? (I.e., the mitigator telling the target that it will cost so many EUR per hour)

Q2) Using DOTS in an under-attack network, did you consider recommending dual-stack signaling to cope with the rare case where IPv4 is disrupted while IPv6 still works (of course if the DoS is plain flooding this won't help a lot probably; and the dual proposition exists).

Q3) While I appreciate the value of Anycast DOTS server, hence UDP is mostly required for signaling transport, I wonder whether the choice of UDP (often used AFAIK as volumetric attack as it is easier to spoof) is a good choice compared to TCP or DSCP or ...

Q4) When having multiple DOTS servers, I assume that the case of a dual-stack DOTS server is also covered. Therefore, a word on whether Happy Eyeball (RFC 8305) should probably be useful **IF** applicable

Regards

-éric

Regards,

-éric

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dots-architecture-15, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-01-27):

From: The IESG
To: IETF-Announce
CC: rdd@cert.org, valery@smyslov.net, draft-ietf-dots-architecture@ietf.org, dots@ietf.org, Roman Danyliw , Valery Smyslov , dots-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture) to Informational RFC


The IESG has received a request from the DDoS Open Threat Signaling WG (dots)
to consider the following document: - 'Distributed-Denial-of-Service Open
Threat Signaling (DOTS)
  Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-01-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes an architecture for establishing and
  maintaining Distributed Denial of Service (DDoS) Open Threat
  Signaling (DOTS) within and between domains.  The document does not
  specify protocols or protocol extensions, instead focusing on
  defining architectural relationships, components and concepts used in
  a DOTS deployment.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ballot/


No IPR declarations have been submitted directly on this I-D.

The following is the shepherd write-up for draft-ietf-dots-architecture.

1. Summary

The document shepherd was first Roman Danyliw and later Valery Smyslov.
The responsible Area Director is Benjamin Kaduk.

This document specifies an architecture for deploying and operating Distributed Denial of Service (DDoS) Open Threat.  The document does not specify protocols or protocol extensions, instead it defines architectural relationships, components and concepts used in a DOTS deployment.

The WG has reached consensus to publish this draft as an Informational document.  It has been subjected to substantial review from the community of interest.  Publication of this draft has been intentionally delayed to coincide with the publication of the signal and data channel specifications

2. Review and Consensus
=====================
The WG adopted this draft in July 2016 (-00) from an individual submission which was first published in March 2016.  This draft has evolved through substantial WG discussions to the current -10 version. Feedback on this draft came from vendors, operators and the current implementers of the signal and data channels drafts that realize this architecture.

This draft iteratively evolved with further refinement of the use cases (draft-ietf-dots-use-cases); increased maturity of the signal (draft-ietf-dots-use-cases) and data (draft-ietf-dots-data-channel) channel; and corresponding interop feedback.  The notable evolutions of the draft were:

** Multi-homing architecture considerations were added and refined starting in -02, but ultimately removed by WG consensus and added to a separate document, draft-ietf-dots-multihoming-01.

** Addition of a construct for recursive signaling came in -04

** Guidance around handling environment with Network Address Translation first emerged in -06.

The WG convened a WGLC on -08 of the draft on November 27, 2018 (https://mailarchive.ietf.org/arch/msg/dots/DR2Pu9EzJXJn5uOQ13ien9vvqCY).  This feedback resulted in the publication of -09 and -10.  Key changes in these revisions included consistently clarifying the definition of a session; referencing a specific requirements (in draft-ietf-dots-requirements) and needed updates identified during the review of the signal channel (draft-ietf-dots-requirements).  Issues identified during AD and shepherd review were addressed in -11 and -12.

This draft has seen review from the WG, and there is a belief that it is ready for publication.

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the DOTS mailing list:

** Andrew Mortensen -- https://mailarchive.ietf.org/arch/msg/dots/e__fggpaCdNxHxmaImL2itmBXko
** Flemming Andreasen -- https://mailarchive.ietf.org/arch/msg/dots/22rdjU0yT0o0ax86F_pj-90sZFs
** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/XApYrdcWW2olOti-AIU97Og7X4Q
** Nik Teague -- https://mailarchive.ietf.org/arch/msg/dots/sk44DcT7EfGJE6HygGz6th61X8I
** Rich Compton -- https://mailarchive.ietf.org/arch/msg/dots/R8zBPtdmftL6g9ydZb0olSdQ5EE

One of the contributors, Mohamed Boucadair, has confirmed that he is not aware of any IPR:
https://mailarchive.ietf.org/arch/msg/dots/Lff7OwUAi4j5_Tzh_1pio0fKrSI
The other listed contributor, Christopher Gray, didn't reply to requests for confirmation.

There are no IPR disclosures on the document.

4. Other Points
============
IDnits reported no issues that require immediate action. It reports that there are two lines longer than 72 characters (by 2 chars), that can be handled by RFC Editor. It also reports that there is no the recommended RFC 2119 boilerplate, but it seems to be a false positive, because the boilerplate does exist.

The draft contains no YANG or XML modules to validate.

The draft has no IANA actions.

The following is the shepherd write-up for draft-ietf-dots-architecture.

1. Summary

The document shepherd was first Roman Danyliw and later Valery Smyslov.
The responsible Area Director is Benjamin Kaduk.

This document specifies an architecture for deploying and operating Distributed Denial of Service (DDoS) Open Threat.  The document does not specify protocols or protocol extensions, instead it defines architectural relationships, components and concepts used in a DOTS deployment.

The WG has reached consensus to publish this draft as an Informational document.  It has been subjected to substantial review from the community of interest.  Publication of this draft has been intentionally delayed to coincide with the publication of the signal and data channel specifications

2. Review and Consensus
=====================
The WG adopted this draft in July 2016 (-00) from an individual submission which was first published in March 2016.  This draft has evolved through substantial WG discussions to the current -10 version. Feedback on this draft came from vendors, operators and the current implementers of the signal and data channels drafts that realize this architecture.

This draft iteratively evolved with further refinement of the use cases (draft-ietf-dots-use-cases); increased maturity of the signal (draft-ietf-dots-use-cases) and data (draft-ietf-dots-data-channel) channel; and corresponding interop feedback.  The notable evolutions of the draft were:

** Multi-homing architecture considerations were added and refined starting in -02, but ultimately removed by WG consensus and added to a separate document, draft-ietf-dots-multihoming-01.

** Addition of a construct for recursive signaling came in -04

** Guidance around handling environment with Network Address Translation first emerged in -06.

The WG convened a WGLC on -08 of the draft on November 27, 2018 (https://mailarchive.ietf.org/arch/msg/dots/DR2Pu9EzJXJn5uOQ13ien9vvqCY).  This feedback resulted in the publication of -09 and -10.  Key changes in these revisions included consistently clarifying the definition of a session; referencing a specific requirements (in draft-ietf-dots-requirements) and needed updates identified during the review of the signal channel (draft-ietf-dots-requirements).  Issues identified during AD and shepherd review were addressed in -11 and -12.

This draft has seen review from the WG, and there is a belief that it is ready for publication.

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the DOTS mailing list:

** Andrew Mortensen -- https://mailarchive.ietf.org/arch/msg/dots/e__fggpaCdNxHxmaImL2itmBXko
** Flemming Andreasen -- https://mailarchive.ietf.org/arch/msg/dots/22rdjU0yT0o0ax86F_pj-90sZFs
** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/XApYrdcWW2olOti-AIU97Og7X4Q
** Nik Teague -- https://mailarchive.ietf.org/arch/msg/dots/sk44DcT7EfGJE6HygGz6th61X8I
** Rich Compton -- https://mailarchive.ietf.org/arch/msg/dots/R8zBPtdmftL6g9ydZb0olSdQ5EE

There are no IPR disclosures on the document.

4. Other Points
============
IDnits reported no issues that require immediate action. It reports that there are two lines longer than 72 characters (by 2 chars), that can be handled by RFC Editor. It also reports that there is no the recommended RFC 2119 boilerplate, but it seems to be a false positive, because the boilerplate does exist.

The draft contains no YANG or XML modules to validate.

The draft has no IANA actions.

The following is the shepherd write-up for draft-ietf-dots-architecture.

1. Summary

The document shepherd was first Roman Danyliw and later Valery Smyslov.
The responsible Area Director is Benjamin Kaduk.

This document specifies an architecture for deploying and operating Distributed Denial of Service (DDoS) Open Threat.  The document does not specify protocols or protocol extensions, instead it defines architectural relationships, components and concepts used in a DOTS deployment.

The WG has reached consensus to publish this draft as an Informational document.  It has been subjected to substantial review from the community of interest.  Publication of this draft has been intentionally delayed to coincide with the publication of the signal and data channel specifications

2. Review and Consensus
=====================
The WG adopted this draft in July 2016 (-00) from an individual submission which was first published in March 2016.  This draft has evolved through substantial WG discussions to the current -10 version. Feedback on this draft came from vendors, operators and the current implementers of the signal and data channels drafts that realize this architecture.

This draft iteratively evolved with further refinement of the use cases (draft-ietf-dots-use-cases); increased maturity of the signal (draft-ietf-dots-use-cases) and data (draft-ietf-dots-data-channel) channel; and corresponding interop feedback.  The notable evolutions of the draft were:

** Multi-homing architecture considerations were added and refined starting in -02, but ultimately removed by WG consensus and added to a separate document, draft-ietf-dots-multihoming-01.

** Addition of a construct for recursive signaling came in -04

** Guidance around handling environment with Network Address Translation first emerged in -06.

The WG convened a WGLC on -08 of the draft on November 27, 2018 (https://mailarchive.ietf.org/arch/msg/dots/DR2Pu9EzJXJn5uOQ13ien9vvqCY).  This feedback resulted in the publication of -09 and -10.  Key changes in these revisions included consistently clarifying the definition of a session; referencing a specific requirements (in draft-ietf-dots-requirements) and needed updates identified during the review of the signal channel (draft-ietf-dots-requirements).  Issues identified during AD and shepherd review were addressed in -11 and -12.

This draft has seen review from the WG, and there is a belief that it is ready for publication.

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the DOTS mailing list:

** Andrew Mortensen -- https://mailarchive.ietf.org/arch/msg/dots/e__fggpaCdNxHxmaImL2itmBXko
** Flemming Andreasen -- https://mailarchive.ietf.org/arch/msg/dots/22rdjU0yT0o0ax86F_pj-90sZFs
** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/XApYrdcWW2olOti-AIU97Og7X4Q
** Nik Teague -- https://mailarchive.ietf.org/arch/msg/dots/sk44DcT7EfGJE6HygGz6th61X8I
** Rich Compton -- https://mailarchive.ietf.org/arch/msg/dots/R8zBPtdmftL6g9ydZb0olSdQ5EE

There are no IPR disclosures on the document.

4. Other Points
============
IDnits reported no issues that require immediate action. It reports that there are two lines longer than 72 characters (by 2 chars), that can be handled by RFC Editor. It also reports that there is no the recommended RFC 2119 boilerplate, but it seems to be a false positive, because the boilerplate does exist.

The draft contains no YANG or XML modules to validate.

The draft has no IANA actions.

Request for posting confirmation emailed to previous authors: " christopher_gray3@cable.comcast.com" , Nik Teague , Flemming Andreasen , Rich Compton , Andrew Mortensen , dots-chairs@ietf.org, Reddy K

(Write-up as of 02/07/2019; Outstanding issue:
** IPR Check: https://mailarchive.ietf.org/arch/msg/dots/p4APqoojMLOpXHyGmEnF6qzb9X0
)

The following is the shepherd write-up for draft-ietf-dots-architecture.

1. Summary

The document shepherd is Roman Danyliw. The responsible Area Director is Benjamin Kaduk.

This document specifies an architecture for deploying and operating Distributed Denial of Service (DDoS) Open Threat.  The document does not specify protocols or protocol extensions, instead it defines architectural relationships, components and concepts used in a DOTS deployment.

The WG has reached consensus to publish this draft as an Informational document.  It has been subjected to substantial review from the community of interest.  Publication of this draft has been intentionally delayed to coincide with the publication of the signal and data channel specifications

2. Review and Consensus
=====================
The WG adopted this draft in July 2016 (-00) from an individual submission which was first published in March 2016.  This draft has evolved through substantial WG discussions to the current -10 version. Feedback on this draft came from vendors, operators and the current implementers of the signal and data channels drafts that realize this architecture.

This draft iteratively evolved with further refinement of the use cases (draft-ietf-dots-use-cases); increased maturity of the signal (draft-ietf-dots-use-cases) and data (draft-ietf-dots-data-channel) channel; and corresponding interop feedback.  The notable evolutions of the draft were:

** Multi-homing architecture considerations were added and refined starting in -02, but ultimately removed by WG consensus and added to a separate document, draft-ietf-dots-multihoming-01.

** Addition of a construct for recursive signaling came in -04

** Guidance around handling environment with Network Address Translation first emerged in -06.

The WG convened a WGLC on -08 of the draft on November 27, 2018 (https://mailarchive.ietf.org/arch/msg/dots/DR2Pu9EzJXJn5uOQ13ien9vvqCY).  This feedback resulted in the publication of -09 and -10.  Key changes in these revisions included consistently clarifying the definition of a session; referencing a specific requirements (in draft-ietf-dots-requirements) and needed updates identified during the review of the signal channel (draft-ietf-dots-requirements).  Issues identified during AD and shepherd review were addressed in -11 and -12.

This draft has seen review from the WG, and there is a belief that it is ready for publication.

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the DOTS mailing list:

** Andrew Mortensen -- https://mailarchive.ietf.org/arch/msg/dots/e__fggpaCdNxHxmaImL2itmBXko
** Flemming Andreasen -- https://mailarchive.ietf.org/arch/msg/dots/22rdjU0yT0o0ax86F_pj-90sZFs
** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/XApYrdcWW2olOti-AIU97Og7X4Q
** Nik Teague --
** Christopher Gray --

There are no IPR disclosures on the document.

4. Other Points
============

[TO FIX] Idnits reported no issues that require action.

The draft contains no YANG or XML modules to validate.

The draft has no IANA actions.

Request for posting confirmation emailed to previous authors: " christopher_gray3@cable.comcast.com" , Nik Teague , Flemming Andreasen , Rich Compton , Andrew Mortensen , dots-chairs@ietf.org, Reddy K

(Write-up as of 02/07/2019; Outstanding issue:
** IPR Check: https://mailarchive.ietf.org/arch/msg/dots/p4APqoojMLOpXHyGmEnF6qzb9X0
)

The following is the shepherd write-up for draft-ietf-dots-architecture.

1. Summary

The document shepherd is Roman Danyliw. The responsible Area Director is Benjamin Kaduk.

This document specifies an architecture for deploying and operating Distributed Denial of Service (DDoS) Open Threat.  The document does not specify protocols or protocol extensions, instead it defines architectural relationships, components and concepts used in a DOTS deployment.

The WG has reached consensus to publish this draft as an Informational document.  It has been subjected to substantial review from the community of interest.  Publication of this draft has been intentionally delayed to coincide with the publication of the signal and data channel specifications

2. Review and Consensus
=====================
The WG adopted this draft in July 2016 (-00) from an individual submission which was first published in March 2016.  This draft has evolved through substantial WG discussions to the current -10 version. Feedback on this draft came from vendors, operators and the current implementers of the signal and data channels drafts that realize this architecture.

This draft iteratively evolved with further refinement of the use cases (draft-ietf-dots-use-cases); increased maturity of the signal (draft-ietf-dots-use-cases) and data (draft-ietf-dots-data-channel) channel; and corresponding interop feedback.  The notable evolutions of the draft were:

** Multi-homing architecture considerations were added and refined starting in -02, but ultimately removed by WG consensus and added to a separate document, draft-ietf-dots-multihoming-01.

** Addition of a construct for recursive signaling came in -04

** Guidance around handling environment with Network Address Translation first emerged in -06.

The WG convened a WGLC on -08 of the draft on November 27, 2018 (https://mailarchive.ietf.org/arch/msg/dots/DR2Pu9EzJXJn5uOQ13ien9vvqCY).  This feedback resulted in the publication of -09 and -10.  Key changes in these revisions included consistently clarifying the definition of a session; referencing a specific requirements (in draft-ietf-dots-requirements) and needed updates identified during the review of the signal channel (draft-ietf-dots-requirements).  Issues identified during AD and shepherd review were addressed in -11.

This draft has seen review from the WG, and there is a belief that it is ready for publication.

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the DOTS mailing list:

** Andrew Mortensen -- https://mailarchive.ietf.org/arch/msg/dots/e__fggpaCdNxHxmaImL2itmBXko
** Flemming Andreasen -- https://mailarchive.ietf.org/arch/msg/dots/22rdjU0yT0o0ax86F_pj-90sZFs
** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/XApYrdcWW2olOti-AIU97Og7X4Q
** Nik Teague --
** Christopher Gray --

There are no IPR disclosures on the document.

4. Other Points
============

[TO FIX] Idnits reported no issues that require action.

The draft contains no YANG or XML modules to validate.

The draft has no IANA actions.

(Write-up as of 02/07/2019; Outstanding issue:
** IPR Check: https://mailarchive.ietf.org/arch/msg/dots/p4APqoojMLOpXHyGmEnF6qzb9X0
)

The following is the shepherd write-up for draft-ietf-dots-architecture.

1. Summary

The document shepherd is Roman Danyliw. The responsible Area Director is Benjamin Kaduk.

This document specifies an architecture for deploying and operating Distributed Denial of Service (DDoS) Open Threat.  The document does not specify protocols or protocol extensions, instead it defines architectural relationships, components and concepts used in a DOTS deployment.

The WG has reached consensus to publish this draft as an Informational document.  It has been subjected to substantial review from the community of interest.  Publication of this draft has been intentionally delayed to coincide with the publication of the signal and data channel specifications

2. Review and Consensus
=====================
The WG adopted this draft in July 2016 (-00) from an individual submission which was first published in March 2016.  This draft has evolved through substantial WG discussions to the current -10 version. Feedback on this draft came from vendors, operators and the current implementers of the signal and data channels drafts that realize this architecture.

This draft iteratively evolved with further refinement of the use cases (draft-ietf-dots-use-cases); increased maturity of the signal (draft-ietf-dots-use-cases) and data (draft-ietf-dots-data-channel) channel; and corresponding interop feedback.  The notable evolutions of the draft were:

** Multi-homing architecture considerations were added and refined starting in -02, but ultimately removed by WG consensus and added to a separate document, draft-ietf-dots-multihoming-01.

** Addition of a construct for recursive signaling came in -04

** Guidance around handling environment with Network Address Translation first emerged in -06.

The WG convened a WGLC on -08 of the draft on November 27, 2018 (https://mailarchive.ietf.org/arch/msg/dots/DR2Pu9EzJXJn5uOQ13ien9vvqCY).  This feedback resulted in the publication of -09 and -10.  Key changes in these revisions included consistently clarifying the definition of a session; referencing a specific requirements (in draft-ietf-dots-requirements) and needed updates identified during the review of the signal channel (draft-ietf-dots-requirements).  Issues identified during AD and shepherd review were addressed in -11.

This draft has seen review from the WG, and there is a belief that it is ready for publication.

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the DOTS mailing list:

** Andrew Mortensen --
** Flemming Andreasen -- https://mailarchive.ietf.org/arch/msg/dots/22rdjU0yT0o0ax86F_pj-90sZFs
** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/XApYrdcWW2olOti-AIU97Og7X4Q
** Nik Teague --
** Christopher Gray --

There are no IPR disclosures on the document.

4. Other Points
============

[TO FIX] Idnits reported no issues that require action.

The draft contains no YANG or XML modules to validate.

The draft has no IANA actions.

(Write-up as of 02/07/2019; Outstanding issue:
** IPR Check: https://mailarchive.ietf.org/arch/msg/dots/p4APqoojMLOpXHyGmEnF6qzb9X0
)

The following is the shepherd write-up for draft-ietf-dots-architecture.

1. Summary

The document shepherd is Roman Danyliw. The responsible Area Director is Benjamin Kaduk.

This document specifies an architecture for deploying and operating Distributed Denial of Service (DDoS) Open Threat.  The document does not specify protocols or protocol extensions, instead it defines architectural relationships, components and concepts used in a DOTS deployment.

The WG has reached consensus to publish this draft as an Informational document.  It has been subjected to substantial review from the community of interest.  Publication of this draft has been intentionally delayed to coincide with the publication of the signal and data channel specifications

2. Review and Consensus
=====================
The WG adopted this draft in July 2016 (-00) from an individual submission which was first published in March 2016.  This draft has evolved through substantial WG discussions to the current -10 version. Feedback on this draft came from vendors, operators and the current implementers of the signal and data channels drafts that realize this architecture.

This draft iteratively evolved with further refinement of the use cases (draft-ietf-dots-use-cases); increased maturity of the signal (draft-ietf-dots-use-cases) and data (draft-ietf-dots-data-channel) channel; and corresponding interop feedback.  The notable evolutions of the draft were:

** Multi-homing architecture considerations were added and refined starting in -02, but ultimately removed by WG consensus and added to a separate document, draft-ietf-dots-multihoming-01.

** Addition of a construct for recursive signaling came in -04

** Guidance around handling environment with Network Address Translation first emerged in -06.

The WG convened a WGLC on -08 of the draft on November 27, 2018 (https://mailarchive.ietf.org/arch/msg/dots/DR2Pu9EzJXJn5uOQ13ien9vvqCY).  This feedback resulted in the publication of -09 and -10.  Key changes in these revisions included consistently clarifying the definition of a session; referencing a specific requirements (in draft-ietf-dots-requirements) and needed updates identified during the review of the signal channel (draft-ietf-dots-requirements).  Issues identified during shepherd review were addressed in -11.

This draft has seen review from the WG, and there is a belief that it is ready for publication.

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the DOTS mailing list:

** Andrew Mortensen --
** Flemming Andreasen -- https://mailarchive.ietf.org/arch/msg/dots/22rdjU0yT0o0ax86F_pj-90sZFs
** Tirumaleswar Reddy -- https://mailarchive.ietf.org/arch/msg/dots/XApYrdcWW2olOti-AIU97Og7X4Q
** Nik Teague --
** Christopher Gray --

There are no IPR disclosures on the document.

4. Other Points
============

[TO FIX] Idnits reported no issues that require action.

The draft contains no YANG or XML modules to validate.

The draft has no IANA actions.

Request for posting confirmation emailed to previous authors: " christopher_gray3@cable.comcast.com" , Nik Teague , Flemming Andreasen , Rich Compton , Andrew Mortensen , dots-chairs@ietf.org, Reddy K

(Write-up as of 02/04/2019; Outstanding issues:
** https://mailarchive.ietf.org/arch/msg/dots/K3KyCmM3y-hD5RgOoqHXw9Nb45Q
** https://mailarchive.ietf.org/arch/msg/dots/p4APqoojMLOpXHyGmEnF6qzb9X0
)

The following is the shepherd write-up for draft-ietf-dots-architecture.

1. Summary

The document shepherd is Roman Danyliw. The responsible Area Director is Benjamin Kaduk.

This document specifies an architecture for deploying and operating Distributed Denial of Service (DDoS) Open Threat.  The document does not specify protocols or protocol extensions, instead it defines architectural relationships, components and concepts used in a DOTS deployment.

The WG has reached consensus to publish this draft as an Informational document.  It has been subjected to substantial review from the community of interest.  Publication of this draft has been intentionally delayed to coincide with the publication of the signal and data channel specifications

2. Review and Consensus
=====================
The WG adopted this draft in July 2016 (-00) from an individual submission which was first published in March 2016.  This draft has evolved through substantial WG discussions to the current -10 version. Feedback on this draft came from vendors, operators and the current implementers of the signal and data channels drafts that realize this architecture.

This draft iteratively evolved with further refinement of the use cases (draft-ietf-dots-use-cases); increased maturity of the signal (draft-ietf-dots-use-cases) and data (draft-ietf-dots-data-channel) channel; and corresponding interop feedback.  The notable evolutions of the draft were:

** Multi-homing architecture considerations were added and refined starting in -02, but ultimately removed by WG consensus and added to a separate document, draft-ietf-dots-multihoming-01.

** Addition of a construct for recursive signaling came in -04

** Guidance around handling environment with Network Address Translation first emerged in -06.

The WG convened a WGLC on -08 of the draft on November 27, 2018 (https://mailarchive.ietf.org/arch/msg/dots/DR2Pu9EzJXJn5uOQ13ien9vvqCY).  This feedback resulted in the publication of -09 and -10.  Key changes in these revisions included consistently clarifying the definition of a session; referencing a specific requirements (in draft-ietf-dots-requirements) and needed updates identified during the review of the signal channel (draft-ietf-dots-requirements)

This draft has seen review from the WG, and there is a belief that it is ready for publication.

3. Intellectual Property
===================
Each author has confirmed conformance with BCPs 78 and 79 on the DOTS mailing list:

** Andrew Mortensen --
** Flemming Andreasen --
** Tirumaleswar Reddy --
** Nik Teague --
** Christopher Gray --

There are no IPR disclosures on the document.

4. Other Points
============

[TO FIX] Idnits reported no issues that require action.

The draft contains no YANG or XML modules to validate.

The draft has no IANA actions.

Request for posting confirmation emailed to previous authors: " christopher_gray3@cable.comcast.com" , Nik Teague , Flemming Andreasen , Rich Compton , Andrew Mortensen , dots-chairs@ietf.org, Reddy K

Request for posting confirmation emailed to previous authors: " christopher_gray3@cable.comcast.com" , Nik Teague , Flemming Andreasen , Andrew Mortensen , Rich Compton , dots-chairs@ietf.org, Reddy K

Request for posting confirmation emailed to previous authors: " christopher_gray3@cable.comcast.com" , Nik Teague , Flemming Andreasen , Andrew Mortensen , Rich Compton , dots-chairs@ietf.org, Reddy K

Request for posting confirmation emailed to previous authors: Tirumaleswar Reddy , " christopher_gray3@cable.comcast.com" , Nik Teague , Flemming Andreasen , Andrew Mortensen , Rich Compton , dots-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Tirumaleswar Reddy , " christopher_gray3@cable.comcast.com" , Nik Teague , Flemming Andreasen , Andrew Mortensen , Rich Compton , dots-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Tirumaleswar Reddy , " christopher_gray3@cable.comcast.com" , Nik Teague , Flemming Andreasen , Andrew Mortensen , Rich Compton , dots-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Tirumaleswar Reddy , " christopher_gray3@cable.comcast.com" , Nik Teague , Flemming Andreasen , Andrew Mortensen , Rich Compton , dots-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Tirumaleswar Reddy , Nik Teague , Flemming Andreasen , Andrew Mortensen , Rich Compton , Christopher Gray , dots-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Tirumaleswar Reddy , Nik Teague , Flemming Andreasen , Andrew Mortensen , Rich Compton , Christopher Gray , dots-chairs@ietf.org

Request for posting confirmation emailed to previous authors: "Andrew Mortensen" , " christopher_gray3@cable.comcast.com" , "Nik Teague" , "Rich Compton" , "Flemming Andreasen" , dots-chairs@ietf.org, "Tirumaleswar Reddy"