Subject: Re: [Ace] draft-ietf-ace-usecases

From: Ludwig Seitz <[email-masked]>
Date: Thu, 27 Aug 2015 11:16:09 +0200

Hello Jim,

sorry the delay in answering, it was holliday time here in Europe.

Comments inline.

On 2015-07-15 21:41, Jim Schaad wrote:
> Section 2.1 -Is it important that vendors have "real-time" information on
> the state of the container or is it sufficient to have post-mortem dumps?
> Also is it the vendor or the transporter that needs to have some of this
> information - since the transporter has a better chance to detect and fix a
> problem in transit that the vendor.

The transporter needs to have access to some real-time information,
in order to be able to prioritize items that are close to expire and to 
avoid transporting spoiled goods. They also need to know if there is a 
problem with the refrigeration in real-time. Steffi will be inquiring 
with her contacts to get more info on this.

The vendor might be happy with post-mortem dumps in many cases, although
I can imagine that real-time information might be useful, e.g. for
supply management, when the vendor wants to replace spoiled or delayed
goods in order to fulfill delivery obligations.

We'll try to condense this into a paragraph to go into 2.1

>
> Section 2.1.1 - para #2 - May need a requirement to revoke authorization on
> a sensor which is out of step with other sensors.  I.e. a single sensor
> which is reading hot when all of the others have a good temperature.
>

We'll add that as a requirement.

> Section 2.1.1 - para ? - You need to talk about the possibility that a relay
> station in the neighborhood of the bananas may need to be present.  And that
> relay station may be provided by the transport company (and change over time
> as the transport company changes) rather than the vendor.
>

We'll add a sentence and a corresponding requirement, although we cover
a similar requirement in section 2.5 (U5.8).

> Section 2.1.2 - There is a discussion going on in the COSE group about
> Integrity and if it is possible to have it in the absence of origin of data
> information.  I.e. can an anonymous note be integrity protected.  If you are
> requiring more than just integrity in U1.2 - then you need to make that
> statement.
>

Asides from knowing that the message was not altered we mainly need to 
know if the sender was authorized. For this it might be enough that the 
sender is part of an authorized group, without knowing the exact identity.

> Section 2.2 - Do you want to add a case of a child and notification to Alice
> and Bob when the child arrives home at the end of the school day?
>

Although it would be interesting as a feature, I don't think it adds
some new authentication and authorization requirements to the use case.

> Section 2.2 - Do you want to add a case where an external tech comes in to
> perform maintenance on one or more sections of the house and needs access
> both to the logs and potentially to change behaviors of subsystems?   (i.e.
> change how the furnace operates after an upgrade).
>

This scenario is alluded to in 2.2 "Such a system needs to accommodate
... a heterogeneous group of dynamically varying users (visitors,
repairmen, delivery men).".

I don't see what new requirements it would add, since we already have
U2.1, U2.2 and U2.4 which I think cover the scenario above.

> Section 2.3 - s/located physically on the user/located physically on, or in,
> the user./
Fixed

>
> Section 2.3.1 s/and his position/and his location/  Otherwise I think this
> is vertical or prone.

God catch! Fixed.

> Section 2.5 - You need to address the privacy issues implicit in this
> situation.
>

I was hoping that section 4 (Privacy Considerations) would deliver a
blanket coverage of this topic, since it is only indirectly an
authorization problem.

We could add some text about the fact that in the smart metering use 
case, devices that are not under the control of the inhabitants are 
placed into their homes, and how this could threaten their privacy. Do 
you think that would be useful?

Regards,

Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se