Use Cases for Authentication and Authorization in Constrained Environments
draft-ietf-ace-usecases-10

While I'm not ordinarily a big fan of publishing use cases as RFCs, I think this one has value.

Otherwise, I have only a few minor comments:

-Please  expand ACE in the title, abstract, and body.

- 2.6.1: Is it reasonable to expect wearable devices to have what sound like multi-user-profile capabilities?

- 2.7: An informational reference for stuxnet might be helpful.

This draft seems especially worth the effort of publishing a use case draft as an RFC. I learned a lot while reviewing it. 

The security considerations section seemed unusually valuable for a use case draft. Do the title and abstract call enough attention to that?

The section title "2.1.1. Bananas for Munich" would also be a great name for a rock band ... :-)

Excellent and well written document, thanks. I think there are
five things you could usefully add, see below. That said, I
agree that this cannot and should not try to be fully complete
so I won't argue (much:-) if you prefer to omit these. We/you
can figure out what if any text to add I'm sure, but I'm happy
to chat about that.

1. Software update is really needed and often missing and
usually hard. There's at least a need to authenticate and
authorize new firmware, when there is any update. That may not
be the same as authorizing a new config.

2. Alice buys a new device, and would like to know if it is
calling home or what it is doing before she configures it, or
perhaps before she accepts it in her network. Even if she
accepts it, she may want to be able to monitor the data it
is sending "home" e.g. to ensure her TV is not sending 
data when she inserts a USB stick, if that is undesired.

3. Device fingerprinting is a threat that ought be considered
by solution developers, especially if there is no reliable
software update. Probably the best to be done is to try to
make it hard for unauthorized parties to fingerprint a device,
but that's also hard.

4. Commercial Devices will be end-of-lifed by vendors, and yet
Alice still needs to be able to use, and perhaos to update,
the device. That calls for some kind of authorization handover
which is not quite the same as a change of ownership.

5. Penetration testing will happen and devices should not barf
even then. Maybe that's a security consideration worth a
mention.

See also the secdir review. [1] It'd be good to see a 
response to that.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06101.html