Hi Juergen, thanks for your response.
On 04/01/2014 01:41 PM, Juergen Schoenwaelder wrote: > On Mon, Mar 31, 2014 at 02:53:13PM +0200, Hannes Tschofenig wrote: >> Hi all, >> >> after I listened to Juergen's presentation in the CORE working group at >> the last IETF meeting about 'constrained management' I was wondering >> about the following aspect: >> >> More and more devices (specifically IoT devices) come with a built-in >> software update mechanism (even at different levels). For example, you >> can see firmware update mechanisms, the ability to update individual >> files (if there is a file system), or package managers being used. > > There is a wide range of different device classes. I do not believe > that package managers are generally available on all device classes. > In a nutshell, there are the really constrained devices (see LWIG > terminology) and then there are devices with sufficient resources to > run an embedded Linux or BSD kernels. A file system and package > managers sound to me you are assuming the later. There are certainly a range of devices. For that reason I have listed a number of techniques used by these devices to provide updates. Many Linux-based IoT devices use a form of package manager. These are more "high-end" devices. > >> The configuration data and the code is often treated in the same way and >> also updated using the same style (to better deal with the constrained >> nature of these devices). > > Reference? Thinking about some of the products I have seen in the wearable space I might be wrong since there you often have a firmware update mechanism for the core functionality (code & long-term configuration data) but then also a configuration mechanism for short-term data. Since it would require reverse engineering to really find out what these products are doing it raises the question about where interoperability is needed. Many of today's products show a pattern that is very close to what we described in Figure 2 of http://tools.ietf.org/html/draft-iab-smart-object-architecture-03. In that sense it does not really matter whether and how configuration data is attached to the code itself since it is proprietary anyway. > >> I am wondering what the role of traditional network management protocols >> actually is. >> >> Why would I add, let's say, SNMP to my IoT device to configure the >> device or to retrieve sensor information when I anyway have to provide a >> software update mechanism together with some application layer protocol >> (like CoAP)? > > What matters most is reuse of data models. How you ship the data > depends on many criteria. All I can say (since we did implement SNMP) > is that SNMP works reasonably well on constrained devices. Unless you do all your tasks on an embedded device with SNMP (or a similar protocol) it seems to be the wrong choice to me since you are adding one additional protocol to implement with functionality that overlaps the other protocol. You might have some experience that I have not yet understood though (which caused me to start a discussion about it). > But yes, if > you live in a CoAP world, you may prefer to ship data via CoAP (once > you have worked out the details). What would be a failure in my view > is to redo the data models. That's an interesting perspective. What data models from the network management community do you see most valuable? (Of course, I am not married to CoAP and there is a lot of HTTP usage out there as well. I have only seen one product that used SNMP in the lighting space and I was asking myself why didn't they use CoAP or HTTP.) Ciao Hannes > > /js >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
