Re: [art] Artart last call review of draft-ietf-anima-constrained-join-proxy-10

[Peter van der Stok <[e-mail]>]

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