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.