Re: [Dots] some nits and comments about draft-dots-signal-channel-23:

[<[e-mail]>]

Hi all,

I agree with almost all replies from Tiru. I have one minor comment about this one:

==
5.       P18: / cdid:  Stands for Client Domain IDentifier./ cdid:  Stands for Client Domain Identifier./
==

The initial wording was correct.

Anyway, I’m not planning to change this back in the draft.

Cheers,
Med

De : Dots [mailto:[e-mail]] De la part de Konda, Tirumaleswar Reddy
Envoyé : mercredi 29 août 2018 17:12
À : Jon Shallow; Xialiang (Frank); [e-mail]; [e-mail]
Objet : Re: [Dots] some nits and comments about draft-dots-signal-channel-23:

From: Jon Shallow <[e-mail]>
Sent: Wednesday, August 29, 2018 1:22 PM
To: Konda, Tirumaleswar Reddy <[e-mail]>; Xialiang (Frank) <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: [Dots] some nits and comments about draft-dots-signal-channel-23:


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi there,

One comment inline Jon>

Regards

Jon

From: Dots [mailto: [e-mail]<mailto:[e-mail]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 29 August 2018 08:42
To: Xialiang (Frank, Network Integration Technology Research Dept); [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Dots] some nits and comments about draft-dots-signal-channel-23:

Hi Frank,

Please see inline [TR3]

From: Xialiang (Frank, Network Integration Technology Research Dept) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, August 29, 2018 7:17 AM
To: Konda, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: 答复: some nits and comments about draft-dots-signal-channel-23:


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi Tiru,
Please see inline:

发件人: Konda, Tirumaleswar Reddy [mailto:[e-mail]]
发送时间: 2018年8月28日 21:24
收件人: Xialiang (Frank, Network Integration Technology Research Dept) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[e-mail]>
主题: RE: some nits and comments about draft-dots-signal-channel-23:

Hi Frank,

Please see inline [TR2]

From: Dots <[e-mail]<mailto:[e-mail]>> On Behalf Of Xialiang (Frank, Network Integration Technology Research Dept)
Sent: Tuesday, August 28, 2018 7:29 AM
To: Konda, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Dots] 答复: some nits and comments about draft-dots-signal-channel-23:


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi Tiru,
Please see further comments inline:

发件人: Dots [mailto:[e-mail]] 代表 Konda, Tirumaleswar Reddy
发送时间: 2018年8月25日 22:32
收件人: Xialiang (Frank, Network Integration Technology Research Dept) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[e-mail]>
主题: Re: [Dots] some nits and comments about draft-dots-signal-channel-23:

Hi Frank,

Please see inline [TR]

From: Dots <[e-mail]<mailto:[e-mail]>> On Behalf Of Xialiang (Frank, Network Integration Technology Research Dept)
Sent: Friday, August 24, 2018 1:59 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Dots] some nits and comments about draft-dots-signal-channel-23:


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________

Hi authors,
After once more careful review of this draft, I have the following nits and comments:

Nits:

1.       Last paragraph of section 1: /This is a companion document…/There is a companion document…/


[TR] The line looks correct, DOTS signal channel is a companion document of the DOTS data channel document.


2.       P13, the definition of cuid: /This is a mandatory Uri-Path./ This is a mandatory Uri-Path parameter./

[TR] Yes, will update.


3.       First paragraph in P16: / with indefinite lifetimes./ with indefinite lifetime./


[TR] The line looks correct, “lifetimes” is plural to refer to “mitigations”.



4.       P12: / Uri-Path: "version"/ Uri-Path: "v1"/


5.       P18: / cdid:  Stands for Client Domain IDentifier./ cdid:  Stands for Client Domain Identifier./

[TR] Yes, will fix 4 and 5.




6.       Last paragraph in P21: /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./ The DOTS server differentiates the DOTS signal channel sessions using the DOTS client identity and optionally the ’cdid’ parameter value. for every DOTS signal channel session, the DOTS server uses ’mid’ Uri-Path parameter values to detect duplicate mitigation requests./

[TR] The above line is added to explain how the DOTS server couples DOTS signal channel sessions from the same DOTS client.
[Frank]: How many signal channel sessions can have between one DOTS client and DOTS server? I assume there only one.

[TR2] The DOTS client can create more than one DOTS signal channel session with the DOTS server, but the draft recommends the client to use a single channel. Please see the following snippet from the Security Considerations Section
<snip>
   A single DOTS signal channel between DOTS agents can be used to
   exchange multiple DOTS signal messages.  To reduce DOTS client and
   DOTS server workload, DOTS clients SHOULD re-use the (D)TLS session.
</snip>
[Frank]: since this is a key point for the whole protocol, I think it’s not enough you only mention it in the Security Consideration Section. Can you add some text to clarify this point in the suitable section more clearly.

[TR3] we can move the above text to section 3 (Design overview), let us know if any other details need to be added.

Jon> During Happy Eyeballs, there can be up to 4 signal channel sessions, which should settle down to one.

[TR4] Happy Eyeballs specification discusses to abandon non-winning connections, don’t see a need to repeat.

-Tiru

~Jon



7.       P22: /This version of the specification forbids ’cuid’ and ’cdid’ (if used) to be returned in a response./This version of the specification forbids ’cuid’ and ’cdid’ (if used) to be returned in a response message body./

[TR] Yes, will update.

Comments:

1.       Last paragraph of P6: only "coaps+tcp" URI scheme is used, no “coaps+udp”?

[TR] No, by default the “coaps” URI scheme defined in RFC7252 is for UDP.
[Frank]: So, do we still need “coaps” URL for the UDP transport?

[TR2] Yes, “coaps” means DTLS-secured CoAP messages exchanged over UDP, please see RFC7252.
[Frank]: why I cannot see the “coaps” URI in the whole document?

[TR3] The doc does not discuss complete URI, hence you don’t see “coaps”.



2.       Please consider including these terminology in section 2: JSON, YANG, CBOR, DER, ASN, SPKI, PSK, SHA, CIDR, TCP, UDP, SCTP, DCCP, IANA, FQDN, URI, ...

[TR] I have not seen any recent RFC adding them to the Terminology. However, we will expand the all the abbreviations (currently only missing for JSON, DER, ASN and PSK).
[Frank]: ok.


3.       Last paragraph of P7: 3..xx Response Codes seems to be not used in this document, delete it?

[TR] Good catch, will delete.



4.       P50: "...time to live values in the CBOR body (Figure 22)", TTL values should not be in the CBOR message body.

[TR] Yes, will remove.



5.       P72: [I-D.ietf-tls-dtls13] should be replaced by [RFC8446]

[TR] No, DTLS 1.3 has not yet become a RFC (see https://tools.ietf.org/html/draft-ietf-tls-dtls13-28)



6.       cuid vs cdid:

1)       Will server-domain DOTS gateways replace the cuid with its own cuid as the new DOTS client?

[TR] No, gateways will not modify or replace cuid.
[Frank]: then, the source ‘cuid’ will reach the final DOTS server, why do we still need the define the ‘cdid’?

[TR2] ‘cdid’ identifies the DOTS client domain whereas ‘cuid’ the DOTS client identity.
[Frank]: so, the main reason for introducing the ‘cdid’ is for differentiating the different DOTS client with the same ‘cuid’ but from the different domain (with different ‘cdid’), not for representing the source DOTS client ?

[TR3] The other reason is ‘cid’ can only be conveyed by the server-domain DOTS gateway and can be trusted by the DOTS server to enforce policies.

If there are multiple DOTS clients in one domain, there should be multiple ‘cuid’ with the only one ‘cdid’?

[TR3] Yes.

Cheers,
-Tiru



2)       Will Server-domain DOTS gateways insert the new cdid to represent the source DOTS client ?

[TR] Yes, but to convey the source DOTS client domain identity.


3)       If the above points are right, I think the third paragraph in P18 is not very clear to clarify them and have space for tuning. And I also think there is a conflict between the 5th and 6th paragraph, since source DOTS clients cannot generate cdid, the DOTS server is impossible to ignore ‘cdid’ attributes that are directly supplied by source DOTS clients.

[TR] I did not get the above comment.



4)       P21: Is “the DOTS client identity” here the same as the ‘cuid’? or another id?

[TR] “DOTS client identity” is explained in page 26
<snip>
As a reminder, a DOTS client
   is identified by its identity (e.g., client certificate, 'cuid') and
   optionally the 'cdid'.
</snip>
[Frank]: so, you mean a “DOTS client identity” can be the client certificate, ‘cuid’ or ‘cdid’ depending on context? If you use this term in other place, how can I know which one it is?

[TR2] No, “DOTS client identity” is ‘cuid’ + ‘cdid’ (‘cdid’ may or may not be present in the mitigation request). The algorithm for generating ‘cuid’ and ‘cdid’ is discussed in the draft and
‘cuid’  can be generated from the DOTS client certificate.

Cheers,
-Tiru

Thanks!

B.R.
Frank