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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Med,

Please see inline

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Friday, November 30, 2018 12:25 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> Roman Danyliw <[e-mail]>; [e-mail]
> 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.
> 
> Hi Tiru,
> 
> My replies inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[e-mail]]
> > Envoyé : jeudi 29 novembre 2018 17:03
> > À : BOUCADAIR Mohamed TGI/OLN; Roman Danyliw; [e-mail] Objet :
> > RE: WGLC on draft-ietf-dots-architecture-08
> >
> > > -----Original Message-----
> > > From: [e-mail]
> <[e-mail]>
> > > Sent: Thursday, November 29, 2018 7:35 PM
> > > To: Konda, Tirumaleswar Reddy
> <[e-mail]>;
> > > Roman Danyliw <[e-mail]>; [e-mail]
> > > 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
> > >
> > > > -----Message d'origine-----
> > > > De : Konda, Tirumaleswar Reddy
> > > > [mailto:[e-mail]]
> > > > Envoyé : jeudi 29 novembre 2018 14:25 À : BOUCADAIR Mohamed
> > > > TGI/OLN; Roman Danyliw; [e-mail] Objet :
> > > > RE: WGLC on draft-ietf-dots-architecture-08
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Dots <[e-mail]> On Behalf Of
> > > > > [e-mail]
> > > > > Sent: Thursday, November 29, 2018 2:01 PM
> > > > > To: Roman Danyliw <[e-mail]>; [e-mail]
> > > > > Subject: Re: [Dots] WGLC on draft-ietf-dots-architecture-08
> > > > >
> > > > >
> > > > >
> > > > > 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.
> > > >
> > > > 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.
> >
> > Sure, let's use the term "DOTS signal channel session" in the signal
> > channel I-D.
> >
> 
> [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".
> 
> > >
> > >  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.
> >
> > Sure, Works for me.
> >
> 
> [Med] Please make sure to have this included in the architecture I-D.

Sure, we will update draft. 

> 
> > >
> > > >
> > > > The DOTS signal data channel session is a mutually authenticated
> > > > DOTS session between DOTS agents.
> > > >
> > >
> > > [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).
> >
> 
> [Med] Works for me.
> 
> > > 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."
> >
> > Removing the above line should avoid the confusion.
> >
> ...
> > >
> > >
> > > > 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."
> 
> [Med] This one is still pending.

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

-Tiru