A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)
Note: This ballot was opened for revision 08 and is now closed.
Ben Campbell Yes
Spencer Dawkins Yes
Comment (2015-05-12 for -08)
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)
- 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)
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