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

[<[e-mail]>]

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. 

> >
> > >
> > > 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.