Subject: [Dots] Review of draft-ietf-dots-data-channel-01

From: "Jon Shallow" <[email-masked]>
Date: Thu, 8 Jun 2017 10:31:09 +0100

Hi there,

Some comments

#1 Page 3

"Filter management, which enables a DOTS client to install or
      remove traffic filters, dropping or rate-limiting unwanted traffic
      and permitting white-listed traffic.  Sample use cases for
      populating black- or white-list filtering rules are detailed
      hereafter:"

As in the following narrative, the DOTS client is not installing on itself the traffic filters etc. but is informing the DOTS gateway / server to do so - who optionally can ignore the request.  I believe that this should read
"... enables a DOTS client to request the installation or removal of traffic filters, dropping ...."

Same for 3.1.3#

------

I believe that ietf-dots-data-channel-identifier should also contain optional support for ICMP types and codes (e.g. to handle blacknurse).

I believe that ietf-dots-data-channel-identifier should also contain optional support for dropping fragmented packets.

Regards

Jon

---

From: <[email-masked]>
Date: Thu, 8 Jun 2017 11:37:16 +0000

Hi Jon, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Jon Shallow
> Envoyé : jeudi 8 juin 2017 11:31
> À : [email-masked]
> Objet : [Dots] Review of draft-ietf-dots-data-channel-01
> 
> Hi there,
> 
> Some comments
> 
> #1 Page 3
> 
> As in the following narrative, the DOTS client is not installing on itself
> the traffic filters etc. but is informing the DOTS gateway / server to do
> so - who optionally can ignore the request.  I believe that this should
> read

[Med] Works for me.

> Same for 3.1.3#

[Med] I guess you are referring to: 

   o  Filter management, which enables a DOTS client to install or
      remove traffic filters, dropping or rate-limiting unwanted traffic
      and permitting white-listed traffic.

> 
> ------
> 
> I believe that ietf-dots-data-channel-identifier should also contain
> optional support for ICMP types and codes (e.g. to handle blacknurse).
> 
[Med] ICMP is supported given that this draft relies upon I-D.ietf-netmod-acl-model.

> I believe that ietf-dots-data-channel-identifier should also contain
> optional support for dropping fragmented packets.
> 

[Med] Idem as above.

> Regards
> 
> Jon
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 8 Jun 2017 13:42:51 +0100

Hi Med,

Thanks for your feedback. 

Yes, you are referring to the correct entity in 3.1.3# that is confusing in
the use of the word install.

In my experience if something is not specified, but can be optionally
defined, then incompatible variants will start to get used causing later
challenges of interoperability.  So putting in a place holder hinting at /
recommending how it should be done is much more preferable for ICMP and/or
Fragmentation handling.  Perhaps the appropriate augment statements should
be defined.

Regards

Jon

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 08 June 2017 12:37
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Review of draft-ietf-dots-data-channel-01

Hi Jon, 

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 8 juin 2017 11:31 À : [email-masked] Objet : [Dots] 
> Review of draft-ietf-dots-data-channel-01
> 
> Hi there,
> 
> Some comments
> 
> #1 Page 3
> 
> As in the following narrative, the DOTS client is not installing on 
> itself the traffic filters etc. but is informing the DOTS gateway / 
> server to do so - who optionally can ignore the request.  I believe 
> that this should read "... enables a DOTS client to request the 
> installation or removal of traffic filters, dropping ...."

[Med] Works for me.

> optional support for ICMP types and codes (e.g. to handle blacknurse).
[Med] ICMP is supported given that this draft relies upon
I-D.ietf-netmod-acl-model.

[Med] Idem as above.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 12 Jun 2017 14:30:05 +0000

Hi Jon,

Thanks for the review. Fixed comments 1 and 2 in my local copy. To support filtering rules based on ICMP type and code, and filtering based on fragments, the base ACL model defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be extended in this draft using augmentation (see https://tools.ietf.org/html/rfc6020#section-4.2.8). 

I will extend the ACL YANG model in the next revision. 

Cheers,
-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Thursday, June 8, 2017 6:13 PM
> To: [email-masked]
> Yes, you are referring to the correct entity in 3.1.3# that is confusing in the
> use of the word install.
> 
> In my experience if something is not specified, but can be optionally defined,
> then incompatible variants will start to get used causing later challenges of
> interoperability.  So putting in a place holder hinting at / recommending how
> it should be done is much more preferable for ICMP and/or Fragmentation
> handling.  Perhaps the appropriate augment statements should be defined.
> 
> Regards
> 
> Jon
>