Subject: [Dots] TR: New Version Notification for draft-nishizuka-dots-signal-control-filtering-06.txt

From: <[email-masked]>
Date: Tue, 2 Apr 2019 13:13:05 +0000

Hi all, 

This version takes into account the comments received in Prague. 

The text was also restructured for a better readability. 

Questions, comments, and suggestions are more than welcome. 

Cheers,
Med

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> Envoyé : mardi 2 avril 2019 15:11
> À : Takahiko Nagata; Tirumaleswar Reddy; BOUCADAIR Mohamed TGI/OLN; Reddy K;
> Kaname Nishizuka
> Objet : New Version Notification for draft-nishizuka-dots-signal-control-
> filtering-06.txt
> 
> 
> A new version of I-D, draft-nishizuka-dots-signal-control-filtering-06.txt
> has been successfully submitted by Mohamed Boucadair and posted to the
> IETF repository.
> 
> Name:		draft-nishizuka-dots-signal-control-filtering
> Revision:	06
> Title:		Controlling Filtering Rules Using Distributed Denial-of-
> Service Open Threat Signaling (DOTS) Signal Channel
> Document date:	2019-04-02
> Group:		Individual Submission
> Pages:		23
> URL:            https://www.ietf.org/internet-drafts/draft-nishizuka-dots-
> signal-control-filtering-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-nishizuka-dots-signal-
> control-filtering/
> Htmlized:       https://tools.ietf.org/html/draft-nishizuka-dots-signal-
> control-filtering-06
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nishizuka-dots-
> signal-control-filtering
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-nishizuka-dots-
> signal-control-filtering-06
> 
> Abstract:
>    This document specifies an extension to the DOTS signal channel so
>    that DOTS clients can control their filtering rules when an attack
>    mitigation is active.
> 
>    Particularly, this extension allows a DOTS client to activate or de-
>    activate existing filtering rules during a DDoS attack.  The
>    characterization of these filtering rules is supposed to be conveyed
>    by a DOTS client during an idle time by means of the DOTS data
>    channel protocol.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>    Please update these statements within the document 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: Controlling Filtering Rules Using Distributed Denial-
>       of-Service Open Threat Signaling (DOTS) Signal Channel";
> 
>    o  reference: RFC XXXX
> 
>    o  [RFCXXXX]
> 
>    Please update these statements with the RFC number to be assigned to
>    the following documents:
> 
>    o  "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling
>       (DOTS) Signal Channel Specification" (used to be
>       [I-D.ietf-dots-signal-channel])
> 
>    o  "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling
>       (DOTS) Data Channel Specification" (used to be
>       [I-D.ietf-dots-data-channel])
> 
>    Please update the "revision" date of the YANG module.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 2 Apr 2019 15:21:27 +0100

Hi Med,

Thanks for this.

Clarification / comment

3.2.1  Parameters & Behaviors
...
acl-name:  A name of an access list defined using the DOTS data
  channel (Section 7.2 of [I-D.ietf-dots-data-channel]).

The acl-name is unique per cuid, but the name can be duplicated, so perhaps

Updated

acl-name:  A name of an access list defined using the DOTS data
  channel (Section 7.2 of [I-D.ietf-dots-data-channel]) that is associated with the DOTS client's 'cuid'.

Old
Figure 5: GET to Retrieve the Filtering (After Mitigation)
New
Figure 5: DOTS Data Channel GET response after Mitigation

Old
Figure 6: DOTS Data Channel Request to Create an Accep-List Filter
New
Figure 6: DOTS Data Channel Request to Create an Accept-List Filter

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: [email-masked]] On Behalf Of
> [email-masked]
> Sent: 02 April 2019 14:13
> To: [email-masked]
> Subject: [Dots] TR: New Version Notification for draft-nishizuka-dots-signal-
> control-filtering-06.txt
> 
> Hi all,
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Tue, 2 Apr 2019 14:45:24 +0000

Hi Jon, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : mardi 2 avril 2019 16:21
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Objet : RE: [Dots] TR: New Version Notification for draft-nishizuka-dots-

[Med] Indeed. We do already have the following in Section 3.1:

"Note that an ACL name unambiguously identifies an ACL bound to a DOTS client, but the same name may be used by distinct DOTS clients."

> with the DOTS client's 'cuid'.

[Med] Sure (even if this is implied by the reference to the data channel spec). 

I added: "that is associated with the DOTS client."

No need to mention the cuid (again) given the discussion in Section 3.1.

> Figure 5: DOTS Data Channel GET response after Mitigation

[Med] OK.

> Figure 6: DOTS Data Channel Request to Create an Accept-List Filter

[Med] Thanks for catching the missing "t". Fixed.