Subject: [Dots] WGLC on draft-ietf-dots-architecture-08

From: Roman Danyliw <[email-masked]>
Date: Tue, 27 Nov 2018 22:15:08 +0000

Hello!

Consistent with our discussion at the Bangkok meeting, we are starting a working group last call (WGLC) for the DOTS architecture draft:

DOTS Architecture
draft-ietf-dots-architecture-08
https://tools.ietf.org/html/draft-ietf-dots-architecture-08

Please send comments to the DOTS mailing list -- feedback on remaining issues or needed changes; as well as endorsements that this draft is ready.

This WGLC will end on December 12, 2018.

Thanks,
Roman and Frank

---

From: <[email-masked]>
Date: Thu, 29 Nov 2018 08:31:08 +0000

Hi Roman, all,

I support this draft to be sent to the IESG for publication. 

Some easy-to-fix comment, though: 

(1) The document cites [I-D.ietf-dots-requirements] in may occurrences. I suggest these citations to be more specific, that is to point the specific REQ# or the section. Doing so would help readers not familiar with DOTS documents to easily link the various pieces. 

(2) I used to point people to the DOTS architecture I-D when I receive comments/questions about the notion of "DOTS session" and to the Requirements I-D for clarification about DOTS channels. It seems that some clarifications are needed in the architecture I-D to explain for readers not familiar with all DOTS documents, for example: 
- the link with the underlying transport sessions/connections and security associations. 
- mitigations are not bound to a DOTS session but to a DOTS client/domain. 

(3) The signal channel I-D uses "DOTS signal channel session", "DOTS signal channel sessions" and "DOTS data channel session" to refer to specific DOTS sessions. I'd like to have these terms introduced also in the arch I-D. 

BTW, the signal channel uses in few occurrences "DOTS session"; those can be changed to "DOTS signal channel session". There is no occurrence of "DOTS session" in the data channel I-D.

Thank you.  

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Roman Danyliw
> Envoyé : mardi 27 novembre 2018 23:15
> À : [email-masked]
> Objet : [Dots] WGLC on draft-ietf-dots-architecture-08
> 
> Hello!
> 
> Consistent with our discussion at the Bangkok meeting, we are starting a
> working group last call (WGLC) for the DOTS architecture draft:
> 
> DOTS Architecture
> Please send comments to the DOTS mailing list -- feedback on remaining issues
> or needed changes; as well as endorsements that this draft is ready.
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 29 Nov 2018 13:25:19 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Thursday, November 29, 2018 2:01 PM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Subject: Re: [Dots] WGLC on draft-ietf-dots-architecture-08
> 
> 
> 
> Hi Roman, all,
> 
> (1) The document cites [I-D.ietf-dots-requirements] in may occurrences. I
> suggest these citations to be more specific, that is to point the specific REQ# or
> the section. Doing so would help readers not familiar with DOTS documents to
> easily link the various pieces.
> 
> (2) I used to point people to the DOTS architecture I-D when I receive
> comments/questions about the notion of "DOTS session" and to the
> Requirements I-D for clarification about DOTS channels. It seems that some
> clarifications are needed in the architecture I-D to explain for readers not
> familiar with all DOTS documents, for example:
> (3) The signal channel I-D uses "DOTS signal channel session", "DOTS signal
> channel sessions" and "DOTS data channel session" to refer to specific DOTS
> sessions. I'd like to have these terms introduced also in the arch I-D.
> 
> BTW, the signal channel uses in few occurrences "DOTS session"; those can be
> changed to "DOTS signal channel session". There is no occurrence of "DOTS
> session" in the data channel I-D.

I don't see a need to modify the "DOTS session" discussed in the signal channel draft, https://tools.ietf.org/html/draft-ietf-dots-architecture-07#section-3.1 defines the term "DOTS session". However, I agree with your comments to update the section 3.1 to add the following lines:
Mitigation requests created using a DOTS session are not bound to the DOTS session. Mitigation requests are associated with a DOTS client and can be managed using different DOTS sessions. A DOTS session is associated with a single transport connection (e.g. TCP or UDP session) and an ephemeral security association (e.g. a TLS or DTLS session). 

The DOTS signal data channel session is a mutually authenticated DOTS session between DOTS agents.

DOTS data channel draft is not using the term "DOTS data channel session", we can fix the signal channel draft to use "DOTS data channel" instead of "DOTS data channel session".

Cheers,
-Tiru

> > Envoyé : mardi 27 novembre 2018 23:15 À : [email-masked] Objet : [Dots]
> > WGLC on draft-ietf-dots-architecture-08
> >
> > Hello!
> >
> > Consistent with our discussion at the Bangkok meeting, we are starting
> > a working group last call (WGLC) for the DOTS architecture draft:
> >
> > DOTS Architecture
> > Please send comments to the DOTS mailing list -- feedback on remaining
> > issues or needed changes; as well as endorsements that this draft is ready.
> >

---

From: <[email-masked]>
Date: Thu, 29 Nov 2018 14:04:35 +0000

Tiru, 

Please see inline. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : jeudi 29 novembre 2018 14:25
> À : BOUCADAIR Mohamed TGI/OLN; Roman Danyliw; [email-masked]
> Objet : RE: WGLC on draft-ietf-dots-architecture-08
> 
> 
> 
> I don't see a need to modify the "DOTS session" discussed in the signal
> channel draft, https://tools.ietf.org/html/draft-ietf-dots-architecture-
> 07#section-3.1 defines the term "DOTS session".

[Med] I used to had the same opinion till recently. The comments I'm getting from people is that the articulation between the various terms is not that clear. We collectively need to double check this and make required changes, including simplifying the terminology. We are using the following terms in the various I-Ds:

* DOTS session
* DOTS signal channel
* DOTS data channel
* DOTS signal channel session
* DOTS data channel session
* established signal channel
* established data channel

For example, having both "DOTS signal channel session" and "DOTS session" terms in the signal channel I-D to refer to the same thing can be avoided. 

 However, I agree with your
> comments to update the section 3.1 to add the following lines:
> Mitigation requests created using a DOTS session are not bound to the DOTS
> session. Mitigation requests are associated with a DOTS client and can be
> managed using different DOTS sessions. A DOTS session is associated with a
> single transport connection (e.g. TCP or UDP session) and an ephemeral
> security association (e.g. a TLS or DTLS session).

[Med] This is a good starting point. Some part of the text is more accurate with s/DOTS session/DOTS signal channel session.

> The DOTS signal data channel session is a mutually authenticated DOTS session

[Med] I guess you meant s/signal data channel/signal channel. Putting that aside, and more importantly, a reader will then have troubles to parse the following: 

"Conversely, a
   DOTS session cannot exist without an established signal channel: when
   an established signal channel is terminated for any reason, the DOTS
   session is also said to be terminated."

> DOTS data channel draft is not using the term "DOTS data channel session", we
> can fix the signal channel draft to use "DOTS data channel" instead of "DOTS
> data channel session".
> 

[Med] May be. BTW, this part of the text:

" Conversely, a
   DOTS session cannot exist without an established signal channel
"

is conflicting with this one: 

"
To allow for DOTS
   service flexibility, neither the order of contact nor the time
   interval between channel creations is specified.  A DOTS client MAY
   establish signal channel first, and then data channel, or vice versa."

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 29 Nov 2018 16:02:50 +0000

> From: [email-masked] <[email-masked]>
> Sent: Thursday, November 29, 2018 7:35 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Roman Danyliw <[email-masked]>; [email-masked]
> Subject: RE: WGLC on draft-ietf-dots-architecture-08
> 
> 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.
> 
> Tiru,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > À : BOUCADAIR Mohamed TGI/OLN; Roman Danyliw; [email-masked] Objet :
> > RE: WGLC on draft-ietf-dots-architecture-08
> >
> >
> >
> > > (1) The document cites [I-D.ietf-dots-requirements] in may
> > > occurrences. I suggest these citations to be more specific, that is
> > > to point the specific
> > REQ# or
> > > the section. Doing so would help readers not familiar with DOTS
> > > documents
> > to
> > > (2) I used to point people to the DOTS architecture I-D when I
> > > receive comments/questions about the notion of "DOTS session" and to
> > > the Requirements I-D for clarification about DOTS channels. It seems
> > > that some clarifications are needed in the architecture I-D to
> > > explain for readers
> > not
> > > (3) The signal channel I-D uses "DOTS signal channel session", "DOTS
> > > signal channel sessions" and "DOTS data channel session" to refer to
> > > specific DOTS sessions. I'd like to have these terms introduced also in the
> arch I-D.
> > >
> > > BTW, the signal channel uses in few occurrences "DOTS session";
> > > those can
> > be
> > > changed to "DOTS signal channel session". There is no occurrence of
> > > "DOTS session" in the data channel I-D.
> >
> > I don't see a need to modify the "DOTS session" discussed in the
> > signal channel draft,
> > https://tools.ietf.org/html/draft-ietf-dots-architecture-
> [Med] I used to had the same opinion till recently. The comments I'm getting
> from people is that the articulation between the various terms is not that clear.
> We collectively need to double check this and make required changes,
> including simplifying the terminology. We are using the following terms in the
> various I-Ds:
> 
> * DOTS session
> * DOTS signal channel
> * DOTS data channel
> For example, having both "DOTS signal channel session" and "DOTS session"
> terms in the signal channel I-D to refer to the same thing can be avoided.

Sure, let's use the term "DOTS signal channel session" in the signal channel I-D. 

> > Mitigation requests created using a DOTS session are not bound to the
> > DOTS session. Mitigation requests are associated with a DOTS client
> > and can be managed using different DOTS sessions. A DOTS session is
> > associated with a single transport connection (e.g. TCP or UDP
> > session) and an ephemeral security association (e.g. a TLS or DTLS session).
> 
> [Med] This is a good starting point. Some part of the text is more accurate with
> s/DOTS session/DOTS signal channel session.

Sure, Works for me.

> [Med] I guess you meant s/signal data channel/signal channel. 

I don't see the need for the above line, if we add the following line:
 A DOTS signal channel session is associated with a single transport connection (e.g. TCP or UDP session) and an ephemeral security association (e.g. a TLS or DTLS session).

> Putting that
> aside, and more importantly, a reader will then have troubles to parse the
> following:
> 
> "Conversely, a

Removing the above line should avoid the confusion.

-Tiru

> 
> 
> > DOTS data channel draft is not using the term "DOTS data channel
> > session", we can fix the signal channel draft to use "DOTS data
> > channel" instead of "DOTS data channel session".
> >
> 
>    DOTS session cannot exist without an established signal channel "
> 
> > > > De : Dots [mailto:[email-masked]] De la part de Roman
> > > > Danyliw Envoyé : mardi 27 novembre 2018 23:15 À : [email-masked]
> > > > Consistent with our discussion at the Bangkok meeting, we are
> > > > starting a working group last call (WGLC) for the DOTS architecture draft:
> > > >
> > > > DOTS Architecture
> > > > Please send comments to the DOTS mailing list -- feedback on
> > > > remaining issues or needed changes; as well as endorsements that
> > > > this draft is
> > ready.
> > > >

---

From: "Xialiang (Frank, Network Integration Technology Research Dept)" <[email-masked]>
Date: Fri, 30 Nov 2018 00:43:44 +0000

Hi Tiru and Med,
Please see inline:

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Konda, Tirumaleswar Reddy
发送时间: 2018年11月30日 0:03
收件人: [email-masked]; Roman Danyliw <[email-masked]>; [email-masked]
主题: Re: [Dots] WGLC on draft-ietf-dots-architecture-08

> 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.
> 
> Tiru,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > Envoyé : jeudi 29 novembre 2018 14:25 À : BOUCADAIR Mohamed TGI/OLN; 
> > Roman Danyliw; [email-masked] Objet :
> > > occurrences. I suggest these citations to be more specific, that 
> > > is to point the specific
> > REQ# or
> > > receive comments/questions about the notion of "DOTS session" and 
> > > to the Requirements I-D for clarification about DOTS channels. It 
> > > seems that some clarifications are needed in the architecture I-D 
> > > to explain for readers
> > not
[Frank]: is there some specific examples to clarify this point I feel we don't explain the use cases and the benefits well enough in current drafts, or maybe I missed something.

> > >
> > > (3) The signal channel I-D uses "DOTS signal channel session", 
> > > "DOTS signal channel sessions" and "DOTS data channel session" to 
> > > refer to specific DOTS sessions. I'd like to have these terms 
> > > introduced also in the
> arch I-D.
> > >
> > > changed to "DOTS signal channel session". There is no occurrence 
> > > of "DOTS session" in the data channel I-D.
> >
> [Med] I used to had the same opinion till recently. The comments I'm 
> getting from people is that the articulation between the various terms is not that clear.
> including simplifying the terminology. We are using the following 
> terms in the various I-Ds:
> 
> * DOTS session
> * DOTS signal channel
> * DOTS data channel
[Frank]: do we still use the terminology of "DOTS signal channel" and "DOTS data channel" somewhere? They are the draft title. And if they still exist, what is the relation between the channels and the sessions?

> > Mitigation requests created using a DOTS session are not bound to 
> > the DOTS session. Mitigation requests are associated with a DOTS 
> > client and can be managed using different DOTS sessions. A DOTS 
> > session is associated with a single transport connection (e.g. TCP 
> > or UDP
> [Med] This is a good starting point. Some part of the text is more 
> accurate with s/DOTS session/DOTS signal channel session.

Sure, Works for me.

-Tiru

> > channel" instead of "DOTS data channel session".
[Frank]: why can we use the term " DOTS data channel session" to make it consistent with "DOTS signal channel session"?

---

From: <[email-masked]>
Date: Fri, 30 Nov 2018 06:55:00 +0000

Hi Tiru, 

My replies inline. 

Cheers,
Med

> Envoyé : jeudi 29 novembre 2018 17:03
> getting

[Med] Glad to see that we agree on this. The signal channel is now updated accordingly. Check the updates at: https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/draft-ietf-dots-signal-channel-26.txt   

None of the protocol I-Ds is using now "DOTS session". 

> > s/DOTS session/DOTS signal channel session.

[Med] Please make sure to have this included in the architecture I-D. 

>  A DOTS signal channel session is associated with a single transport
> connection (e.g. TCP or UDP session) and an ephemeral security association
> (e.g. a TLS or DTLS session).
> 

[Med] Works for me. 

> Removing the above line should avoid the confusion.
...
> >    establish signal channel first, and then data channel, or vice versa."

[Med] This one is still pending.

---

From: <[email-masked]>
Date: Fri, 30 Nov 2018 07:07:29 +0000

Hi Frank, 

Please see inline. 

Cheers,
Med

> De : Xialiang (Frank, Network Integration Technology Research Dept)
> [mailto:[email-masked]]
> Envoyé : vendredi 30 novembre 2018 01:44
> À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed TGI/OLN; Roman Danyliw;
> [email-masked]
> Objet : 答复: WGLC on draft-ietf-dots-architecture-08
> 
> Hi Tiru and Med,
> Please see inline:
> 
> -----邮件原件-----
> [Frank]: is there some specific examples to clarify this point I feel we
> don't explain the use cases and the benefits well enough in current drafts,
> or maybe I missed something.
> 

[Med] Adding the clarification I proposed into the architecture I-D would fix this, IMHO.

FWIW, we do have text for this in the protocol I-Ds, e.g., 

==
   In both DOTS signal and data channel sessions, the DOTS client MUST
   authenticate itself to the DOTS server (Section 8).  The DOTS server
   MAY use the algorithm presented in Section 7 of [RFC7589] to derive
   the DOTS client identity or username from the client certificate.
   The DOTS client identity allows the DOTS server to accept mitigation
   requests with scopes that the DOTS client is authorized to manage.

   The DOTS server couples the DOTS signal and data channel sessions
   using the DOTS client identity and optionally the 'cdid' parameter
   value, so the DOTS server can validate whether the aliases conveyed
   in the mitigation request were indeed created by the same DOTS client
   using the DOTS data channel session.  If the aliases were not created
   by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in
   the response.

   The DOTS server couples the DOTS signal channel sessions using the
   DOTS client identity and optionally the 'cdid' parameter value, and
   the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to
   detect duplicate mitigation requests.  If the mitigation request
   contains the 'alias-name' and other parameters identifying the target
   resources (such as 'target-prefix', 'target-port-range', 'target-
   fqdn', or 'target-uri'), the DOTS server appends the parameter values
   in 'alias-name' with the corresponding parameter values in 'target-
   prefix', 'target-port-range', 'target-fqdn', or 'target-uri'.
==

> [Frank]: do we still use the terminology of "DOTS signal channel" and "DOTS
> data channel" somewhere? They are the draft title. And if they still exist,
> what is the relation between the channels and the sessions?
> 

[Med] The notion of "channel" is already defined in the Requirements I-D. I do think that one is clear. 

The architecture I-D defines the notion of "DOTS session", but some changes are still needed. The changes discussed in this thread will help clarifying what is the relationship between a channel and the session or set of sessions bound to it. 

[snip]
> [Frank]: why can we use the term " DOTS data channel session" to make it
> consistent with "DOTS signal channel session"?
> 

[Med] Perhaps I missed your point, but the signal channel is already using "DOTS data channel session".

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 30 Nov 2018 10:54:01 +0000

Hi Med,

Please see inline

> Sent: Friday, November 30, 2018 12:25 PM
> > > links
> > or
> > > open attachments unless you recognize the sender and know the
> > > content is
> > safe.
> > >
> > > Tiru,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > Envoyé : jeudi 29 novembre 2018 14:25 À : BOUCADAIR Mohamed
> > > > TGI/OLN; Roman Danyliw; [email-masked] Objet :
> > > > > receive comments/questions about the notion of "DOTS session"
> > > > > and to the Requirements I-D for clarification about DOTS
> > > > > channels. It seems that some clarifications are needed in the
> > > > > architecture I-D to explain for readers
> > > > not
> > > > > "DOTS signal channel sessions" and "DOTS data channel session"
> > > > > to refer to specific DOTS sessions. I'd like to have these terms
> > > > > introduced also in
> > the
> > > arch I-D.
> > > > >
> > > from people is that the articulation between the various terms is
> > > not that
> > clear.
> > > terms in
> > the
> [Med] Glad to see that we agree on this. The signal channel is now updated
> accordingly. Check the updates at: https://github.com/boucadair/draft-ietf-
> dots-signal-channel/blob/master/draft-ietf-dots-signal-channel-26.txt
> 
> > > accurate
> > with

Sure, we will update draft. 

> > connection (e.g. TCP or UDP session) and an ephemeral security
> > association (e.g. a TLS or DTLS session).
> >
> 
> [Med] Works for me.
> 
> > > Putting that

The above line looks clear to me, what is the confusion ?

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 30 Nov 2018 10:57:54 +0000

> Sent: Friday, November 30, 2018 12:37 PM
> To: Xialiang (Frank, Network Integration Technology Research Dept)
> <[email-masked]>; Konda, Tirumaleswar Reddy
> <[email-masked]>; Roman Danyliw <[email-masked]>;
> [email-masked]
> > Envoyé : vendredi 30 novembre 2018 01:44 À : Konda, Tirumaleswar
> > Reddy; BOUCADAIR Mohamed TGI/OLN; Roman Danyliw; [email-masked]
> Objet :
> > 答复: WGLC on draft-ietf-dots-architecture-08
> >
> > Hi Tiru and Med,
> > Please see inline:
> >
> > -----邮件原件-----
> > > links or open attachments unless you recognize the sender and know
> > > the
> > content is safe.
> > >
> > > Tiru,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > [Frank]: is there some specific examples to clarify this point I feel
> > we don't explain the use cases and the benefits well enough in current
> > drafts, or maybe I missed something.
> >
> 

Most of the details in the above paragraphs are protocol specific and discussed in the signal channel draft, no need to re-iterate in the architecture draft.

-Tiru

> > > getting from people is that the articulation between the various
> > > terms is
> > not that clear.
> > [Frank]: do we still use the terminology of "DOTS signal channel" and
> > "DOTS data channel" somewhere? They are the draft title. And if they
> > still exist, what is the relation between the channels and the sessions?
> >
> 
> The architecture I-D defines the notion of "DOTS session", but some changes
> are still needed. The changes discussed in this thread will help clarifying what is
> the relationship between a channel and the session or set of sessions bound to
> it.
> 
> [snip]
> >
> > >
> > > >
> > [Frank]: why can we use the term " DOTS data channel session" to make
> > it consistent with "DOTS signal channel session"?
> >
>

---

From: <[email-masked]>
Date: Fri, 30 Nov 2018 12:10:15 +0000

Re-,

OK. Thanks. 

FWIW, I also made on my side some changes that I'd like to see made to fix the issues we discussed so far:

Xml: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-dots-architecture-09.xml 
Diff: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/wdiff%20draft-ietf-dots-architecture-09.txt%20draft-ietf-dots-architecture-09.pdf 

Feel free to reuse the modified version. 

(Removing parts that were agreed and focusing on the last pending one)

> The above line looks clear to me, what is the confusion ?

[Med] The problem is not with the last line with this one:

"DOTS session cannot exist without an established signal channel"

Which means that dots signal channel session is a pre-requisite for DOTS data channel. This is conflict with the other excerpt I cited.

---

From: <[email-masked]>
Date: Fri, 30 Nov 2018 12:16:46 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : vendredi 30 novembre 2018 11:58
> À : BOUCADAIR Mohamed TGI/OLN; Xialiang (Frank, Network Integration
> Technology Research Dept); Roman Danyliw; [email-masked]
> > [Med] Adding the clarification I proposed into the architecture I-D would
> fix this,
> > IMHO.
> >
> Most of the details in the above paragraphs are protocol specific and
> discussed in the signal channel draft, no need to re-iterate in the
> architecture draft.
> 

[Med] It seems that you misunderstood the comments: I'm not suggesting to have this included in the arch draft.
Franck said "we don't explain the use cases and the benefits well enough in current drafts, or maybe I missed something". The expert above is to show that the expected behavior is already covered in the protocols I-Ds, but some changes are still required to the arch I-D.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 30 Nov 2018 16:13:52 +0000

Hi Med,

I don't fully agree with some of the updates.  I propose the following changes:

[1] Replace " A DOTS session can be a DOTS data channel session or a DOTS signal channel session" with "A DOTS session can be a DOTS data channel session or a DOTS signal channel session or both."
[2] I thought we agreed to say the following:
A DOTS signal channel session is associated with a single transport connection (TCP or UDP session) and an ephemeral security association (e.g. a TLS or DTLS session). Similarly,  a DOTS data channel session is associated with a single TCP connection and an ephemeral TLS security association.
[3] Direct and recursive signaling is applicable to both DOTS signal and data channel sessions, replace "DOTS signal channel session" with "DOTS session".
[4] In Section 3.1.2, replace "session" with "DOTS session"
[5] Remove the following line:
"These sessions may belong to the same or distinct DOTS channels (signal or data). 

Cheers,
-Tiru

> Sent: Friday, November 30, 2018 5:40 PM
> Diff: https://github.com/boucadair/IETF-Drafts-
> Reviews/blob/master/wdiff%20draft-ietf-dots-architecture-09.txt%20draft-ietf-
> dots-architecture-09.pdf
> 
> > > > > > DOTS data channel draft is not using the term "DOTS data
> > > > > > channel session", we can fix the signal channel draft to use
> > > > > > "DOTS data channel" instead of "DOTS data channel session".
> > > > > >
> > > > >
> > > > >    establish signal channel first, and then data channel, or
> > > > > vice
> > versa."
> > >
> Which means that dots signal channel session is a pre-requisite for DOTS data
> channel. This is conflict with the other excerpt I cited.