Hi Hannes, concerning "motes", "class 0", or whatever we want to call such devices: indeed, not sure how we should relate with such devices in the document.
Do we care to define a "new" category of devices on which no protocol will run that we IETFers specify (e.g. BLE beacons)? I'd say: no, unless it is deemed useful to distinguish from other types of devices that are expected to run IETF protocols in practice. Emmanuel On Wed, Feb 1, 2017 at 3:05 PM, Hannes Tschofenig <[email protected] > wrote: > Hi Carsten and Co-Authors, > > thanks for working on the document. > > What I am missing is a discussion (which does not need to end in the > final version of the document) on what functionality you consider to be > included in, for example, the class 1 device. > > I agree with Emmanuel regarding the difference between the device that > run a RTOS (or special IoT-designed OS) and the devices that run a > general purpose OS, like Linux. This is also a differentiation we make, > as you know. > > Ciao > Hannes > > PS: I am not sure about the "motes". Are you talking about BLE beacons? > > On 02/01/2017 10:57 AM, Emmanuel Baccelli wrote: > > Hi Carsten, > > > > thanks for the initiative. I support it! > > > > Coarsly, from the software perspective, there are 3 classes of devices: > > > > - "motes" with fixed, simplistic functionality in software, on which > > resources are so constrained that an operating system and (secure) > > software updates do not make sense. > > > > - "low-end IoT devices" with more resources and more functionalities in > > software, which run an OS but cannot run generic operating systems such > > as Linux or equivalents/derivatives, and hence run IoT-specific > > operating systems such as RIOT, Contiki etc. > > > > - "high-end IoT devices" which have enough resources so that they can > > run generic operating systems such as Linux or equivalents/derivatives. > > > > Each category presents specific challenges, but the "low-end IoT device" > > category is the one where the most fundamental progress is expected, and > > achievable. > > By that I mean that we can hope to transform low-end IoT devices into > > "standard" Internet citizens if we do things right. > > On that level, there is no hope for motes and, on the other hand, > > high-end IoT devices are already Internet citizens. > > > > From that perspective, I'm not sure defining a "Class 7" would be useful. > > I'm not even sure if defining a "Class 0" is so useful either in the end > > -- if we have no hope that such devices will become "standard" Internet > > citizens. > > > > Best, > > > > Emmanuel > > > > > > On Wed, Feb 1, 2017 at 4:01 AM, Christian Groves <[email protected] > > <mailto:[email protected]>> wrote: > > > > I did a quick read of the draft and to me its not clear what the > > goal of clause 5.2 "Class of Internet Integration" is. > > > > The table talks about internet technologies, the text makes > > reference to communications patterns (e.g. device-to-cloud) whereas > > the section is on integration. It also lists I9 which seems to > > suggest there will be "degrees" on classes of integration between I1 > > and I9. > > > > So is the aim to only have 3 types? e.g. > > > > Device Internal IP usage - IP Interoperability not an issue. > > > > Device to Provider Server - IP Interoperability within a service > > provider. > > > > Device to Any - IP interoperability required between multiple > > service providers. > > > > Or to have something more specific to IP listing what parts of the > > IP suite are supported? > > > > Regards, Christian > > > > > > > > > > On 26/01/2017 6:57 PM, Carsten Bormann wrote: > > > > On 26 Jan 2017, at 00:38, Carsten Bormann <[email protected] > > <mailto:[email protected]>> wrote: > > > > Sure. We started that discussion a few IETFs ago and have a > > bis draft out at > > draft-bormann-lwig-7228bis. > > > > … and the editors’ draft is now at: > > > > https://github.com/lwig-wg/terminology > > <https://github.com/lwig-wg/terminology> > > and > > https://lwig-wg.github.io/terminology/ > > <https://lwig-wg.github.io/terminology/> > > > > Issues and pull requests are welcome. > > (Please see > > https://github.com/lwig-wg/terminology/blob/master/ > CONTRIBUTING.md > > <https://github.com/lwig-wg/terminology/blob/master/ > CONTRIBUTING.md> > > ). > > > > (The proposed bis document is an individual submission at this > > point; we still put it up under the “lwig-wg” organization as > > there appears to be some interest.) > > > > Grüße, Carsten > > > > _______________________________________________ > > Lwip mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lwip > > <https://www.ietf.org/mailman/listinfo/lwip> > > > > > > _______________________________________________ > > Lwip mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lwip > > <https://www.ietf.org/mailman/listinfo/lwip> > > > > > > > > > > _______________________________________________ > > Lwip mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lwip > > > >
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
