Re: [Dots] clarification questions from the hackathon

[<[e-mail]>]

Jon, Kaname, all, 

FWIW, a proposal to integrate the interop comments is available at: 
https://github.com/boucadair/filter-control/blob/master/wdiff%20draft-nishizuka-dots-signal-control-filtering-05.txt%20draft-nishizuka-dots-signal-control-filtering-06.pdf 

Cheers,
Med

> > >
> > > > -----Message d'origine-----
> > > > De : Dots [mailto:[e-mail]] De la part de kaname nishizuka
> > > > Envoyé : jeudi 28 mars 2019 11:38
> > > > À : [e-mail]
> > > > Objet : [Dots] clarification questions from the hackathon
> > > >
> > > > Hi,
> > > >
> > > > I'd like to continue discussion of these topics in the ML.
> > > >
> > > > #1: Questions about signal-control-filtering
> > > >   1. Should a mitigation request create a mitigation before doing a PUT
> +
> > > > acl-list [{acl-name, activation-type}] against the active mitigation,
> or
> > is a
> > > > ‘PUT + acl-list [{acl-name, activation-type}]’ allowed to create a new
> > > > mitigation?
> > >
> > > [Med] Both are currently allowed in the draft. I don't still a valid
> reason
> > to
> > > restrict this.
> >
> > [Jon] As per draft
> >    A DOTS client MUST NOT use the filtering control over DOTS signal
> >    channel if no attack (mitigation) is active;
> >
> 
> [Med] What is meant actually is:
> 
>    A DOTS client MUST NOT use the filtering control over DOTS signal
>    channel in 'idle' time;
> 
> Will update the text.
> 
> > [Jon] then needs to be reworded as there is no active mitigation until the
> > PUT is done...
> > I believe that both cases should be supported.
> > >
> > > >   2. Should the response to a GET (or Observed GET) include the acl-
> list
> > > > [{acl-name, activation-type}] if the PUT included it?
> > >
> > > [Med] The current spec says "no". That's said, what would be the value in
> > > returning it? Then, why not allowing to return the references to all ACLs
> > that
> > > are enabled during the mitigation time?
> > >
> > [Jon] When observing the mitigation request, if the activation-type is
> > changed externally, the client will then know about the change. Assuming
> the
> > response got back to the client, this is effectively an ACK to the fact
> that
> > the ACL change got through.
> 
> [Med] The observe case makes sense, indeed.
> 
> >
> > Interesting concept about knowing about all the relevant ACLs as returned
> > over the signal channel.  More work for the server to do in determining
> which
> > ACLs are valid for, say, a specific IP address that is being mitigated.
> Not
> > entirely convinced of the benefit of this as this generally is available
> over
> > the data channel.
> >
> 
> [Med] I'm not convinced, either.
>