Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hi Mirja, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:[e-mail]]
> Envoyé : mardi 16 juillet 2019 17:16
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Konda, Tirumaleswar Reddy; Roman Danyliw; [e-mail]; Benjamin
> Kaduk; The IESG; [e-mail]; draft-ietf-dots-data-
> [e-mail]
> Objet : Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-
> channel-28: (with DISCUSS and COMMENT)
> 
[snip]
> >>>
> >>> Sure, will add the following text:
> >>>
> >>>  A DOTS client can either maintain a persistent connection or periodic
> >>>  connections with its DOTS server(s).  If the DOTS client needs to
> >>>  frequently update the drop-list or accept-list filtering rules or
> >>>  aliases, it maintains a persistent connection with the DOTS server.
> >>>  For example, CAPTCHA and cryptographic puzzles can be used by the
> >>>  mitigation service in the DOTS client domain to determine whether the
> >>>  IP address is used for legitimate purpose or not, and the DOTS client
> >>>  can frequently update the drop-list filtering rules.  A persistent
> >>>  connection is also useful if the DOTS client subscribes to event
> >>>  notifications (Section 6.3 of [RFC8040]).
> >>>
> >>> - Tiru and Med
> >>
> >> Thanks!
> >>
> >> Two more small comments:
> >>
> >> At least to me the term “periodic" is not clear. I guess mean something
> >> like short-lived connections, where you have a request, you open a
> >> connection, send it, get a reply, and close the connection immediately
> or
> >> after a short idle period. Or is there actually any kind of periodicity
> in
> >> the dots protocol in general? Can you pleas clarify.
> >
> > [Med] We are trying to reuse the same terminology as RESTCONF (draft-
> ietf-netconf-restconf-client-server).
> >
> > For the DOTS case, the DOTS client is required to register and send
> requests to refresh the registration in regular intervals (otherwise, the
> DOTS client won't be able to created filters). Likewise, cycles will be
> observed because the client will need to maintains the aliases and ACLs it
> created. The client may use these cycles for any planned activity (create
> new aliases, create a new filter, etc.) or not.
> >
> >>
> >> Also if a persistent connection is used, I think it would (again) be
> good
> >> to clarify what should be done if the connection fails. I think the
> right
> >> advise in this case, is to not reconnect immediately but only if you
> have
> >> another request to send, right?
> >>
> >
> > [Med] draft-ietf-netconf-restconf-client-server voices for the
> following:
> >
> >   Maintain a persistent connection to the
> >   RESTCONF server. If the connection goes down,
> >   immediately start trying to reconnect to the
> >   RESTCONF server, using the reconnection strategy.
> >
> > Which is the right approach, IMO.
> >
> > We didn't touched on connection management because we are relying on
> RESTCONF. DOTS will use whatever strategy adopted for RESTCONF.
> >
> > I don't think it is a good idea to add specific behavior into our spec.
> 
> That is fine. I wasn’t aware that this is specified like this in RESTCONF
> and that your are replying on it. Instead of (re-)specifying in this in
> document, I would recommend to actually add a reference to this part  of
> the RESTCONF document and make clear that this is what you are replying
> on.

[Med] We can cite draft-ietf-netconf-restconf-client-server as an informative reference with the following text:

   Additional considerations
   related to RESTCONF connection management (including, configuring the
   connection type or the reconnect strategy) can be found in
   [I-D.ietf-netconf-restconf-client-server].

Better?

> 
> Thanks!
> Mirja