Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt

From: [email-masked]
Date: Thu, 19 Apr 2018 00:15:09 -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 WG of the IETF.

        Title           : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
        Authors         : Tirumaleswar Reddy
                          Mohamed Boucadair
                          Kaname Nishizuka
                          Liang Xia
                          Prashanth Patil
                          Andrew Mortensen
                          Nik Teague
	Filename        : draft-ietf-dots-data-channel-15.txt
	Pages           : 59
	Date            : 2018-04-19

Abstract:
   The document specifies a Distributed Denial-of-Service Open Threat
   Signaling (DOTS) data channel used for bulk exchange of data that
   cannot easily or appropriately communicated through the DOTS signal
   channel under attack conditions.

   This is a companion document to the DOTS signal channel
   specification.

Editorial Note (To be removed by RFC Editor)

   Please update these statements with the RFC number to be assigned to
   this document:

   o  "This version of this YANG module is part of RFC XXXX;"

   o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
      (DOTS) Data Channel Specification";

   o  reference: RFC XXXX

   Please update these statements with the RFC number to be assigned to
   the following documents:

   o  "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
      (DOTS) Signal Channel Specification" (used to be
      [I-D.ietf-dots-signal-channel])

   o  "RFC ZZZZ: Network Access Control List (ACL) YANG Data Model"
      (used to be [I-D.ietf-netmod-acl-model])

   Please update the "revision" date of the YANG module.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dots-data-channel-15
https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-15

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: <[email-masked]>
Date: Thu, 19 Apr 2018 07:24:13 +0000

Hi all, 

This new version integrates the outcome of the discussion related to the handling of IPv4 fragments. An appendix is added to illustrate examples with fragment handling. 

A keyword is still present for the IPv6 given that the netmod-acl specification is not clear whether "protocol" covers the base header and "next-header" of any enclosed header. Authors/shepherded of the netmod-acl I-D was contacted to clarify this; no feedback from them (yet). 

We received an offline comment from Jon asking to change "rate-limit decimal64" to "uint32" or "uint64", but we didn't implemented any change at this stage because the use of decimal64 is aligned with RFC5575 and also the format used for rate definition in other RFCs such as https://tools.ietf.org/html/rfc2212. If you think that in the context of DOTS, we don't need to align with existing specs or that in the context of massive DDoS, we don't need to concern ourselves with sub byte precision, please let us know. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de internet-
> [email-masked]
> Envoyé : jeudi 19 avril 2018 09:15
> À : [email-masked]
> Cc : [email-masked]
> Objet : [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 19 Apr 2018 19:53:07 +0900

Hi Med,

Thank you for updating the draft.
I'd like to note 2 typos.

Figure 19: An Example of Response Body
- "traffic-protocol": [
+ "target-protocol": [

Figure 23: Reply to a GET Response with Filtering Capabilities
- "rate-limit": "true",
+ "rate-limit": true,
(it's boolean)

And please consider to put the latest draft on github repo of dotswg and keep it to be latest in order to make this kind of tiny pull request easily merged.
https://github.com/dotswg/dots-data-channel

thank you,
Kaname

---

From: <[email-masked]>
Date: Thu, 19 Apr 2018 12:12:23 +0000

Hi Kaname, 

Thank you for catching those. 

Fixed. Pleased check at https://github.com/boucadair/draft-ietf-dots-data-channel. 

Cheers,
Med

> De : kaname nishizuka [mailto:[email-masked]]
> Envoyé : jeudi 19 avril 2018 12:53
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : Re: [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt
> 
> Hi Med,
> 
> And please consider to put the latest draft on github repo of dotswg and keep
> it to be latest in order to make this kind of tiny pull request easily
> merged.
> > This new version integrates the outcome of the discussion related to the
> handling of IPv4 fragments. An appendix is added to illustrate examples with
> fragment handling.
> >
> > A keyword is still present for the IPv6 given that the netmod-acl
> specification is not clear whether "protocol" covers the base header and
> "next-header" of any enclosed header. Authors/shepherded of the netmod-acl I-
> D was contacted to clarify this; no feedback from them (yet).
> >
> > We received an offline comment from Jon asking to change "rate-limit
> decimal64" to "uint32" or "uint64", but we didn't implemented any change at
> this stage because the use of decimal64 is aligned with RFC5575 and also the
> format used for rate definition in other RFCs such as
> https://tools.ietf.org/html/rfc2212. If you think that in the context of
> DOTS, we don't need to align with existing specs or that in the context of
> massive DDoS, we don't need to concern ourselves with sub byte precision,
> please let us know.
> >
> > Cheers,
> > Med
> >
> >>          Title           : Distributed Denial-of-Service Open Threat
> Signaling
> >> (DOTS) Data Channel Specification