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

Hi Jon, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
> Envoyé : mardi 2 avril 2019 16:21
> À : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
> Objet : RE: [Dots] TR: New Version Notification for draft-nishizuka-dots-
> signal-control-filtering-06.txt
> 
> 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

[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."

> 
> 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'.

[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.

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

[Med] OK.

> 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
> 

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

> 
> Regards
> 
> Jon
> 
> > -----Original Message-----
> > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of
> > mohamed.boucadair@orange.com
> > Sent: 02 April 2019 14:13
> > To: dots@ietf.org
> > Subject: [Dots] TR: New Version Notification for draft-nishizuka-dots-
> signal-
> > control-filtering-06.txt
> >
> > 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 : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > 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
> >
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots