Subject: [Ace] [ACE] review draft-ietf-ace-usecases-06

From: Somaraju Abhinav <[email-masked]>
Date: Thu, 1 Oct 2015 15:28:48 +0000

Hi All,

Please see below my review of the use-cases draft.

Regards,

Abhinav

Page 3, last paragraph: "We assume that the communication between the devices is based on the
   Representational State Transfer (REST) architectural style, i.e. a
   device acts as a server that offers resources such as sensor data and
   actuators".
Is this true for all interactions in the constrained world? For several event driven systems, does it not make sense to also support some "RPC" like features? In some of the models we are looking at in the indoor professional lighting domain, it is planned to use CoAP POST to execute an action and not to create a new resource.

The remaining comments I have are only regarding the Building Automation usecase because of my background working for an Indoor professional lighting company.

Sec. 2.4.1.1. "A vacant area of the building has been recently leased to company A.

   Before moving into its new office, Company A wishes to replace the

   lighting with a more energy efficient and a better light quality

   luminaries.  They hire an installation and commissioning company C to

   redo the illumination."

>From my knowledge of Building automation and professional lighting this scenario is highly unlikely. Usually a leasing company hires a space and the lights come as package with the space and are built into the leasing company's contract. If the leasing company wishes to change the luminaires they typically have to speak to the (representative of) the building owner but this is quite rare. There are some specific regions in the world e.g. central EU where this is not always the case. Sometimes in central EU, the buildings do not have any built in luminaires and the leasing companies bring in their own freestanding luminaires. It is very rarely the case that a leasing tenant hires a contractor to change the lighting system. The situations is more complicated for HVAC systems which often need to satisfy regulatory requirements. HVAC systems are often done building wide and are very rarely tenant specific.

A very important aspect of the installation/commissioning workflow has been overlooked. Typically, installation in the building occur in the following order (in a new building). 1) Installation of the lighting devices by an untrained electrician, 2) A lighting commissioning engineer who configures lights 3) Installation of HVAC systems 4) First presence of trained IT professionals.

So, the initial commissioning/installation process needs to be performed by people with no IT knowledge and with the IT backbone not being present. Also, the commissioning goes in phases with different floors being commissioned at different times and then later connected together with the IT backbone. Not having the IT backbone during commissioning puts big constraints because it is difficult to use public key certs during this process.

Another point is that Authorization rules may also be role based. E.g. A commissioner/facility manager might be able to configure devices but a user may only be able to dim up/down the lights.

2.4.1.3 Maintenance

The roles of a facility manager and commissioner (at least in building speak) are confused here. Depending on the type of building, there is a facility manager who takes care of issues during the device operation. If changes are required the facility manager is usually able to make the changes. The facility manager is sometimes the same individual as the commissioner but not always. We need to put procedures in place so that the commissioner who commissions at the start can "hand-over" the system to the facility manager.

The most common maintenance issue that occur is that of replacing broken devices. Therefore, the "authorizations" need to be transferred to the replacement device.

A phase that occurs several times and not covered in this use case is recommissioning. This may occur in several situations: 1) when one tenant moves out and a new one moves in, 2) Changes in the office space, 3) removing a device from one system and adding it to another

________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 2 Oct 2015 10:58:12 +0200

> Please see below my review of the use-cases draft.

Hello Abhinav,

thank you for reviewing our document. Comments inline.

/Ludwig

>
> Page 3, last paragraph: „We assume that the communication between the devices is based on the
>
>     actuators”.
> Is this true for all interactions in the constrained world? For several
> event driven systems, does it not make sense to also support some “RPC”
> like features? In some of the models we are looking at in the indoor
> professional lighting domain, it is planned to use CoAP POST to execute
> an action and not to create a new resource.

Actually when looking at the use cases it's true there is nothing that 
would specifically exclude RPC-like communication. I'll try to rephrase 
this to make it more neutral.

>
> The remaining comments I have are only regarding the Building Automation
> usecase because of my background working for an Indoor professional
> lighting company.

This makes your comments a very valuable contribution. I'm hoping that 
Sandeep who was the main author of this section will have some time to 
address you comments. If not I will give it a try.

Regards,

Ludwig Seitz

-- 
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

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 2 Oct 2015 15:17:50 +0000

Hi Abhinav

See comments inline

From: Ace [mailto:[email-masked]] On Behalf Of Somaraju Abhinav
Sent: Thursday, October 01, 2015 5:29 PM
To: [email-masked]
Subject: [Ace] [ACE] review draft-ietf-ace-usecases-06

Hi All,

Regards,

Abhinav

   redo the illumination."

>From my knowledge of Building automation and professional lighting this scenario is highly unlikely. Usually a leasing company hires a space and the lights come as package with the space and are bui…

[> ] You are right about the current status in certain central European countries regarding how office space leasing is done. I have taken a more general approach to include issues from other domains like retail where indoor lighting is tied closely to the branding independent of where they lease their space. Instead of creating multiple use cases or geographic specific cases, I took a practical approach to extend the office scenario that can explain what type of issues may be relevant in professional lighting in different related domains. This way technology developed in ACE is the not the blocking factor for end-users to demand a different choice than they have today. Does the extension bother you regarding how it would guide the solution direction making it inapplicable in your more restricted setting?

[> ] Indeed true regarding no IT connectivity to devices and forming individual islands before joining them for a new installation. I think I had it in the previous version but it changed after it combined with the HVAC use case.  The current description is more shifted towards an already up and running system which changes ownership. I can include in those things. Do you see other authorization problems that needs to be added based on the change?

I do not know if it directly means "no public key certs" since the commissioning tool can potentially be connected to a backend.

[> ] That sounds more like the choice of solution rather than an authorization problem.

2.4.1.3 Maintenance

[> ] The current text does imply a handover to the facility manager (the service company) since the commissioner needs new authorization to make changes during the maintenance stage. Do you have any specific authorization problems in mind by the "hand over" which is not already covered in U4.2 (if you could change the name of the actors).

[> ] This is a good one but needs to be detailed in terms of how much interaction is needed from the one doing the transfer. It should be less than normal commissioning U4.1 but cannot be zero-configuration either. Any text is welcome.

[> ] I tried to leave this phase out since I did not see any new authorization problems (the whole use case is kind of depicted as a recommissioning). The point of the document is not to explain lighting but to guide the solution development. If you think any new authorization problems need to be added, we can include this phase. Please let me know.

Regards

Sandeep

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 05 Oct 2015 09:53:25 +0200

Somaraju Abhinav <[email-masked]> writes:

> Is this true for all interactions in the constrained world? For
> several event driven systems, does it not make sense to also support
> some “RPC” like features? In some of the models we are looking at in
> the indoor professional lighting domain, it is planned to use CoAP
> POST to execute an action and not to create a new resource. 

As far as I understand, you do not have to actually create a new
resource to call a POST "REST-ful". If your design is clean, it can
still be REST.

Grüße
Olaf

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 5 Oct 2015 08:12:19 +0000

Hi Sandeep,
Thanks for the reply. Maybe there is a confusion of terminology here. The situation that you described in the installation/commissioning section is what I would usually call recommissioning. Please see remaining comments inline.

   redo the illumination."

[AS] My main issue is that commissioning a part of the building by the leasing company using independent contractors is very much a corner case when it comes to Building automation (and almost never applicable to anything other than (retail) lighting because of regulatory requirements). Maybe my previous email was not clear about this point - Central EU is sometimes an exception to this rule and is one of the corner cases where the leasing company brings their "own lighting using free-standing luminaires". My concern with the text is that the main issues with regards to initial installation/commissioning in buildings have not been mentioned (which is the following point).

[AS] I can only judge new authorization problems after looking at the text. Some of the key issues during the initial commissioning phase are: 1) Phased commissioning/installation: different parts of the building are installed by (sometimes) different installers/commissioners usually by people with no IT background. But at a later stage when the parts are connected, they have to work as a single system. 2) Lack of IT backbone as already mentioned (though the commissioner can use public key certs the devices probably can't authenticate commissioner - maybe not important?), 3) Requiring some out of the box functionality before the commissioner is on site to allow some installation testing, 4) The devices being physically inaccessible when the commissioner is on site but only being accessible during installation (e.g. HVAC valves or ceiling mounted luminaires - this rules out options such as NFC sometimes) 5) Usually there is a long B-2-B chain before the devices reach the customer (unlike maybe home automation) 6) The initial installers/commissioners will need to install devices from multiple different suppliers (rules out a single company selling "gateway+device" combinations with specific commissioning methods).

I think it is important that the use-case document captures these initial installation/commissioning issues rather than focus on the corner case of one tenant independently re-commissioning a part of the building.

My use case of installation/commissioning will go along the following lines: 1) Building owner hires contractor, 2) Contractor hires: architect (to design), electrician (to install) and commissioner (there are several permutations of the above possible with additional actors), 3) Electrician (usually not highly qualified) installs the devices and needs to prove wiring was done properly (so needs some out of the box probably unsecured communication), 4) Commissioner comes on site and connects devices to talk to each other (This phase could happen in parallel on multiple floors and sometimes even in parallel with installation). Sometimes there are 10-100 thousand devices in the building. Also, several devices are not physically accessible to the commissioner. This makes it for instance very difficult to map the physical local of sensors (e.g. motion sensors), 5) IT engineer comes on site and connects up the IT backbone and the devices are exposed to the wider internet for the first time. 6) The devices continue to work with not requiring the commissioner to come back on site.

[AS] I would not say this is a choice of solution. In general the users of the indoor BA can be grouped into categories - maintenance personnel, (night-time) cleaners, commissioners, BMS, LMS systems, end users (that may occupy certain floors). The authorization problem is that these categories of users need different access rights. The solution could be a role based authorization policy or based on individual authorization policies using unique identification of the user. However, the fact that such categories of users exist is really the underlying authorization problem.

2.4.1.3 Maintenance

[AS] No.

[AS] There are two parts to this - first part is configuring the new device and of course it cannot be zero configuration. The second part is that proper disposal of the broken device - hopefully when you through the device in the bin and somebody else gets access to it, you do not create any new problems.

[AS] You cover this use-case to a large extent in the installation/commissioning section. However, maybe I missed the point about if a device is removed from one system and recommissioned to a new one then you should not be able to break the old system with the device that has been recommissioned. Difference from decommissioning use-case is that the device stills needs to work properly in the new system.

Regards

Sandeep

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 5 Oct 2015 08:37:16 +0000

Hi Olaf,
Thanks for the clarification. I usually do not understand exactly when an API is RESTful. If you think all the use cases can be covered with Restful APIs, then please ignore my comment - the distinction between Restful vs RPC is not very important for me.
Abhinav

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Olaf Bergmann
Sent: Montag, 05. Oktober 2015 09:53
To: Somaraju Abhinav
Cc: [email-masked]
Subject: Re: [Ace] [ACE] review draft-ietf-ace-usecases-06

> POST to execute an action and not to create a new resource.

As far as I understand, you do not have to actually create a new resource to call a POST "REST-ful". If your design is clean, it can still be REST.

Grüße
Olaf

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace
________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Mon, 5 Oct 2015 08:37:10 +0000

Hi Abhinav

True..I tried to combine the commissioning into the re-commissioning phase to get the main ideas related to commissioning and the maintenance part together. Indeed the first commissioning can be quite different from a later commissioning since the supporting infrastructure (like IT ) may now be available (although the supporting infrastructure may itself be in a re-commissioning phase making it unavailable, but let's not get into those details). Anyways I will make a re-edit to get your main concerns more clearly stated in the document.

Regards
Sandeep

From: Somaraju Abhinav [mailto:[email-masked]]
Sent: Monday, October 05, 2015 10:12 AM
To: Kumar, Sandeep <[email-masked]>; [email-masked]
Subject: RE: [ACE] review draft-ietf-ace-usecases-06

Hi Sandeep,

   redo the illumination."

2.4.1.3 Maintenance

[AS] No.

Regards

Sandeep

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 05 Oct 2015 11:05:04 +0200

Somaraju Abhinav <[email-masked]> writes:

> Thanks for the clarification. I usually do not understand exactly when
> an API is RESTful. If you think all the use cases can be covered with
> Restful APIs, then please ignore my comment - the distinction between
> Restful vs RPC is not very important for me.

Fair enough. What I wanted to avoid is to open up the ACE for boiling
the ocean. After taking out CoAP we are going to take out
REST... Hopefully, we do not end up in taking out authorization :-)

Grüße
Olaf

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 5 Oct 2015 09:13:54 +0000

Grt! Looking forward to your new draft.
Abhinav

From: Kumar, Sandeep [mailto:[email-masked]]
Sent: Montag, 05. Oktober 2015 10:37
To: Somaraju Abhinav; [email-masked]
Subject: RE: [ACE] review draft-ietf-ace-usecases-06

Hi Abhinav

Regards
Sandeep

From: Somaraju Abhinav [mailto:[email-masked]]
Sent: Monday, October 05, 2015 10:12 AM
To: Kumar, Sandeep <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [ACE] review draft-ietf-ace-usecases-06

Hi Sandeep,

   redo the illumination."

2.4.1.3 Maintenance

[AS] No.

Regards

Sandeep