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

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Jul 2019 10:40:33 -0500

Hi Mirja,

Can you please let us know whether these replies address your concerns?

Thanks,

Ben

On Thu, May 02, 2019 at 11:54:50AM +0000, [email-masked] wrote:
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Mirja Kühlewind via Datatracker [mailto:[email-masked]]
> > Envoyé : jeudi 2 mai 2019 13:25
> > À : The IESG
> > Cc : [email-masked]; Roman Danyliw; dots-
> > [email-masked]; [email-masked]; [email-masked]
> > Objet : Mirja Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with
> > DISCUSS and COMMENT)
> > 
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-dots-data-channel-28: Discuss
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > I support Suresh's discuss that the process of how it is indicated if a 1 or
> > 2
> > byte mask is used is not clear. However, I would additionally like to discuss
> > why this bit mask is needed at all. The TCP flags field in RFC8519 is already
> > defined as bits. Storing these bits in a signal 8 bit field and applying a
> > matching operation is implementation specific only and doesn't require any
> > changes to the YANG model.
> 
> [Med] The motivation is similar to the one for the IPv4 flags:  
> 
>    Nevertheless,
>    the use of 'flags' is problematic since it does not allow to define a
>    bitmask.  For example, setting other bits not covered by the 'flags'
>    filtering clause in a packet will allow that packet to get through
>    (because it won't match the ACE).  
> 
> The use of bitmask will also ease inter-working witg BGP flowspec.
> 
> > 
> > I would also quickly like to discuss the use of keep-alives as described in
> > Section 3.1: "While the communication to the DOTS server is
> >    quiescent, the DOTS client MAY probe the server to ensure it has
> >    maintained cryptographic state.  Such probes can also keep alive
> >    firewall and/or NAT bindings.  A TLS heartbeat [RFC6520] verifies
> >    that the DOTS server still has TLS state by returning a TLS message."
> > I understood that multiple requests can and should be send in the same
> > connection, however, I would expect that those requests are send basically
> > right after each other, such as a look-up and then change of the config. I
> > don't see a need to keep up the connection for a long time otherwise.
> > Especially any action performed are (other than in the signal channel case)
> > not
> > time critical. Therefore I would rather recommend to close and reopen
> > connections and not recommend to use keep-alives at all.
> 
> [Med] The activity of the DOTS client may be used to track/detect stale entries:
> 
>    Also, DOTS servers
>    may track the inactivity timeout of DOTS clients to detect stale
>    entries.
> 
> 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Editorial comment: As alias 
> 
> [Med] The grouping "target" is defined in the data-channel, and reused in the signal channel. The name cannot be reused because it is a key of the aliases in data-channel and a node in the signal-channel. 
> 
> and migration-scope 
> 
> [Med] I guess you meant "mitigation-scope". There is no such item in the data channel. Please note that "ietf-data:target" is called in the signal-channel under mitigation-scope. 
> 
> (in the signal channel
> > document) have the same fields, wouldn't it make sense to only definite it
> > once
> > somewhere?
> > 
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 1 Jul 2019 18:30:10 +0200

Hi Ben, hi Med,

Please see below.

> On 1. Jul 2019, at 17:40, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Mirja,
> 

Okay, this is fine based on discussion with Suresh.

>>   may track the inactivity timeout of DOTS clients to detect stale
My understanding is that this is orthogonal. You can also see that a client is inactive when it didn’t open a new connection for a certain time…?

Mirja

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 2 Jul 2019 07:55:15 +0000

Hi Mirja,

Please see inline

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Mirja Kuehlewind
> Sent: Monday, July 1, 2019 10:00 PM
> To: Benjamin Kaduk <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; [email-masked]; The IESG <[email-masked]>;
> [email-masked]; [email-masked]; draft-ietf-dots-
> [email-masked]
> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-
> channel-28: (with DISCUSS and COMMENT)
> 
> 
> 
> Hi Ben, hi Med,
> 
> Please see below.
> 
> >>> Envoyé : jeudi 2 mai 2019 13:25 À : The IESG Cc :
> >>> [email-masked]; Roman Danyliw; dots-
> >>> [email-masked]; [email-masked]; [email-masked] Objet : Mirja
> >>> Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with
> >>> DISCUSS and COMMENT)
> >>>
> >>> When responding, please keep the subject line intact and reply to
> >>> all email addresses included in the To and CC lines. (Feel free to
> >>> cut this introductory paragraph, however.)
> >>>
> >>>
> >>> Please refer to
> >>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>> byte mask is used is not clear. However, I would additionally like
> >>> to discuss why this bit mask is needed at all. The TCP flags field
> >>> in RFC8519 is already defined as bits. Storing these bits in a
> >>> signal 8 bit field and applying a matching operation is
> >>> implementation specific only and doesn't require any changes to the
> YANG model.
> >>
> >>> I would also quickly like to discuss the use of keep-alives as
> >>> described in Section 3.1: "While the communication to the DOTS server is
> >>> I understood that multiple requests can and should be send in the
> >>> same connection, however, I would expect that those requests are
> >>> send basically right after each other, such as a look-up and then
> >>> change of the config. I don't see a need to keep up the connection for a
> long time otherwise.
> >>> Especially any action performed are (other than in the signal
> >>> channel case) not time critical. Therefore I would rather recommend
> >>> to close and reopen connections and not recommend to use keep-alives
> >>> at all.
> >>
> My understanding is that this is orthogonal. You can also see that a client is
> inactive when it didn’t open a new connection for a certain time…?

The drop-list rules could be frequently updated by the DOTS client based on the tests used by the DOTS client domain (e.g. cryptographic challenge) to detect whether the IP address is for legitimate use or not, or based on threat intelligence feeds from security vendors providing the botnet/malicious IP addresses feed.  Further, persistent DOTS data channel is required to handle updates to target resources (e.g. CDN hosting a domain, and it needs DDoS protection) and target IP/prefix may also change frequently (mobile branch office, prefix re-numbering etc.)

Further, we are not mandating the connection to be persistent, but when needed, the probe mechanism applies. Please note https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-13 discusses persistent-connection and it’s a client preference on how the connection is maintained (persistent or periodic).

Cheers,
-Tiru

> >> [Med] The grouping "target" is defined in the data-channel, and reused in
> the signal channel. The name cannot be reused because it is a key of the
> aliases in data-channel and a node in the signal-channel.
> >>
> >> and migration-scope
> >>
> >> [Med] I guess you meant "mitigation-scope". There is no such item in the
> data channel. Please note that "ietf-data:target" is called in the signal-
> channel under mitigation-scope.
> >>
> >> (in the signal channel
> >>> document) have the same fields, wouldn't it make sense to only
> >>> definite it once somewhere?
> >>>
> >>
> >
> >
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 2 Jul 2019 16:06:19 +0200

Hi Tiru,

Please see below.

> On 2. Jul 2019, at 09:55, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 

This still doesn’t sounds like it is desirable to keep the TCP connection open. Also if you can bear the time to reconnect (1-2 RTT for the handshake) that is usually the better and easier options. I don’t think the information we talk about here are that time-critical, is it? When you say frequent what time frame do you mean, Hours, minutes, seconds, milliseconds?

Mirja

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 2 Jul 2019 14:22:14 +0000

> From: Mirja Kuehlewind <[email-masked]>
> Sent: Tuesday, July 2, 2019 7:36 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: Benjamin Kaduk <[email-masked]>; Roman Danyliw <[email-masked]>;
> [email-masked]; The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> > On 2. Jul 2019, at 09:55, Konda, Tirumaleswar Reddy
> <[email-masked]> wrote:
> >
> >>>>> described in Section 3.1: "While the communication to the DOTS
> >>>>> server is  quiescent, the DOTS client MAY probe the server to
> >>>>> ensure it has  maintained cryptographic state.  Such probes can
> >>>>> also keep alive  firewall and/or NAT bindings.  A TLS heartbeat
> >>>>> [RFC6520] verifies  that the DOTS server still has TLS state by returning
> a TLS message."
> >>>>> channel case) not time critical. Therefore I would rather
> >>>>> recommend to close and reopen connections and not recommend to
> use
> >>>>> keep-alives at all.
> >>>>
> >>>> [Med] The activity of the DOTS client may be used to track/detect
> >>>> stale
> >> entries:
> >>>>
> >>>>  Also, DOTS servers
> >> My understanding is that this is orthogonal. You can also see that a
> >> client is inactive when it didn’t open a new connection for a certain time…?
> >
> > The drop-list rules could be frequently updated by the DOTS client
> > based on the tests used by the DOTS client domain (e.g. cryptographic
> > challenge) to detect whether the IP address is for legitimate use or
> > not, or based on threat intelligence feeds from security vendors
> > providing the botnet/malicious IP addresses feed.  Further, persistent
> > DOTS data channel is required to handle updates to target resources
> > (e.g. CDN hosting a domain, and it needs DDoS protection) and target
> > IP/prefix may also change frequently (mobile branch office, prefix
> > re-numbering etc.)
> 
> This still doesn’t sounds like it is desirable to keep the TCP connection open.
> Also if you can bear the time to reconnect (1-2 RTT for the handshake) that is
> usually the better and easier options. I don’t think the information we talk
> about here are that time-critical, is it? When you say frequent what time
> frame do you mean, Hours, minutes, seconds, milliseconds?

The frequency of updates to drop-list rules can be few milliseconds.  For example, CAPTCHA and cryptographic puzzles can be used by DOTS client domain to determine whether the IP address is used for legitimate purpose or not, and can configure the drop-list rules.
Further, the specification does not mandate the connection to be persistent, but when needed, the probe mechanism applies.

-Tiru

> 
> Mirja
> 
> 
> >
> > Further, we are not mandating the connection to be persistent, but when
> needed, the probe mechanism applies. Please note
> https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-13
> discusses persistent-connection and it’s a client preference on how the
> connection is maintained (persistent or periodic).

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 2 Jul 2019 17:50:00 +0200

Hi Tiru,

Below...

> On 2. Jul 2019, at 16:22, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 

Then it really seems to me that the document would need to provide further guidance when a persistent connection is useful or when it is recommend to close the connection (and reopen if needed).

Mirja

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 3 Jul 2019 08:00:57 +0000

Hi Mirja,

Please see inline 

> Sent: Tuesday, July 2, 2019 9:20 PM
> 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 Tiru,
> 
> Below...
> 
> > On 2. Jul 2019, at 16:22, Konda, Tirumaleswar Reddy
> >>>>>>> I understood that multiple requests can and should be send in
> >>>>>>> the same connection, however, I would expect that those requests
> >>>>>>> are send basically right after each other, such as a look-up and
> >>>>>>> then change of the config. I don't see a need to keep up the
> >>>>>>> connection for a
> >>>> long time otherwise.
> >>>> My understanding is that this is orthogonal. You can also see that
> >>>> a client is inactive when it didn’t open a new connection for a certain
> time…?
> >>>
> >>> providing the botnet/malicious IP addresses feed.  Further,
> >>> persistent DOTS data channel is required to handle updates to target
> >>> resources (e.g. CDN hosting a domain, and it needs DDoS protection)
> >>> and target IP/prefix may also change frequently (mobile branch
> >>> office, prefix re-numbering etc.)
> >>
> >> Also if you can bear the time to reconnect (1-2 RTT for the
> >> handshake) that is usually the better and easier options. I don’t
> >> think the information we talk about here are that time-critical, is
> >> it? When you say frequent what time frame do you mean, Hours, minutes,
> seconds, milliseconds?
> >
> > The frequency of updates to drop-list rules can be few milliseconds.  For
> example, CAPTCHA and cryptographic puzzles can be used by DOTS client
> domain to determine whether the IP address is used for legitimate purpose
> or not, and can configure the drop-list rules.
> > Further, the specification does not mandate the connection to be
> persistent, but when needed, the probe mechanism applies.
> 
> Then it really seems to me that the document would need to provide further
> guidance when a persistent connection is useful or when it is recommend to
> close the connection (and reopen if needed).

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
 
> >> https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-
> >> 13 discusses persistent-connection and it’s a client preference on
> >> how the connection is maintained (persistent or periodic).
> >

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 3 Jul 2019 18:41:10 +0200

Hi Tiru, hi Med,

Please see below.

> On 3. Jul 2019, at 10:00, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> Please see inline 
> 

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.

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?

Mirja

---

From: <[email-masked]>
Date: Wed, 3 Jul 2019 17:51:29 +0000

Re-,

Please see inline.

Cheers,
Med

> De : Mirja Kuehlewind [mailto:[email-masked]]
> Envoyé : mercredi 3 juillet 2019 18:41
> À : Konda, Tirumaleswar Reddy
> Cc : Roman Danyliw; [email-masked]; The IESG; [email-masked]; draft-
> [email-masked]; BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk
> Objet : Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-
> > On 3. Jul 2019, at 10:00, Konda, Tirumaleswar Reddy
> >>>> This still doesn’t sounds like it is desirable to keep the TCP
> connection
> >> open.
> 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.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 15 Jul 2019 12:36:04 +0000

Hi Mirja,

We have updated the draft to address your Discuss (please see https://tools.ietf.org/html/draft-ietf-dots-data-channel-30) and Med responded to your comments. 
Please have a look and approve the draft.

Best Regards,
-Tiru

> From: [email-masked]
> <[email-masked]>
> Sent: Wednesday, July 3, 2019 11:21 PM
> To: Mirja Kuehlewind <[email-masked]>; Konda, Tirumaleswar Reddy
> <[email-masked]>
> [email-masked]; [email-masked]; Benjamin Kaduk
> <[email-masked]>
> Subject: RE: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-
> > De : Mirja Kuehlewind [mailto:[email-masked]] Envoyé : mercredi 3
> > juillet 2019 18:41 À : Konda, Tirumaleswar Reddy Cc : Roman Danyliw;
> > [email-masked]; The IESG; [email-masked]; draft-
> > [email-masked]; BOUCADAIR Mohamed TGI/OLN;
> Benjamin
> > Kaduk Objet : Re: [Dots] Mirja Kühlewind's Discuss on
> > draft-ietf-dots-data-
> > >> 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 Tiru,
> > >>
> > >> Below...
> > >>
> > >>>>>>>>> I would also quickly like to discuss the use of keep-alives
> > >>>>>>>>> as described in Section 3.1: "While the communication to the
> > >>>>>>>>> DOTS server is  quiescent, the DOTS client MAY probe the
> > >>>>>>>>> server to ensure it has  maintained cryptographic state.
> > >>>>>>>>> Such probes can also keep alive  firewall and/or NAT
> > >>>>>>>>> bindings.  A TLS heartbeat [RFC6520] verifies  that the DOTS
> > >>>>>>>>> server still has TLS state by returning
> > >>>> a TLS message."
> > >>>>>>>>> I understood that multiple requests can and should be send
> > >>>>>>>>> in the same connection, however, I would expect that those
> > >>>>>>>>> requests are send basically right after each other, such as
> > >>>>>>>>> a look-up and then change of the config. I don't see a need
> > >>>>>>>>> to keep up the connection for a
> > >>>>>> long time otherwise.
> > >>>>>>>>> Especially any action performed are (other than in the
> > >>>>>>>>> signal channel case) not time critical. Therefore I would
> > >>>>>>>>> rather recommend to close and reopen connections and not
> > >>>>>>>>> recommend
> > >> to
> > >>>> use
> > >>>>>>>>> keep-alives at all.
> > >>>>>>>>
> > >>>>>>>> [Med] The activity of the DOTS client may be used to
> > >>>>>>>> track/detect stale
> > >>>>>> entries:
> > >>>>>>>>
> > >>>>>>>> Also, DOTS servers
> > >>>>>>>> may track the inactivity timeout of DOTS clients to detect
> > >>>>>>>> stale entries.
> > >>>>>>>>
> > >>>>>> My understanding is that this is orthogonal. You can also see
> > >>>>>> that a client is inactive when it didn’t open a new connection
> > >>>>>> for a
> > certain
> > >> time…?
> > >>>>>
> > >>>>> The drop-list rules could be frequently updated by the DOTS
> > >>>>> client based on the tests used by the DOTS client domain (e.g.
> > >>>>> cryptographic
> > >>>>> challenge) to detect whether the IP address is for legitimate
> > >>>>> use or not, or based on threat intelligence feeds from security
> > >>>>> vendors providing the botnet/malicious IP addresses feed.
> > >>>>> Further, persistent DOTS data channel is required to handle
> > >>>>> updates to target resources (e.g. CDN hosting a domain, and it
> > >>>>> needs DDoS protection) and target IP/prefix may also change
> > >>>>> frequently (mobile branch office, prefix re-numbering etc.)
> > >>>>
> > >>>> think the information we talk about here are that time-critical,
> > >>>> is it? When you say frequent what time frame do you mean, Hours,
> > minutes,
> > >> seconds, milliseconds?
> > >>>
> > >> example, CAPTCHA and cryptographic puzzles can be used by DOTS
> > >> client domain to determine whether the IP address is used for
> > >> legitimate
> > purpose
> > >> guidance when a persistent connection is useful or when it is
> > >> recommend
> > to
> > 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.
> 
> 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?
> >
> 
> We didn't touched on connection management because we are relying on
> RESTCONF. DOTS will use whatever strategy adopted for RESTCONF.
> 
> > >>>> 13 discusses persistent-connection and it’s a client preference
> > >>>> on how the connection is maintained (persistent or periodic).
> > >>>
> > >

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 16 Jul 2019 17:16:09 +0200

Hi Med,

Sorry for my late reply.

One minor comment below:

> On 3. Jul 2019, at 19:51, [email-masked] wrote:
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 

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.

Thanks!
Mirja

---

From: <[email-masked]>
Date: Wed, 17 Jul 2019 08:10:07 +0000

Hi Mirja, 

Please see inline.

Cheers,
Med

> Envoyé : mardi 16 juillet 2019 17:16
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Konda, Tirumaleswar Reddy; Roman Danyliw; [email-masked]; Benjamin
> Kaduk; The IESG; [email-masked]; draft-ietf-dots-data-
> [email-masked]
[snip]
> > 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.
> >
> >>
> good
> 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?

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 17 Jul 2019 10:54:58 +0200

Hi Med,

Thanks that would be great!

Mirja

> On 17. Jul 2019, at 10:10, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Mirja, 
> 
> Please see inline.
> 
> Cheers,
> Med
>