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

["Xialiang (Frank, Network Integration Technology Research Dept)" <[e-mail]>]

Hi Tiru and Med,
Please see inline:

-----邮件原件-----
发件人: Dots [mailto:[e-mail]] 代表 Konda, Tirumaleswar Reddy
发送时间: 2018年11月30日 0:03
收件人: [e-mail]; Roman Danyliw <[e-mail]>; [e-mail]
主题: Re: [Dots] 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.
[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.
> > >
> > > 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
[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?

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

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

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

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

-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".
[Frank]: why can we use the term " DOTS data channel session" to make it consistent with "DOTS signal 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."
> 
> > Cheers,
> > -Tiru
> >
> > >
> > > Thank you.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Dots [mailto:[e-mail]] De la part de Roman 
> > > > Danyliw Envoyé : mardi 27 novembre 2018 23:15 À : [e-mail] 
> > > > 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
> > > > 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
> > > >
> > > > _______________________________________________
> > > > Dots mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dots
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dots
_______________________________________________
Dots mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dots