Re: [Lwip] Discussion about IoT Device Classes

[Emmanuel Baccelli <[e-mail]>]

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 <[e-mail]
> 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 <[e-mail]
> > <mailto:[e-mail]>> 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 <[e-mail]
> >         <mailto:[e-mail]>> 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
> >         [e-mail] <mailto:[e-mail]>
> >         https://www.ietf.org/mailman/listinfo/lwip
> >         <https://www.ietf.org/mailman/listinfo/lwip>
> >
> >
> >     _______________________________________________
> >     Lwip mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/lwip
> >     <https://www.ietf.org/mailman/listinfo/lwip>
> >
> >
> >
> >
> > _______________________________________________
> > Lwip mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lwip
> >
>
>