Subject: Re: [Ace] Variants (was: Re: Fwd: I-D Action:draft-ietf-ace-usecase

From: "Kepeng Li" <[email-masked]>
Date: Wed, 18 Feb 2015 17:39:08 +0800

> It is not optional to solve the U1.2 problem.

It seems that this is the main disagreement beteween each other.

As Hannes mentioned, this is actually about requirements.

In last F2F meeting, there were some comments to remove requirements in the use case document.

I suggest that we don't talk too much about requirement at this stage.

Kepeng

------------------ 原始邮件 ------------------
发件人: "Stefanie Gerdes" <[email-masked]>;
发送时间: 2015年2月18日(星期三) 1:40
收件人: "G��ran Selander" <[email-masked]>;
抄送: "[email-masked]" <[email-masked]>;
主题: [Ace] Variants (was: Re: Fwd: I-D Action:draft-ietf-ace-usecases-02.txt)

Hi G��ran,

On 02/16/2015 08:21 PM, G��ran Selander wrote:
> Hi Steffi,
>
> About the Charter: If you ask about people what "authorized access to
> resources identified by a URI and hosted on a
> resource server” means, I think many would make the interpretation in U1.1
> and very few, if any, would make the interpretation of U1.2. Stating that
> the charter supports your claim is IMHO an over-interpretation.
>
> There are also other "problems” of the Client Owners, like the examples I
> mentioned in
> http://www.ietf.org/mail-archive/web/ace/current/msg00989.html. The
> assumption that U1.2 should be solved with access control policies (if
> that is implied) is arbitrary.
>
> About requirement vs problem: If a candidate solution does not solve
> problem U1.1 that is not acceptable. However, we should not discriminate
> solutions which does not solve U1.2 with access control policies. If we
> have this formulation, it should be made clear that U1.2 is optional.

It is not optional to solve the U1.2 problem. In some cases 
authorization problems might be solved by implicit authorization. We can 
point this out in the security considerations. We can add the following 
to 3.2: Endpoints need to be enabled to enforce the authorization 
policies of their principals. In some cases, authorization problems 
might bei solved by implicit authorization (all authenticated entities 
are authorized).

>
> You should keep "such as the fruit vendor and container owner” etc. in the
> formulation, just as you had in your previous version. One major point
> with the problem formulation is to explain the terminology in terms of the
> actors of the use case.

We will not be able to decide whether a fruit vendor will in every case 
be a client owner or a resource owner. To make this more clear, we can 
add the following section to the container use case (I think this is a 
useful exercise since it shows the various possible settings):

# Variants

As mentioned in section 2, there are various reasons for assigning a 
function (CoAP client or server) to a device. This section lists 
possible settings for the communication between a temperature sensor and 
a fan actuator.

## Temperature Sensor and Fan Actuator Servers

Temperature sensors and fan actuators are servers, an aggregation server 
that belongs to the container owner is the client. Therefore, the fruit 
vendor is a Resource Owner. The container owner is a Resource Owner and 
a Client Owner.

Temperature sensors are resources on individual CoAP servers that belong 
to the fruit vendor. The CoAP client is an aggregation server that 
requests the temperature values from the servers and computes a 
temperature setting from these results. The result is then transmitted 
to the ventilation system of the container owner.

## Temperature Sensor and Fan Actuator Clients

Temperature sensors and fan actuators are located on clients. An 
aggregation server that belongs to the container owner is a server. The 
fruit vendor is a Client Owner. The container owner is a Client Owner 
and a Resource Owner.

The clients with the temperature sensors send a representation of the 
current temperature values to a resource on the aggregation server 
whenever the temperature changes. The client that controls the fan 
actuator requests the aggregated temperature values from the aggregation 
server. It uses observe to receive resource representations periodically.

## Temperature Sensor Client and Fan Actuator Server

Temperature sensors are located on a client. The fan actuator is located 
on a server. An aggregation server that belongs to the container owner 
acts as a resource server for the temperature sensor and as a client for 
the fan actuator server.

The client with the temperature sensor sends a representation of the 
current temperature values to a resource on the aggregation server 
whenever the temperature changes. The aggregation server then acts as a 
client to send the aggregated temperature values to a resource on the 
fan actuator server.

## Temperature Sensor Server and Fan Actuator Client Communicating directly

Temperature sensors are located on a server. The fan actuator is located 
on a client. The fruit vendor is a resource owner, the container owner 
is a client owner.

The client with the fan actuator requests the current sensor values 
directly from the nearest temperature sensor. It uses observe to get 
regular updates of the resource representation. The fan can react 
directly to local temperature changes and thus allows for an optimal 
temperature at different places within a container.

## Temperature Sensor Client and Fan Actuator Server Communicating directly

Temperature sensors are located on a client. The fan actuator is located 
on a server. The fruit vendor is a Client Owner, the container owner is 
a Resource Owner.

The client with the temperature sensor sends a representation of the 
current temperature values directly to a resource on the fan actuator 
server. The fan can react directly to local temperature changes as 
described above.

Best regards,
Steffi

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 18 Feb 2015 15:35:56 +0100

Hi Kepeng,

> I suggest that we don't talk too much about requirement at this stage.

Yes, thank you. That is the reason why I proposed to just list the 
problems. From what I understood, we agree that U1.2 is a problem. It 
therefore should be listed in the problem summary section.

I suggested to add text to section 3.2 (Configuration of Access 
Permissions) that indicates that the listed problems can be solved in 
different ways.

Where possible, the use cases document uses neutral terminology such as 
"principal" to make sure that we don't indicate a specific solution. 
Replacing the terminology by solution specific terms that are not 
deducible from the use cases is not useful.

Best regards,
Steffi