petervanderstok
commented
2 years ago Hi Rich,
many thanks for the useful suggestions. Below my reactions. Most of your suggestions have been taken over.
Greetings,
Peter Rich Salz via Datatracker schreef op 2022-05-18 19:44:
Reviewer: Rich Salz Review result: Ready with Nits
A block diagram that show the participants and the protocols (like DTLS or RFC4944, etc) would be very helpful to someone new to this field. Like me.
==>pvds A forward pointer to figure 1 has been added to the introduction. ==>
Sec 1. "Once a Pledge is enrolled, it can act as constrained Join Proxy between other Pledges and the enrolling Registrar." Is that a special function of JP-based enrollment, or could anyone in the mesh be a JP?
==>pvds NEW An enrolled Pledge can act as constrained Join Proxy between other Pledges and the enrolling Registrar. ==>
The 1,2 item list has a spurious "that" in the second entry. ==>pvds removed ==>
The "Similar to..." part in the last paragraph is a sentence fragment.
==>pvds NEW Similar to the difference between storing and non_storing Modes of Operations (MOP) in RPL [RFC6550], the stateful and stateless modes differ in the way that they store the state required to forward the return packet to the pledge. ==>
Sec 4. Oh, you have a diagram here. Spread out the distance between R and J so that "multi-hop" fits on one line maybe. Consider adding to it and moving it to Sec
-
Or at least in Sec 1 have a forward pointer. ==>pvds This is the diagram proposed by my co-author
++++ multi-hop mesh |R |---- +---+ +--+ +--+ | | \ |6 |----|J |........|P | ++++ \--+ LR| | | | | +---+ +--+ +--+ Registrar Join Proxy Pledge
==> Repeating "(P)" and "(J)" after the first instance is distracting. ==>pvds removed ==> Type "untill" in last paragraph. ==>pvds don't understand ==> Why is "legal" in quotes?
==>pvds legal is removed ==>
"An enrolled device can..." same question as above: ANY enrolled device could? ==>pvds Yes, any enrolled devices was a pledge beforehand ==>
Sec 5.1
Maybe "such as by" instead of "for example" The parenthetical about "Discovery
can also" and the sentence about DNS-SD probably belong in section 6.
==>pvds
sentence about DNS-SD is removed
==>
==>pvds NEW The Join Proxy has been enrolled via the Registrar and learns the IP address and port of the Registrar, by using a discovery mechanism such as described in Section 6. ==> In Figure 2, I was briefly confused by the label "Src_IP" and the content having "IP_p" etc. ==>pvds NEW
The columns "SRc_IP:port" and "Dst_IP:port" show the IP address and port values for the source and destination of the message. ==> Sec 5.2 The phrase "but may also reduce" maybe "and may also reduce"? ==>pvds followed your suggestion ==> Is are paragraphs 2 and 3 redundant? Why use JPY and not, say, SJP? ==>pvds JPY is inherited from earlier draft; and we authors are all used to it. ==> "The registrar should not assume..." KEY POINT. ==>pvds Don't understand ==>
Sec 5.3 Why does the text say "ifindex" but the Figure 4 CDDL says "index"?
==>pvds ifindex it is. thanks ==>
Since there can be more than five elements, what is the meaning of extra elements? Ignore them? Maybe MUST send only five? "Completely opaque to the receiver" really means the receiving Registrar, right? ==>pvds completely opaque for the values. The CBOR array is visible. ==>
Sec 6 I was confused about "near" and "remote" Maybe "near and far" or "local and remote" ? The rest of Sec 6, describing the different discovery methods seems reasonable. (I am not well-qualified to say more than that) ==>pvds near and far, it is now ==>
Sec 7 This could be moved into 5 as a new subsection. If not, sec 5 should have a forward pointer to the comparison. ==>pvds Forward pointer added ==>
Sec 8 I like the list of possibilities for evil, and why they're not new. The "enroll itself" item should have the last two sentence fragments merged "With ..., the chance ..." Next item "Also this is assumed" maybe "This, too, is assumed"
==>pvds "This, too," is now used. ==>
I think you could bundle all of the items which require having the private key, for example, and point out that you depend on the security of DTLS to prevent these things, rather than say "unlikely" ==>pvds I personally like the unlikely. It is always possible with a given probability to decrypt DTLS encryption ==>
Reviewer: Rich Salz Review result: Ready with Nits
A block diagram that show the participants and the protocols (like DTLS or RFC4944, etc) would be very helpful to someone new to this field. Like me.
Sec 1. "Once a Pledge is enrolled, it can act as constrained Join Proxy between other Pledges and the enrolling Registrar." Is that a special function of JP-based enrollment, or could anyone in the mesh be a JP? The 1,2 item list has a spurious "that" in the second entry. The "Similar to..." part in the last paragraph is a sentence fragment.
Sec 4. Oh, you have a diagram here. Spread out the distance between R and J so that "multi-hop" fits on one line maybe. Consider adding to it and moving it to Sec
Sec 5.1 Maybe "such as by" instead of "for example" The parenthetical about "Discovery can also" and the sentence about DNS-SD probably belong in section 6. In Figure 2, I was briefly confused by the label "Src_IP" and the content having "IP_p" etc.
Sec 5.2 The phrase "but may also reduce" maybe "and may also reduce"? Is are paragraphs 2 and 3 redundant? Why use JPY and not, say, SJP? "The registrar should not assume..." KEY POINT.
Sec 5.3 Why does the text say "ifindex" but the Figure 4 CDDL says "index"? Since there can be more than five elements, what is the meaning of extra elements? Ignore them? Maybe MUST send only five? "Completely opaque to the receiver" really means the receiving Registrar, right?
Sec 6 I was confused about "near" and "remote" Maybe "near and far" or "local and remote" ? The rest of Sec 6, describing the different discovery methods seems reasonable. (I am not well-qualified to say more than that)
Sec 7 This could be moved into 5 as a new subsection. If not, sec 5 should have a forward pointer to the comparison.
Sec 8 I like the list of possibilities for evil, and why they're not new. The "enroll itself" item should have the last two sentence fragments merged "With ..., the chance ..." Next item "Also this is assumed" maybe "This, too, is assumed" I think you could bundle all of the items which require having the private key, for example, and point out that you depend on the security of DTLS to prevent these things, rather than say "unlikely"