Shepherd writeup
rfc8783-31

The following is the shepherd write-up for draft-ietf-dots-data-channel-22.

1. Summary

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

This document specifies the DOTS data channel, one of two protocols (the other being the DOTS signal channel – draft-ietf-dots-signal-channel) that enables the exchange of information necessary to mitigate a DDoS attack.  This data channel protocol allows the exchange of information that is not appropriate to send under attack conditions.

The WG has reached consensus to publish this protocol specification as a Proposed Standard.  It has been subjected to substantial review from the community of interest and implementations.

2. Review and Consensus
=====================
The WG adopted this draft in April 2017 (-00) from an individual submission which was first published in August 2016.  This draft has evolved through design and implementation feedback to the current -22 version. 

There have been three implementations of the draft, one open source and two proprietary from the following vendors:
** go-dots (NTT) -- https://github.com/nttdots/go-dots
** NCC Group 
** Huawei

Older versions of the draft were used in interops at the Hackathons of IETF 100 and 101 to enable end-to-end testing for DOTS agents.  At the IETF 102 Hackathon, there was an inter-op specifically focused on testing between these three implementations per the -16 of the draft.  Identified issues were fixed in draft versions -17 and -18.  The full results of the inter-op can be seen here:
https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-ietf-102-hackathon-interop-report-00.  Final issues were identified and resolved at the IETF 103 Interop, https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00.

The WG convened a WGLC on -18 of the draft from August 10 – 27, 2018 (https://www.ietf.org/mail-archive/web/dots/current/msg02547.html).  Robust feedback occurred which resulted in the publication of -19, -20 and -21.

Feedback during the shepherding preparation produced -22 to address editorial issues.

This data channel protocol has a companion signal channel protocol (draft-ietf-dots-signal-channel) in DOTS which has also been submitted for publications.

This draft has seen extensive review from the WG and from implementers.  There was early coordination with the NETCONF WG on ACL YANG modules.  The WG believes it is ready for publication.

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

** Mohammed Boucadair -- https://www.ietf.org/mail-archive/web/dots/current/msg02699.html
** Tirumal Reddy -- https://www.ietf.org/mail-archive/web/dots/current/msg02702.html 
** Kaname Nishizuka -- https://www.ietf.org/mail-archive/web/dots/current/msg02700.html
** Liang Xia -- https://www.ietf.org/mail-archive/web/dots/current/msg02701.html
** Prashanth Patil – https://www.ietf.org/mail-archive/web/dots/current/msg02704.html
** Andrew Mortensen – https://www.ietf.org/mail-archive/web/dots/current/msg02705.html
** Nik Teague -- https://www.ietf.org/mail-archive/web/dots/current/msg02703.html

There are no IPR disclosures on the document.

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

Idnits reports the following issues which do not require action:

(** error **)  “The abstract seems to contain references”  The abstract does contain these references but only in guidance to the RFC Editor who will remove them prior to publication.

(== warnings ==) The four “xx has weird spacing” instances are pointing to an figure depicting a YANG model and can be ignored

(-- comments --) The four “Looks like a reference” instances are pointing to an example and can be ignored.

The yang modules in the draft were validated as having no errors using www.yangvalidator.com (that was configured as follows -- validator version: 0.3.1, xym version: 0.4, pyang version: 1.7.3 confdc version: confd-6.5.3 , yanglint version: yanglint 0.14.69)

There are two actions for IANA:
 
(1) Registration of a new URI, urn:ietf:params:xml:ns:yang:ietf-dots-data-channel, in the “IETF XML Registry"; and 
(2) Registration of new YANG module, ietf-dots-data-channel, in the “YANG Module Names” registry

No early expert review has been requested for the above IANA allocation.


Back