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