Re: [Dots] Comments on dots-signal-control-filtering-01

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of
> [e-mail]
> Sent: Friday, January 18, 2019 12:37 PM
> To: Takahiko Nagata <[e-mail]>; [e-mail]
> Subject: Re: [Dots] Comments on dots-signal-control-filtering-01
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> Hi Takahiko,
> 
> Thank you for sharing the comments.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots [mailto:[e-mail]] De la part de Takahiko Nagata
> > Envoyé : jeudi 17 janvier 2019 08:13 À : [e-mail] Objet : [Dots]
> > Comments on dots-signal-control-filtering-01
> >
> > Hi Kaname,
> >
> > I would like to 2 comments on dots-signal-control-filtering-01.
> >
> > (Comment1) Minimal attributes for control-filtering. ("lifetime" behavior)
> >   Minimal attributes of SignalChannel MitigationRequest
> >   for control-filtering is only the followings, I think.
> >   - acl-list(acl-name, activation-type)
> >   - lifetime
> >
> >   So, We can send acl-list via SignalChannel without
> >   other Mitigation request parameters.
> 
> [Med] When the same mid is used, the request is considered as a refresh. As
> such the attributes that were included in the first request must be included.
> 
> >
> >   In this case, we need to decide behavior of "lifetime".
> >   I think "lifetime" is ignored in this case.
> 
> [Med] No. This is a particular case of this text from the signal channel spec:
> 
>    For a mitigation request to continue beyond the initial negotiated
>    lifetime, the DOTS client has to refresh the current mitigation
>    request by sending a new PUT request.  This PUT request MUST use the
>    same 'mid' value, and MUST repeat all the other parameters as sent in
>    the original mitigation request apart from a possible change to the
>    lifetime parameter value.
> 
> >   Because acl-list(acl-name, activation-type) should be
> >   managed only DataChannel side for specification simply.
> >
> >
> > (Comment2) Should be specified behavior.
> > (a) Not be affected by "trigger-mitigation"
> >   acl-list(acl-name, activation-type) is soon be applied
> >   even if "trigger-mitigation" is false.
> 
> [Med] The procedure applies independently of the value of "trigger-mitigation".
> We can say this explicitly on the draft.

A Mitigation request with "trigger-mitigation" set to false must only be sent in the peace time and not during the attack time. During the peace time, I don't see the need to activate/de-activate 
ACLs using DOTS signal channel protocol.

Cheers,
-Tiru

> 
> >
> > (b) Do not affect to "Efficacy Update"
> >   acl-list(acl-name, activation-type) would be ignored
> >   at "Efficacy Update" success or reject.
> 
> [Med] Agree. We are not updating that part of the signal channel spec. acl-list
> clauses won't be included in the efficacy update.
> 
> >
> > (c) GET response of Mitigation Request
> >   acl-list(acl-name, activation-type) would not be included
> >   on respose of GET Mitigation Request.
> 
> [Med] Yes. Will be make this clear in the draft.
> 
> >
> > (d) In DELETE, no behavior(ex: rollback) for acl-list.
> 
> [Med] Yes.
> 
> >
> >
> > Best Regards,
> > Takahiko Nagata
> >
> > _______________________________________________
> > Dots mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots