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

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 1 Nov 2018 17:34:46 -0500

On Thu, Nov 01, 2018 at 03:49:35AM +0000, Konda, Tirumaleswar Reddy wrote:
> 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,
> > 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
> > 
> > > -----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,
> > >
> > > 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.
> > 
> > [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
> > 
> > >
> > > 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.
> > 
> > [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
> > > present on the session-configuration-affecting requests, but not for
> > > 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
> > [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.

Thanks for the discussion.  It's sounding like one could model a DOTS
session as basically a DTLS association (but of course DTLS is not the
only permitted transport for the signal channel, so it's not exactly the
same).

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 2 Nov 2018 04:15:43 +0000

> From: Benjamin Kaduk <[email-masked]>
> Sent: Friday, November 2, 2018 4:05 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: Xialiang (Frank, Network Integration Technology Research Dept)
> <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: [Dots] 答复: high-level questions about the signal channel
> 
> 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.
> 
> > > From: Dots <[email-masked]> On Behalf Of Xialiang (Frank,
> > > Network Integration Technology Research Dept)
> > > > 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,
> > > >
> > > > 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.
> > > >
> > > > 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.
> > >
> > > [Med] This was agreed in an interim in 10/2017 and implemented in
> > > -07. You may check this thread for the more context:
> > > > 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
> > > [Med] We used to have those in the body, but we changed the design
> > > as a fix to the issue discussed in this thread:
> > > [Med] In short, please refer to
> > > https://tools.ietf.org/html/draft-ietf-dots-
> > > > present on the session-configuration-affecting requests, but not
> > > > for mitigations -- are mitigation requests associated with a session
> somehow?
> > >
> > > [Med] sid is about a **configuration session**, that is exchanges
> > > that occur for configuration purposes.
> > >
> > > [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?
> >
> > 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.
> 
> Thanks for the discussion.  It's sounding like one could model a DOTS session as
> basically a DTLS association (but of course DTLS is not the only permitted
> transport for the signal channel, so it's not exactly the same).

Agreed.

-Tiru