A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)
RFC 7650

Note: This ballot was opened for revision 08 and is now closed.

(Ben Campbell) Yes

(Spencer Dawkins) Yes

Comment (2015-05-12 for -08)
No email
send info
I don't think this is a problem, but would you expect a COAP RELOAD usage to use self-signed certificates pretty much all the time? Otherwise, wouldn't you have to configure certificates on each node?

The base RELOAD specification allows that, but if that's what's expected, it might be helpful to explain what's expected and why.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Stephen Farrell) No Objection

Comment (2015-05-14 for -08)
No email
send info
- 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:-)

(Joel Jaeggli) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2015-06-09 for -09)
No email
send info
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:

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

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

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:

   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

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection