Hi Jeff: Thanks I think this is a good doc. My comment for device-type section is that we should also look at specifying additional attributes (vendor id, capabilities, revision, serial num etc) to it as I see use cases (both visibility and control) where this information could be useful. Thx Regards, Navneet From: "Ingo.Friese@telekom.demailto:Ingo.Friese@telekom.de" mailto:Ingo.Friese@telekom.de> Date: Friday, 17 January 2014 7:27 PM To: "stollman.j@gmail.commailto:stollman.j@gmail.com" mailto:stollman.j@gmail.com>, "dg-idot@kantarainitiative.orgmailto:dg-idot@kantarainitiative.org" mailto:dg-idot@kantarainitiative.org> Subject: Re: [DG-IDoT] starter set of IoT defintions Hi Jeff, I like this paper very much. That’s what we need for our terminology discussion. I totally agree with sensor and actuator. I’m not so sure with the processor. I understand that this should be a device that is taking data from the sensor (e.g. temperature) and processes some logic and gives the actuator the command to open the window or regulate the heater. But this could also be a software somewhere in the cloud. How to call it? Processor application? Ingo From: dg-idot-bounces@kantarainitiative.orgmailto:dg-idot-bounces@kantarainitiative.org [mailto:dg-idot-bounces@kantarainitiative.org] On Behalf Of j stollman Sent: Samstag, 11. Januar 2014 18:02 To: dg-idot@kantarainitiative.orgmailto:dg-idot@kantarainitiative.org Subject: [DG-IDoT] starter set of IoT defintions During our call on Friday 10 JAN, we determined that we needed to begin creating some definitions for the IoT space to prevent confusion as we move along. The attached "starter set" is a first draft at trying to define some of the concepts for which we need a common understanding in order to have fruitful discussions. Not only are these definitions open to modification, but the concepts, themselves, may require reconsideration. Accordingly, please review the attached document and send me your feedback. Once it gains a certain level of consensus I'll publish it to the IoT site. (As a matter of version control, I think it is easier to consoidate multiple individual comments on the current draft, before publishing it to the site. Thank you. Jeff -- Jeff Stollman stollman.j@gmail.commailto:stollman.j@gmail.com 1 202.683.8699tel:1%20202.683.8699 Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

Ingo, I appreciate your initiate in working to improve the straw man document. I agree with some of your suggestions and disagree with others. One key difference in our thinking is that I view the definitions if "type" as a logical architecture, while your perspective is that we need to address the physical architecture. Perhaps we need both. The group will have to decide. Below is my feedback on your proposed changes: 1. Intro bullet 1 device vs. instance. I can accept that "device" might be misleading and cause people to only think in terms of hardware. I understand your point about much of the heavy lifting of a processor being performed by software, but I believe that the term "instance" is so generic that it will create more confusion. Whether an application is on a chip, a dedicated device, a shared device, or a device in the cloud, it must run on something. The processor is really a combination of the application and the device it runs on. We might want to change the word "device," but I am uncomfortable with substituting "instance". Perhaps we should merely call it a "thing" -- one of many components on the Internet of Things. But, personally, I think that the word "thing" doesn't sound precise enough. 2. Intro bullet 2 adding the concept of identify relationships to the discussion of ownership. Identity relationships are important, but I think that they are "second order" characteristics. Because identity relationships are likely to be in continuous flux and new roles may arise for many "things," I don't think that they are as fundamental as type, ownership, and accessibility. Perhaps they represent a fourth category. But I don't think that they should be mixed with ownership. 3. Figure. 1 changing the image of processor in Figure 1 to something more "up-to-date". I have no objection to this recommendation. Have at it. 4. 1.2 Data Processor vs. Data Processor/Processor Application. I would give the same argument here as for the device issue in #1 above. Admittedly all processing requires an application, but I don't know that the distinction is important enough to complicate the picture. Just because processing takes place in the cloud rather than locally changes the physical architecture but not the logical architecture. 5. 1.4 Adding gateway as a device type. I see "gateway" as an element of the network, not of the "things" on the network. The "Internet of Things" isn't just a collection of things; it is a collection of things connected by a network infrastructure. I see "gateway" as part of this network infrastructure, rather than one of the "things" being integrated. 6. 1.5 additions to definition of "combination". Based on my discussion regarding gateways above, I do not believe that the addition is appropriate. 7. 2. Relationships description. I don't disagree with any of the points made about the different relationships described here. I just think that they are independent of the notion of ownership and should be addressed separately. The various "relationship" roles all need to be allocated by the "owner" -- though the owner may choose to delegate some of his authority. 8. 3.1 additions to the definition of "discoverable". I have no objection to the additions 9. 3.2 additional to the definition of "not discoverable". I would argue that a "thing" not connected to the network is not a member of the "Internet of Things" and, therefore, falls outside of the scope of the document. For this reason, I would not support the addition. On Thu, Feb 13, 2014 at 8:26 AM, wrote:

Hi,

I tried to extend the paper a bit. Let's see if you agree with the changes. They are marked with yellow.

Best,

Ingo

*From:* dg-idot-bounces@kantarainitiative.org [mailto: dg-idot-bounces@kantarainitiative.org] *On Behalf Of *j stollman *Sent:* Samstag, 11. Januar 2014 18:02 *To:* dg-idot@kantarainitiative.org *Subject:* [DG-IDoT] starter set of IoT defintions

During our call on Friday 10 JAN, we determined that we needed to begin creating some definitions for the IoT space to prevent confusion as we move along.

The attached "starter set" is a first draft at trying to define some of the concepts for which we need a common understanding in order to have fruitful discussions. Not only are these definitions open to modification, but the concepts, themselves, may require reconsideration.

Accordingly, please review the attached document and send me your feedback. Once it gains a certain level of consensus I'll publish it to the IoT site. (As a matter of version control, I think it is easier to consoidate multiple individual comments on the current draft, before publishing it to the site.

Thank you.

Jeff

-- Jeff Stollman stollman.j@gmail.com 1 202.683.8699

Truth never triumphs -- its opponents just die out.

Science advances one funeral at a time.

Max Planck

-- Jeff Stollman stollman.j@gmail.com 1 202.683.8699 Truth never triumphs -- its opponents just die out. Science advances one funeral at a time. Max Planck

Ingo, I recommend that, rather than trying to resolve these over email, we take these issues up with the group, to take advantage of the broad expertise and additional opinions of our colleagues. Let's discuss these are our next meeting. Thank you. Jeff On Fri, Feb 14, 2014 at 9:25 AM, wrote:

Hi Jeff,

Find my remarks inside your mail.

*From:* j stollman [mailto:stollman.j@gmail.com] *Sent:* Donnerstag, 13. Februar 2014 17:38 *To:* Friese, Ingo *Cc:* BAILLEUX Benoit OLNC/OLPS; Mildner, Frank; Keith Uber; Salvatore D'Agostino; dg-idot@kantarainitiative.org *Subject:* Re: [DG-IDoT] starter set of IoT defintions

Ingo,

I appreciate your initiate in working to improve the straw man document. I agree with some of your suggestions and disagree with others. One key difference in our thinking is that I view the definitions if "type" as a logical architecture, while your perspective is that we need to address the physical architecture. Perhaps we need both. The group will have to decide. (perhaps we can merge both views)

Below is my feedback on your proposed changes:

1. Intro bullet 1 device vs. instance. I can accept that "device" might be misleading and cause people to only think in terms of hardware. I understand your point about much of the heavy lifting of a processor being performed by software, but I believe that the term "instance" is so generic that it will create more confusion. Whether an application is on a chip, a dedicated device, a shared device, or a device in the cloud, it must run on something. The processor is really a combination of the application and the device it runs on. We might want to change the word "device," but I am uncomfortable with substituting "instance". Perhaps we should merely call it a "thing" -- one of many components on the Internet of Things. But, personally, I think that the word "thing" doesn't sound precise enough. (Ingo: I agree "instance" is too vague...just thought about the fact...that a piece of software somewhere in the cloud is not really a device. What about "Device/Applikation" 2. Intro bullet 2 adding the concept of identify relationships to the discussion of ownership. Identity relationships are important, but I think that they are "second order" characteristics. Because identity relationships are likely to be in continuous flux and new roles may arise for many "things," I don't think that they are as fundamental as type, ownership, and accessibility. Perhaps they represent a fourth category. But I don't think that they should be mixed with ownership. (I accept that identity relationships are maybe a different kind of category. But coming back to ownership. To me there is no difference for an IOT system whether its in a private or public ownership. Maybe we can shape the description here. 3. Figure. 1 changing the image of processor in Figure 1 to something more "up-to-date". I have no objection to this recommendation. Have at it. 4. 1.2 Data Processor vs. Data Processor/Processor Application. I would give the same argument here as for the device issue in #1 above. Admittedly all processing requires an application, but I don't know that the distinction is important enough to complicate the picture. Just because processing takes place in the cloud rather than locally changes the physical architecture but not the logical architecture. 5. 1.4 Adding gateway as a device type. I see "gateway" as an element of the network, not of the "things" on the network. The "Internet of Things" isn't just a collection of things; it is a collection of things connected by a network infrastructure. I see "gateway" as part of this network infrastructure, rather than one of the "things" being integrated.Yes and no.. In real life there are Gateways/e.g. Home-Automation Gateways. On the one-hand you are right we can abstract everything to ta cloudy network but on the other hand there are functions e.g. policy/access control that are especial to gateways... 6. 1.5 additions to definition of "combination". Based on my discussion regarding gateways above, I do not believe that the addition is appropriate. 7. 2. Relationships description. I don't disagree with any of the points made about the different relationships described here. I just think that they are independent of the notion of ownership and should be addressed separately. The various "relationship" roles all need to be allocated by the "owner" -- though the owner may choose to delegate some of his authority. ok 8. 3.1 additions to the definition of "discoverable". I have no objection to the additions 9. 3.2 additional to the definition of "not discoverable". I would argue that a "thing" not connected to the network is not a member of the "Internet of Things" and, therefore, falls outside of the scope of the document. For this reason, I would not support the addition. Maybe my text was misleading...in fact I mean that there is IP-connectivity but there is no connection on a higher protocol stack...I have to reformulate it.

Thanks and have a great weekend.

Ingo

On Thu, Feb 13, 2014 at 8:26 AM, wrote:

Hi,

I tried to extend the paper a bit. Let's see if you agree with the changes. They are marked with yellow.

Best,

Ingo

*From:* dg-idot-bounces@kantarainitiative.org [mailto: dg-idot-bounces@kantarainitiative.org] *On Behalf Of *j stollman *Sent:* Samstag, 11. Januar 2014 18:02 *To:* dg-idot@kantarainitiative.org *Subject:* [DG-IDoT] starter set of IoT defintions

During our call on Friday 10 JAN, we determined that we needed to begin creating some definitions for the IoT space to prevent confusion as we move along.

The attached "starter set" is a first draft at trying to define some of the concepts for which we need a common understanding in order to have fruitful discussions. Not only are these definitions open to modification, but the concepts, themselves, may require reconsideration.

Accordingly, please review the attached document and send me your feedback. Once it gains a certain level of consensus I'll publish it to the IoT site. (As a matter of version control, I think it is easier to consoidate multiple individual comments on the current draft, before publishing it to the site.

Thank you.

Jeff

-- Jeff Stollman stollman.j@gmail.com 1 202.683.8699

Truth never triumphs -- its opponents just die out.

Science advances one funeral at a time.

Max Planck

-- Jeff Stollman stollman.j@gmail.com 1 202.683.8699

Truth never triumphs -- its opponents just die out.

Science advances one funeral at a time.

Max Planck

-- Jeff Stollman stollman.j@gmail.com 1 202.683.8699 Truth never triumphs -- its opponents just die out. Science advances one funeral at a time. Max Planck