Re: [Dots] clarification questions from the hackathon

Hi Med,

Changes look good to me - thanks.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of 
mohamed.boucadair@orange.com
> Sent: 01 April 2019 12:13
> To: Jon Shallow; kaname nishizuka; dots@ietf.org
> Subject: Re: [Dots] clarification questions from the hackathon
> 
> 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:dots-bounces@ietf.org] De la part de kaname
> nishizuka
> > > > > Envoyé : jeudi 28 mars 2019 11:38
> > > > > À : dots@ietf.org
> > > > > 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.
> >
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots