Hi All, I'm back from vacation and business trips. One week ago I promoted our group at IEEE IoT workshop. Find attached my slide set. I'd like to draw your attention to slide 4. This is my attempt to cluster and to prioritize different IdM Topics (identifier, mapping, discovery, authentication, authorization, privacy...). I saw a youtube video by Scott Jenson (@Paul thanks for sending the link to the list). Scott sees three layers of complexity in the IoT. - First one is about simple sensors/actuators e.g. measuring the temperature at "central square" - here the challenge is discovery - Second layer is "control" - it's about putting some restrictive elements in front of the sensor - a user needs to authenticate etc. - Third layer is "coordination"-it's about many devices acting together according to certain policies etc. Along these layers I located different sub-topics of our identity discussion. Maybe it's a good way to bring some order and focus to our groups topics. It would be good to match this order with your current IoT projects/experiences and provide feedback. Many greets, Ingo
Thanks Ingo, Yes that's a traditional SCADA approach. Certainly applies, sensor \controller\ network At the same time the reason we are talking about this is that much of this is available at the edge. Rgds all, Sal From: dg-idot-bounces@kantarainitiative.org [mailto:dg-idot-bounces@kantarainitiative.org] On Behalf Of Ingo.Friese@telekom.de Sent: Monday, November 18, 2013 8:49 AM To: dg-idot@kantarainitiative.org Subject: [DG-IDoT] out IDoT topics Hi All, I'm back from vacation and business trips. One week ago I promoted our group at IEEE IoT workshop. Find attached my slide set. I'd like to draw your attention to slide 4. This is my attempt to cluster and to prioritize different IdM Topics (identifier, mapping, discovery, authentication, authorization, privacy.). I saw a youtube video by Scott Jenson (@Paul thanks for sending the link to the list). Scott sees three layers of complexity in the IoT. - First one is about simple sensors/actuators e.g. measuring the temperature at "central square" - here the challenge is discovery - Second layer is "control" - it's about putting some restrictive elements in front of the sensor - a user needs to authenticate etc. - Third layer is "coordination"-it's about many devices acting together according to certain policies etc. Along these layers I located different sub-topics of our identity discussion. Maybe it's a good way to bring some order and focus to our groups topics. It would be good to match this order with your current IoT projects/experiences and provide feedback. Many greets, Ingo
I am not yet convinced that the ability to link everything through a single protocol is desirable. The notion of being able to obtain data from all sensors and/or to be able to control all active components is alluring. But, I would assert that anything that we can do with this new ability, adversaries can exploit as well. The notion of defense-in-depth is to complicate control of devices by using multiple protocols. This makes it more difficult for adversaries to take over our networks and devices. Deciding which devices to make easily accessible and which to make more complicated is going to be a complicated process. Jeff On Mon, Nov 18, 2013 at 9:16 AM, Salvatore D'Agostino <sal@idmachines.com>wrote:
Thanks Ingo,
Yes that’s a traditional SCADA approach. Certainly applies, sensor \controller\ network
At the same time the reason we are talking about this is that much of this is available at the edge.
Rgds all,
Sal
*From:* dg-idot-bounces@kantarainitiative.org [mailto: dg-idot-bounces@kantarainitiative.org] *On Behalf Of * Ingo.Friese@telekom.de *Sent:* Monday, November 18, 2013 8:49 AM *To:* dg-idot@kantarainitiative.org *Subject:* [DG-IDoT] out IDoT topics
Hi All,
I’m back from vacation and business trips. One week ago I promoted our group at IEEE IoT workshop.
Find attached my slide set.
I’d like to draw your attention to slide 4. This is my attempt to cluster and to prioritize different IdM Topics
(identifier, mapping, discovery, authentication, authorization, privacy…).
I saw a youtube video by Scott Jenson (@Paul thanks for sending the link to the list). Scott sees three layers of complexity in the IoT.
- First one is about simple sensors/actuators e.g. measuring the temperature at “central square” – here the challenge is discovery
- Second layer is “control” – it’s about putting some restrictive elements in front of the sensor – a user needs to authenticate etc.
- Third layer is “coordination”-it’s about many devices acting together according to certain policies etc.
Along these layers I located different sub-topics of our identity discussion.
Maybe it’s a good way to bring some order and focus to our groups topics.
It would be good to match this order with your current IoT projects/experiences and provide feedback.
Many greets,
Ingo
_______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot
-- 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
To me this is not a question of a single protocol its rather a model to focus and group our topics. We have limited resources and can not handle everything at a time. So this was my first attempt to bring focus and priorities in our topics. From: j stollman [mailto:stollman.j@gmail.com] Sent: Montag, 18. November 2013 23:40 To: Salvatore D'Agostino Cc: Friese, Ingo; dg-idot@kantarainitiative.org Subject: Re: [DG-IDoT] out IDoT topics I am not yet convinced that the ability to link everything through a single protocol is desirable. The notion of being able to obtain data from all sensors and/or to be able to control all active components is alluring. But, I would assert that anything that we can do with this new ability, adversaries can exploit as well. The notion of defense-in-depth is to complicate control of devices by using multiple protocols. This makes it more difficult for adversaries to take over our networks and devices. Deciding which devices to make easily accessible and which to make more complicated is going to be a complicated process. Jeff On Mon, Nov 18, 2013 at 9:16 AM, Salvatore D'Agostino <sal@idmachines.com<mailto:sal@idmachines.com>> wrote: Thanks Ingo, Yes that's a traditional SCADA approach. Certainly applies, sensor \controller\ network At the same time the reason we are talking about this is that much of this is available at the edge. Rgds all, Sal From: dg-idot-bounces@kantarainitiative.org<mailto:dg-idot-bounces@kantarainitiative.org> [mailto:dg-idot-bounces@kantarainitiative.org<mailto:dg-idot-bounces@kantarainitiative.org>] On Behalf Of Ingo.Friese@telekom.de<mailto:Ingo.Friese@telekom.de> Sent: Monday, November 18, 2013 8:49 AM To: dg-idot@kantarainitiative.org<mailto:dg-idot@kantarainitiative.org> Subject: [DG-IDoT] out IDoT topics Hi All, I'm back from vacation and business trips. One week ago I promoted our group at IEEE IoT workshop. Find attached my slide set. I'd like to draw your attention to slide 4. This is my attempt to cluster and to prioritize different IdM Topics (identifier, mapping, discovery, authentication, authorization, privacy...). I saw a youtube video by Scott Jenson (@Paul thanks for sending the link to the list). Scott sees three layers of complexity in the IoT. - First one is about simple sensors/actuators e.g. measuring the temperature at "central square" - here the challenge is discovery - Second layer is "control" - it's about putting some restrictive elements in front of the sensor - a user needs to authenticate etc. - Third layer is "coordination"-it's about many devices acting together according to certain policies etc. Along these layers I located different sub-topics of our identity discussion. Maybe it's a good way to bring some order and focus to our groups topics. It would be good to match this order with your current IoT projects/experiences and provide feedback. Many greets, Ingo _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org<mailto:DG-IDoT@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-idot -- Jeff Stollman stollman.j@gmail.com<mailto: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, I won't say that linking everything by a single protocol is desirable, as I don't think it is, but I don't agree that using multiple protocols is a viable defense-in-depth strategy. It could be seen perhaps more like security by obscurity, and while it may initially make it more difficult for adversaries to take over networks and devices, it also makes it harder for us to manage the networks ourselves as we deal with the protocol soup and may give us a false sense of security Wouldn't it be better to invest in trying to ensure we have a relatively small number of hardened protocols (perhaps engineered for specific problem domains?) that we focus on, rather than a potentially large number of relatively insecure protocols due to the diluted efforts across vendors? Cheers, Einar On Nov 18, 2013, at 10:39 PM, j stollman <stollman.j@gmail.com<mailto:stollman.j@gmail.com>> wrote: I am not yet convinced that the ability to link everything through a single protocol is desirable. The notion of being able to obtain data from all sensors and/or to be able to control all active components is alluring. But, I would assert that anything that we can do with this new ability, adversaries can exploit as well. The notion of defense-in-depth is to complicate control of devices by using multiple protocols. This makes it more difficult for adversaries to take over our networks and devices. Deciding which devices to make easily accessible and which to make more complicated is going to be a complicated process. Jeff On Mon, Nov 18, 2013 at 9:16 AM, Salvatore D'Agostino <sal@idmachines.com<mailto:sal@idmachines.com>> wrote: Thanks Ingo, Yes that’s a traditional SCADA approach. Certainly applies, sensor \controller\ network At the same time the reason we are talking about this is that much of this is available at the edge. Rgds all, Sal From: dg-idot-bounces@kantarainitiative.org<mailto:dg-idot-bounces@kantarainitiative.org> [mailto:dg-idot-bounces@kantarainitiative.org<mailto:dg-idot-bounces@kantarainitiative.org>] On Behalf Of Ingo.Friese@telekom.de<mailto:Ingo.Friese@telekom.de> Sent: Monday, November 18, 2013 8:49 AM To: dg-idot@kantarainitiative.org<mailto:dg-idot@kantarainitiative.org> Subject: [DG-IDoT] out IDoT topics Hi All, I’m back from vacation and business trips. One week ago I promoted our group at IEEE IoT workshop. Find attached my slide set. I’d like to draw your attention to slide 4. This is my attempt to cluster and to prioritize different IdM Topics (identifier, mapping, discovery, authentication, authorization, privacy…). I saw a youtube video by Scott Jenson (@Paul thanks for sending the link to the list). Scott sees three layers of complexity in the IoT. - First one is about simple sensors/actuators e.g. measuring the temperature at “central square” – here the challenge is discovery - Second layer is “control” – it’s about putting some restrictive elements in front of the sensor – a user needs to authenticate etc. - Third layer is “coordination”-it’s about many devices acting together according to certain policies etc. Along these layers I located different sub-topics of our identity discussion. Maybe it’s a good way to bring some order and focus to our groups topics. It would be good to match this order with your current IoT projects/experiences and provide feedback. Many greets, Ingo _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org<mailto:DG-IDoT@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-idot -- Jeff Stollman stollman.j@gmail.com<mailto: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 _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org<mailto:DG-IDoT@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-idot
Einar, You are correct in calling my concept "security by obscurity." And this is a good solution only for unpopular (obscure) protocols. It won't solve the problem for popular protocols. And the success of obscure protocols may cause them to eventually become popular. So it is not a good long-term strategy. I wholeheartedly agree that developing a few hardened protocols is a better solution. I am just not convinced that such protocols can be developed. The more devices use them, the greater the potential pay-off for bad actors. And, as we have already seen in the ordinary internet, bad actors are not limited to desperate, uneducated, poor people. Adversaries have the same skill level as the best protocol developers. And they continue to find new exploits as we patch the old ones. But the reason I am participating in this discussion is in the hope that we can come up with some viable solutions that solve enough of the issues for enough of the use cases to prevent IoT from collapsing under the weight of its vulnerabilities. Thank you for your insight. Jeff On Tue, Nov 19, 2013 at 6:11 PM, Einar Nilsen-Nygaard (einarnn) < einarnn@cisco.com> wrote:
Jeff,
I won't say that linking everything by a single protocol is desirable, as I don't think it is, but I don't agree that using multiple protocols is a viable defense-in-depth strategy. It could be seen perhaps more like security by obscurity, and while it may initially make it more difficult for adversaries to take over networks and devices, it also makes it harder for us to manage the networks ourselves as we deal with the protocol soup and may give us a false sense of security
Wouldn't it be better to invest in trying to ensure we have a relatively small number of hardened protocols (perhaps engineered for specific problem domains?) that we focus on, rather than a potentially large number of relatively insecure protocols due to the diluted efforts across vendors?
Cheers,
Einar
On Nov 18, 2013, at 10:39 PM, j stollman <stollman.j@gmail.com> wrote:
I am not yet convinced that the ability to link everything through a single protocol is desirable.
The notion of being able to obtain data from all sensors and/or to be able to control all active components is alluring. But, I would assert that anything that we can do with this new ability, adversaries can exploit as well.
The notion of defense-in-depth is to complicate control of devices by using multiple protocols. This makes it more difficult for adversaries to take over our networks and devices.
Deciding which devices to make easily accessible and which to make more complicated is going to be a complicated process.
Jeff
On Mon, Nov 18, 2013 at 9:16 AM, Salvatore D'Agostino <sal@idmachines.com>wrote:
Thanks Ingo,
Yes that’s a traditional SCADA approach. Certainly applies, sensor \controller\ network
At the same time the reason we are talking about this is that much of this is available at the edge.
Rgds all,
Sal
*From:* dg-idot-bounces@kantarainitiative.org [mailto: dg-idot-bounces@kantarainitiative.org] *On Behalf Of * Ingo.Friese@telekom.de *Sent:* Monday, November 18, 2013 8:49 AM *To:* dg-idot@kantarainitiative.org *Subject:* [DG-IDoT] out IDoT topics
Hi All,
I’m back from vacation and business trips. One week ago I promoted our group at IEEE IoT workshop.
Find attached my slide set.
I’d like to draw your attention to slide 4. This is my attempt to cluster and to prioritize different IdM Topics
(identifier, mapping, discovery, authentication, authorization, privacy…).
I saw a youtube video by Scott Jenson (@Paul thanks for sending the link to the list). Scott sees three layers of complexity in the IoT.
- First one is about simple sensors/actuators e.g. measuring the temperature at “central square” – here the challenge is discovery
- Second layer is “control” – it’s about putting some restrictive elements in front of the sensor – a user needs to authenticate etc.
- Third layer is “coordination”-it’s about many devices acting together according to certain policies etc.
Along these layers I located different sub-topics of our identity discussion.
Maybe it’s a good way to bring some order and focus to our groups topics.
It would be good to match this order with your current IoT projects/experiences and provide feedback.
Many greets,
Ingo
_______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot
-- 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 _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot
-- 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, I agree about who the potential attackers and adversaries are, and I also agree with your goal. Has there been a comprehensive threat model documented somewhere for IoT? Apologies for the probably newbie question, but I'm just starting to get my feet wet here. In the context of this discussion, I'm looking for the overall picture to see where it is likely that attackers would focus their efforts Cheers, Einar On Nov 20, 2013, at 3:30 PM, j stollman <stollman.j@gmail.com<mailto:stollman.j@gmail.com>> wrote: Einar, You are correct in calling my concept "security by obscurity." And this is a good solution only for unpopular (obscure) protocols. It won't solve the problem for popular protocols. And the success of obscure protocols may cause them to eventually become popular. So it is not a good long-term strategy. I wholeheartedly agree that developing a few hardened protocols is a better solution. I am just not convinced that such protocols can be developed. The more devices use them, the greater the potential pay-off for bad actors. And, as we have already seen in the ordinary internet, bad actors are not limited to desperate, uneducated, poor people. Adversaries have the same skill level as the best protocol developers. And they continue to find new exploits as we patch the old ones. But the reason I am participating in this discussion is in the hope that we can come up with some viable solutions that solve enough of the issues for enough of the use cases to prevent IoT from collapsing under the weight of its vulnerabilities. Thank you for your insight. Jeff On Tue, Nov 19, 2013 at 6:11 PM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com<mailto:einarnn@cisco.com>> wrote: Jeff, I won't say that linking everything by a single protocol is desirable, as I don't think it is, but I don't agree that using multiple protocols is a viable defense-in-depth strategy. It could be seen perhaps more like security by obscurity, and while it may initially make it more difficult for adversaries to take over networks and devices, it also makes it harder for us to manage the networks ourselves as we deal with the protocol soup and may give us a false sense of security Wouldn't it be better to invest in trying to ensure we have a relatively small number of hardened protocols (perhaps engineered for specific problem domains?) that we focus on, rather than a potentially large number of relatively insecure protocols due to the diluted efforts across vendors? Cheers, Einar On Nov 18, 2013, at 10:39 PM, j stollman <stollman.j@gmail.com<mailto:stollman.j@gmail.com>> wrote: I am not yet convinced that the ability to link everything through a single protocol is desirable. The notion of being able to obtain data from all sensors and/or to be able to control all active components is alluring. But, I would assert that anything that we can do with this new ability, adversaries can exploit as well. The notion of defense-in-depth is to complicate control of devices by using multiple protocols. This makes it more difficult for adversaries to take over our networks and devices. Deciding which devices to make easily accessible and which to make more complicated is going to be a complicated process. Jeff On Mon, Nov 18, 2013 at 9:16 AM, Salvatore D'Agostino <sal@idmachines.com<mailto:sal@idmachines.com>> wrote: Thanks Ingo, Yes that’s a traditional SCADA approach. Certainly applies, sensor \controller\ network At the same time the reason we are talking about this is that much of this is available at the edge. Rgds all, Sal From: dg-idot-bounces@kantarainitiative.org<mailto:dg-idot-bounces@kantarainitiative.org> [mailto:dg-idot-bounces@kantarainitiative.org<mailto:dg-idot-bounces@kantarainitiative.org>] On Behalf Of Ingo.Friese@telekom.de<mailto:Ingo.Friese@telekom.de> Sent: Monday, November 18, 2013 8:49 AM To: dg-idot@kantarainitiative.org<mailto:dg-idot@kantarainitiative.org> Subject: [DG-IDoT] out IDoT topics Hi All, I’m back from vacation and business trips. One week ago I promoted our group at IEEE IoT workshop. Find attached my slide set. I’d like to draw your attention to slide 4. This is my attempt to cluster and to prioritize different IdM Topics (identifier, mapping, discovery, authentication, authorization, privacy…). I saw a youtube video by Scott Jenson (@Paul thanks for sending the link to the list). Scott sees three layers of complexity in the IoT. - First one is about simple sensors/actuators e.g. measuring the temperature at “central square” – here the challenge is discovery - Second layer is “control” – it’s about putting some restrictive elements in front of the sensor – a user needs to authenticate etc. - Third layer is “coordination”-it’s about many devices acting together according to certain policies etc. Along these layers I located different sub-topics of our identity discussion. Maybe it’s a good way to bring some order and focus to our groups topics. It would be good to match this order with your current IoT projects/experiences and provide feedback. Many greets, Ingo _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org<mailto:DG-IDoT@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-idot -- Jeff Stollman stollman.j@gmail.com<mailto:stollman.j@gmail.com> 1 202.683.8699<tel:1%20202.683.8699> Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org<mailto:DG-IDoT@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-idot -- Jeff Stollman stollman.j@gmail.com<mailto: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
Not a comprehensive threat model but certainly known hacks as evidence, lots of them, e.g. http://www.canbushack.com/blog/index.php <- canbus, zigbee -> http://webdelcire.com/wordpress/archives/1714 (in Spanish) From: Einar Nilsen-Nygaard (einarnn) [mailto:einarnn@cisco.com] Sent: Wednesday, November 20, 2013 11:06 AM To: j stollman Cc: Salvatore D'Agostino; dg-idot@kantarainitiative.org Subject: Re: [DG-IDoT] out IDoT topics Jeff, I agree about who the potential attackers and adversaries are, and I also agree with your goal. Has there been a comprehensive threat model documented somewhere for IoT? Apologies for the probably newbie question, but I'm just starting to get my feet wet here. In the context of this discussion, I'm looking for the overall picture to see where it is likely that attackers would focus their efforts Cheers, Einar On Nov 20, 2013, at 3:30 PM, j stollman <stollman.j@gmail.com> wrote: Einar, You are correct in calling my concept "security by obscurity." And this is a good solution only for unpopular (obscure) protocols. It won't solve the problem for popular protocols. And the success of obscure protocols may cause them to eventually become popular. So it is not a good long-term strategy. I wholeheartedly agree that developing a few hardened protocols is a better solution. I am just not convinced that such protocols can be developed. The more devices use them, the greater the potential pay-off for bad actors. And, as we have already seen in the ordinary internet, bad actors are not limited to desperate, uneducated, poor people. Adversaries have the same skill level as the best protocol developers. And they continue to find new exploits as we patch the old ones. But the reason I am participating in this discussion is in the hope that we can come up with some viable solutions that solve enough of the issues for enough of the use cases to prevent IoT from collapsing under the weight of its vulnerabilities. Thank you for your insight. Jeff On Tue, Nov 19, 2013 at 6:11 PM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote: Jeff, I won't say that linking everything by a single protocol is desirable, as I don't think it is, but I don't agree that using multiple protocols is a viable defense-in-depth strategy. It could be seen perhaps more like security by obscurity, and while it may initially make it more difficult for adversaries to take over networks and devices, it also makes it harder for us to manage the networks ourselves as we deal with the protocol soup and may give us a false sense of security Wouldn't it be better to invest in trying to ensure we have a relatively small number of hardened protocols (perhaps engineered for specific problem domains?) that we focus on, rather than a potentially large number of relatively insecure protocols due to the diluted efforts across vendors? Cheers, Einar On Nov 18, 2013, at 10:39 PM, j stollman <stollman.j@gmail.com> wrote: I am not yet convinced that the ability to link everything through a single protocol is desirable. The notion of being able to obtain data from all sensors and/or to be able to control all active components is alluring. But, I would assert that anything that we can do with this new ability, adversaries can exploit as well. The notion of defense-in-depth is to complicate control of devices by using multiple protocols. This makes it more difficult for adversaries to take over our networks and devices. Deciding which devices to make easily accessible and which to make more complicated is going to be a complicated process. Jeff On Mon, Nov 18, 2013 at 9:16 AM, Salvatore D'Agostino <sal@idmachines.com> wrote: Thanks Ingo, Yes that's a traditional SCADA approach. Certainly applies, sensor \controller\ network At the same time the reason we are talking about this is that much of this is available at the edge. Rgds all, Sal From: dg-idot-bounces@kantarainitiative.org [mailto:dg-idot-bounces@kantarainitiative.org] On Behalf Of Ingo.Friese@telekom.de Sent: Monday, November 18, 2013 8:49 AM To: dg-idot@kantarainitiative.org Subject: [DG-IDoT] out IDoT topics Hi All, I'm back from vacation and business trips. One week ago I promoted our group at IEEE IoT workshop. Find attached my slide set. I'd like to draw your attention to slide 4. This is my attempt to cluster and to prioritize different IdM Topics (identifier, mapping, discovery, authentication, authorization, privacy.). I saw a youtube video by Scott Jenson (@Paul thanks for sending the link to the list). Scott sees three layers of complexity in the IoT. - First one is about simple sensors/actuators e.g. measuring the temperature at "central square" - here the challenge is discovery - Second layer is "control" - it's about putting some restrictive elements in front of the sensor - a user needs to authenticate etc. - Third layer is "coordination"-it's about many devices acting together according to certain policies etc. Along these layers I located different sub-topics of our identity discussion. Maybe it's a good way to bring some order and focus to our groups topics. It would be good to match this order with your current IoT projects/experiences and provide feedback. Many greets, Ingo _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot -- Jeff Stollman stollman.j@gmail.com 1 202.683.8699 <tel:1%20202.683.8699> Truth never triumphs - its opponents just die out. Science advances one funeral at a time. Max Planck _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-idot -- 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
participants (4)
-
Einar Nilsen-Nygaard (einarnn)
-
Ingo.Friese@telekom.de
-
j stollman
-
Salvatore D'Agostino