Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med
> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : mercredi 24 avril 2019 14:56
> À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; [e-mail]
> Cc : [e-mail]; [e-mail]
> Objet : RE: [Dots] Adoption call for draft-reddy-dots-home-network-04
> 
> > -----Original Message-----
> > From: [e-mail]
> > <[e-mail]>
> > Sent: Wednesday, April 24, 2019 4:48 PM
> > To: Konda, Tirumaleswar Reddy
> > <[e-mail]>; Valery Smyslov
> > <[e-mail]>; [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [Dots] Adoption call for draft-reddy-dots-home-network-04
> >
> > 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.
> >
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Konda, Tirumaleswar Reddy
> > > [mailto:[e-mail]]
> > > Envoyé : mercredi 24 avril 2019 13:01
> > > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; [e-mail] Cc :
> > > [e-mail]; [e-mail] Objet : RE: [Dots] Adoption call
> > > for draft-reddy-dots-home-network-04
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > <[e-mail]>
> > > > Sent: Wednesday, April 24, 2019 12:18 PM
> > > > To: Konda, Tirumaleswar Reddy
> > > > <[e-mail]>; Valery Smyslov
> > > > <[e-mail]>; [e-mail]
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: RE: [Dots] Adoption call for
> > > > draft-reddy-dots-home-network-04
> > > >
> > > >
> > > >
> > > > Re-,
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Konda, Tirumaleswar Reddy
> > > > > [mailto:[e-mail]]
> > > > > Envoyé : mercredi 24 avril 2019 08:13 À : BOUCADAIR Mohamed
> > > > > TGI/OLN; Valery Smyslov; [e-mail] Cc :
> > > > > [e-mail]; [e-mail] Objet : RE: [Dots] Adoption
> > > > > call for draft-reddy-dots-home-network-04
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Dots <[e-mail]> On Behalf Of
> > > > > > [e-mail]
> > > > > > Sent: Wednesday, April 24, 2019 11:26 AM
> > > > > > To: Valery Smyslov <[e-mail]>; [e-mail]
> > > > > > Cc: [e-mail]; [e-mail]
> > > > > > Subject: Re: [Dots] Adoption call for
> > > > > > draft-reddy-dots-home-network-04
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > Re-,
> > > > > >
> > > > > > Please see inline.
> > > > > >
> > > > > > Cheers,
> > > > > > Med
> > > > > >
> > > > > > > -----Message d'origine-----
> > > > > > > De : Dots [mailto:[e-mail]] De la part de Valery
> > > > > > > Smyslov Envoyé : mercredi 24 avril 2019 07:02 À : [e-mail]
> Cc :
> > > > > > > [e-mail]; [e-mail] Objet : Re: [Dots]
> > > > > > > Adoption call for draft-reddy-dots-home-network-04
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > we received a lot of replies supporting adoption of the document.
> > > > > > > So, the document is adopted. Authors, please re-submit it as
> > > > > > > WG
> > > draft.
> > > > > > >
> > > > > > > A couple of comments.
> > > > > > > 1. The draft uses few times a keyword "MAY NOT". This
> > > > > > > combination is
> > > > not
> > > > > > >      among the list of RFC requirement keywords (it is not
> > > > > > > listed
> > > neither
> > > > > > >      in RFC2119, nor in RFC8174). If the intent was to use RFC
> > > > > requirement
> > > > > > >      language, then I'd suggest replacing it with one of MUST
> > > > > > > NOT, SHALL NOT,
> > > > > > >      SHOULD NOT. Otherwise please make it lowcase.
> > > > > > >
> > > > > >
> > > > > > [Med] Good catch. Fixed.
> > > > > >
> > > > > > > 2. When describing transport, the draft allows both TLS and DTLS.
> > > What
> > > > > > >      makes me confusing is that the draft describes it several
> > > > > > > times as "TCP/TLS or DTLS".
> > > > > > >      Why TCP is ever mentioned here? We all know that TLS
> > > > > > > usually runs
> > > > > over
> > > > > > >      TCP (however we now have QUICK) and DTLS runs over UDP.
> > > > > > >      The way it is presented in the draft makes me think that
> > > probably
> > > > > > >      plain TCP is also allowed as a transport, but is seems to
> > > contradict
> > > > > > >      everything I read about DOTS. Am I missing something here?
> > > > > > >
> > > > > >
> > > > > > [Med] Plain TCP is not allowed. The intent was to be explicit
> > > > > > that there is
> > > > > a
> > > > > > reversal in both TCP and TLS layers, but as you rightfully
> > > > > > raised this may
> > > > > be
> > > > > > confusing since, for the DOTS case, it is trivial that the
> > > > > > reversal of TLS
> > > > > roles
> > > > > > implies the reversal of TCP ones.
> > > > >
> > > > > RESTCONF call home only reverses the TCP role but not the TLS
> > > > > role. In DOTS case, the server has to initiate DTLS handshake for
> > > > > UDP. To keep the roles same for TCP,  TLS handshake is also initiated
> by
> > the server.
> > > >
> > > > [Med] You missed "for the DOTS case" in my previous reply :-)
> > > >
> > > > We do have the following in the draft:
> > > >
> > > >                    DOTS                                DOTS
> > > >                   Server                              Client
> > > >                     |                                    |
> > > >                     |         1. (D)TLS connection       |
> > > >                     |----------------------------------->|
> > > >                     |         2. Mitigation request      |
> > > >                     |<-----------------------------------|
> > > >                     |                                    |
> > > >
> > > > That can be trivially expanded as follows for the TLS case:
> > > >
> > > >                    DOTS                                DOTS
> > > >                   Server                              Client
> > > >                     |                                    |
> > > >                     |         1.1. TCP                   |
> > > >                     |----------------------------------->|
> > > >                     |         1.2. TLS                   |
> > > >                     |----------------------------------->|
> > > >                     |         2. Mitigation request      |
> > > >                     |<-----------------------------------|
> > > >                     |                                    |
> > >
> > > Okay.
> > >
> > > >
> > > >
> > > > As mentioned earlier, the use of TCP/TLS is OK but it may be
> > > > confusing as initially raised by Valery.
> > >
> > > The updated text is not accurate if TCP is not covered, role reversal
> > > at TLS does not mean role reversal at TCP.
> >
> > [Med] The updated text is still fine (ref to Figure 1). We don't have any
> > ambiguity in the procedure part with regards to TCP. We explicitly say the
> > following:
> >
> >        If TCP is used, the DOTS server begins by initiating a TCP
> >        connection to the DOTS client.  The DOTS client MUST support
> >        accepting TCP connections on the IANA-assigned port number
> >        defined in Section 4.1, but MAY be configured to listen to a
> >        different port number.  Using this TCP connection, the DOTS
> >        server initiates a TLS connection to the DOTS client.
> >
> > > Similar to (D)TLS, I prefer explicit text to say role reversal at TCP.
> >
> > [Med] We already have such text (see the above excerpt).
> 
> [TR] Yes, but the updated sentences are incomplete/incorrect at various
> places. I have listed one of the inconsistencies below
> 
>    The one and only role reversal that
>    occurs are at the TLS or DTLS layers; that is, the DOTS server acts
>    as a DTLS client and the DOTS client acts as a DTLS server or the
>    DOTS server acts as a TLS client and the DOTS client acts as a TLS
>    server.  The DOTS server initiates TLS handshake or DTLS handshake to
>    the DOTS client.
> 
> The above update means no role reversal at the TCP layer !

[Med] This text assumes that the TCP is implicitly covered by "TLS layer" (refer again to Figure 1). There is no ambiguity that the reversal at the TLS layer for the DOTS case implies a reversal of the TCP roles, because otherwise the connection cannot be established at the first place (due to the presence of NATs/FWs) !

We can removed "one and only" if this really hurts, though.