A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)
draft-jimenez-p2psip-coap-reload-10

Thanks for changing the registration policy to Specification Required; I think that's a better choice than Standards Action.  And thanks for addressing my other comments.  The only small issue I still have is with this change:

OLD
   For example in cases multiple Wireless Sensor
   Networks (WSN) that need to be federated over some wider-area
   network.

NEW
   For example in cases where multiple Wireless
   Sensor Networks (WSN) need to be federated over some wider-area
   network.

The changed sentence is still not a complete sentence.  But at least now I know what you're trying to say, so let me suggest merging it with the previous sentence, like this:

NEWER
   This usage is intended for interconnected devices over a wide-area
   geographical coverage, such as in cases where multiple Wireless
   Sensor Networks (WSN) need to be federated over some wider-area
   network.
END

- This is an AD sponsored document with an IPR declaration that
says RAND+possible-fee. The write-up says that the core and
p2psip WGs discussed the document and are ok with it being AD
sponsored. Was the IPR declaration a part of that discussion?
(The shepherd write up only says that nobody had a problem, it's
not clear if the WGs were told about the IPR directly.) The IETF
LC does however properly note the IPR, so this isn't a formal
process-whine, I'm just asking:-) If the WGs were not in fact
told about the IPR (via a mail or at the presentations mentioned)
then it might be a good belt/braces type thing to do to just
check that before proceeding since we know there are a bunch of
people who aren't subscribed to IETF announce.

- intro, "Regisgtration" para: I forget - do all CoAP nodes have
a "CoAP URI" that they need to know? If so, a ref to that bit of
the CoAP spec would be good. If not, I'm not sure how this works.

- PEA on 1st use: "RN" is a what?

- section 9: "which canonicalized form hashes (using the hash
function for the overlay) to the Resource-ID" is not clear enough
IMO and likely to create interop issues. I think you need some
more detail and a combination of references and examples before
this will be implemented well. Similarly "certificate has an
associated URI" isn't precise enough is it? (It could be in a SAN
or some otherName or even outside the cert with that wording.)

- section 10: I think you're missing a security consideration: if
a CoAP node (probably esp. a sleepy node) uses this to publish
information about itself, then it is more likely to get attacked,
e.g. a sleepy node may be more likely to get a barrage of
messages as soon as it awakens as part of a battery depletion or
other DoS attack. I'd note that and say that it's more important
to be DoS resistent and get e.g. s/w updates when you tell the
world about yourself, since not all bits of the world you're
telling are nice. 

(PEA == Please Expand Acronyms:-)