Subject: [Dots] high-level questions about the signal channel

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Oct 2018 16:31:11 -0500

Hi folks,

I'm still working through my AD review of the signal channel doc (my
apologies for it taking so long!), and I have a couple of high-level
questions that it seems worth talking about in parallel with the rest of my
review.

All of the CoAP resources are under .well-known/dots/, but we have
requested/allocated a dedicated port for dots usage.  It seems that we
could assert that dots is the only service running on that port and get
shorter URLs instead of using this prefix.  I mostly assume that this was
well-discussed before I started following the WG, so hopefully there is an
easy pointer to the list archives that I can read up on.

In a similar vein, using "cuid-<foo>" and "mid=<bar>" and such in uri-paths
feels unusual to me (in that the assignment feels like a parameter that
belongs in the request body as opposed to a path, or having a fixed tree
hierarchy for "mid is a child of cuid is a child of cdid is a child of
resource" and using what are effectively positional arguments.  To be
clear, I'm explicitly *not* objecting to this choice; I'd just appreciate a
pointer to the previous discussion about it to help me understand better.

What is the scope of a "DOTS session"?  I see that the sid uri-path is only
present on the session-configuration-affecting requests, but not for
mitigations -- are mitigation requests associated with a session somehow?
How does the DOTS session scope interplay with (D)TLS connections and
sessions?

There are also some places where response bodies seem to be described as if
they are to be a subtree of the YANG module, where it's still a little
clear to me exactly how to determine the structure/encoding to expect.  But
that may well be clarified in the parts I haven't gotten to, yet, so maybe
I should just wait and see.

Thanks!

-Ben

---

From: <[email-masked]>
Date: Wed, 31 Oct 2018 07:56:18 +0000

Hi Benjamin, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Benjamin Kaduk
> Envoyé : mardi 30 octobre 2018 22:31
> À : [email-masked]
> Objet : [Dots] high-level questions about the signal channel
> 
> Hi folks,
> 

[Med] This was agreed in an interim in 10/2017 and implemented in -07. You may check this thread for the more context: https://mailarchive.ietf.org/arch/msg/dots/fbCvp2evaOD-DXuUgh2xK65dM7M  

> pointer to the previous discussion about it to help me understand better.

[Med] We used to have those in the body, but we changed the design as a fix to the issue discussed in this thread: 
https://mailarchive.ietf.org/arch/msg/dots/GzcUtlXZAfVXuBunC-ydVGl843w 

> 
> What is the scope of a "DOTS session"? 

[Med] In short, please refer to https://tools.ietf.org/html/draft-ietf-dots-architecture-07#section-3.1. 

 I see that the sid uri-path is only
> mitigations -- are mitigation requests associated with a session somehow?

[Med] sid is about a **configuration session**, that is exchanges that occur for configuration purposes.

The draft says the following: 

   sid:  Session Identifier is an identifier for the DOTS signal channel
      session configuration data represented

> I should just wait and see.

[Med] JSON diagnostic notation is used.

> 
> Thanks!
> 
> -Ben
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Xialiang (Frank, Network Integration Technology Research Dept)" <[email-masked]>
Date: Thu, 1 Nov 2018 02:00:31 +0000

Hi,
Please see my comment inline:

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2018年10月31日 15:56
收件人: Benjamin Kaduk <[email-masked]>; [email-masked]
主题: Re: [Dots] high-level questions about the signal channel

Hi Benjamin, 

Please see inline. 

Cheers,
Med

> Envoyé : mardi 30 octobre 2018 22:31 À : [email-masked] Objet : [Dots] 
> high-level questions about the signal channel
> 
> Hi folks,
> 
> questions that it seems worth talking about in parallel with the rest 
> of my review.
> 
> could assert that dots is the only service running on that port and 
> get shorter URLs instead of using this prefix.  I mostly assume that 
> this was well-discussed before I started following the WG, so 
> hopefully there is an easy pointer to the list archives that I can read up on.

> 
> In a similar vein, using "cuid-<foo>" and "mid=<bar>" and such in 
> uri-paths feels unusual to me (in that the assignment feels like a 
> parameter that belongs in the request body as opposed to a path, or 
> having a fixed tree hierarchy for "mid is a child of cuid is a child 
> of cdid is a child of resource" and using what are effectively 
> positional arguments.  To be clear, I'm explicitly *not* objecting to 
> this choice; I'd just appreciate a pointer to the previous discussion about it to help me understand better.

   sid:  Session Identifier is an identifier for the DOTS signal channel
      session configuration data represented
[Frank]: To be more clear, my understanding is there is one and only one session between a DOTS client and a DOTS server, so all the mitigation requests over this session share the same session configurations. Is my understanding right?

> There are also some places where response bodies seem to be described 
> as if they are to be a subtree of the YANG module, where it's still a 
> little clear to me exactly how to determine the structure/encoding to 
> expect.  But that may well be clarified in the parts I haven't gotten 
> to, yet, so maybe I should just wait and see.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 1 Nov 2018 03:49:35 +0000

Hi Frank,

Please see inline

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Xialiang (Frank, Network
> Integration Technology Research Dept)
> Sent: Thursday, November 1, 2018 7:31 AM
> To: [email-masked]; Benjamin Kaduk <[email-masked]>
> Cc: [email-masked]
> Subject: [Dots] 答复: high-level questions about the signal channel
> 
> 
> 
> Hi,
> [Med] This was agreed in an interim in 10/2017 and implemented in -07. You
> may check this thread for the more context:
> https://mailarchive.ietf.org/arch/msg/dots/fbCvp2evaOD-DXuUgh2xK65dM7M
> 
> >
> [Frank]: To be more clear, my understanding is there is one and only one
> session between a DOTS client and a DOTS server, so all the mitigation
> requests over this session share the same session configurations. Is my
> understanding right?

It is discussed in the draft to use a single DOTS session b/w DOTS agents.

<snip>
   A single DOTS signal channel between DOTS agents can be used to
   exchange multiple DOTS signal messages.  To reduce DOTS client and
   DOTS server workload, DOTS clients SHOULD re-use the (D)TLS session.
</snip>

Mitigation requests are not tied to a DOTS session. Mitigation requests are associated with a DOTS client and can be updated/deleted using different DOTS sessions.

-Tiru