Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks
draft-ietf-roll-p2p-rpl-17

Thanks for addressing my concerns.

Thank you for addressing my concerns!

  As already pointed out in the Gen-ART Review by  Alexey Melnikov,
  please expand the First use of "DIO".

Thank you for dealing with my discusses.

(Apologies, I had to read this document in chunks due
to other time pressures, so this review might also be a
bit chunky;-)

- I agree with Sean's DISCUSS

- section 3, the term Target might create an irritating
conflict with how that same term is used in geopriv but
I'm guessing you won't want to change.

- section 4, I don't quite get how this is triggered,
in the remote-conrol/lamp case, is the remote-control
the Origin or a non-router host? If the latter, then
I'm not sure how the remote-control's next-hop router
could know to trigger this process. The former option
seems quite constraining, since it'd mean that all
hosts that can benefit from this need to be p2p-rpl
aware routers, and that seems less rather than more
likely.

- section 4, I'm also not sure how the remote-control
knows the lamp's IP address to start with. How's that
work?  Specification for that probably doesn't belong
here, but I wondered and it might be good to explain a
bit in this draft.

- section 4, 3rd last para: I don't see how the guy who
makes the remote-control (if its the Source LLN router)
can know how to set all those things that the "network
designer" knows how to set. Maybe I'm just missing the
point?

- section 5: sending application data with routing
messages seems to have security issues since the DIOs
are sent more or less all over I think? That implies
that a one-to-many confidentiality service might be
needed which seems very very hard (i.e. silly) in a p2p
context. And of course that also assumes that the
application runs on the "Source" LLN router as well so
you can know what is and is not time-critical. I also
wonder what'd happen if the "application data" you mean
were a TCP SYN packet which seems likely isn't it? The
same security issues arise with the data option in a
DRO. (FYI in case it helps this would have generated a
DISCUSS from me for a standards track protocol but
since there are already two discusses about this I'll
not pile on.)

- 6.1, Why is "Authentication Enabled: 0" the default
and why does that differ from 6550? (If it does.)

- 7.1, Lifetime field - it wasn't clear to me when a
router starts counting down to the end of the Lifetime
for the DAG. 

- 7.2, Only allowing 256 bytes here may effectively
mean securing that data is never possible. That seems
undesirable.

- 7.2 saying a deployment SHOULD take security into
consideration seems meaningless.

- section 8 says the DODAGID identifies the Origin and
that confused me, do you mean its value is the origin's
IP address?

- section 13 says: "Each RPL control message has a
secure version that allows the specification of the
level of security and the algorithms used to secure the
message. " and " These DIOs can be used in their secure
versions if desired" but I have to say I'm unconvinced
that that's sufficiently well defined here (or in 6550)
to allow interop and offer useful security. There
doesn't seem to be any mention of the "secure DRO" in
section 11 for example. I'd love to be proven wrong
however, so can you try convince me that I'm wrong?
(This would also have been a DISCUSS on a standards
track document, even if the authors could justifiably
say that the real fault lies in 6550.)