Subject: Re: [smartobjectdir] Charter

From: Fred Baker <[email-masked]>
Date: Sat, 8 Oct 2011 11:49:09 -0400

On Sep 26, 2011, at 11:31 AM, Russ Housley wrote:

> http://www.ietf.org/iesg/directorate/smart-object.html
> 
> The name of the directorate was changed.  How should the charter change to match?

A question I would ask is how "Smart Objects" differs from "Internet of Things". The latter is a content-free marketing term that was originally coined by the ITU to refer to RFID technologies and is now widely used to refer to various aspects of distributed identification, telemetry, and control technologies. To me, "Smart Objects" is a better term for the same thing.

The Smart Grid is a special case of the use of distributed telemetry and control technologies. Note that I left out identification.

My suggestion for an updated charter; everyone please comment:

Advice and Coordination

Reports to the General Area Director (currently the IETF Chair), and provides coordination between the IETF and others working on Smart Power.

Charter

There are many initiatives related to distributed identification, telemetry, and control technologies; one of these is the Smart Grid, but more generally this includes industrial automation and any application of networked sensors and control elements. The key component is the use of intelligent monitoring and control in a function for which humans set policy but are not directly involved in most specific decisions, and uses two-way and/or multicast communications to reduce cost, improve reliability, and increase transparency.

The Smart Object Directorate provides review and coordination on the use of Internet protocols to provide communications in networks performing distributed identification, telemetry, and control. The goal is to point other organizations to relevant IETF documents and provide review of documents from other organizations that depend upon Internet protocols. If the directorate identifies a gap that requires new work in the IETF, the directorate will raise the issue with the IESG. The directorate will not develop new protocols or enhance existing ones. This review and coordination will require expertise from all of the Areas in the IETF.

Mail List

The Smart Power Directorate can be reached at [email-masked].

The [email-masked] mail list is available for open
discussion of topics related to Smart Power.

---

From: JP Vasseur <[email-masked]>
Date: Sun, 9 Oct 2011 11:27:20 +0200

Hi Fred,

The short story is that I fully agree with your comment. I much prefer the term IP Smart Object networks than IoT;
that being said, we know the power of Marketing, the word is out and now widely used. Technically speaking, IP
smart object networks is the appropriate one; I can tell you that when I publish last year a book on the subject 
matter, I did struggle finding a good title, and we ended up with "Interconnecting smart objects with IP: The next 
Internet".

There are other terms in us, 6lowpan (sometimes used to refer to IP smart object network, although it does point
out to a specific set of technologies, LLN (Low power and Lossy Networks, …).

Thanks for updating the charter, I would just propose to replace "telemetry and control" by "sensing and actuating".

Thanks.

JP.

On Oct 8, 2011, at 5:49 PM, Fred Baker (fred) wrote:

> _______________________________________________
> smartobjectdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smartobjectdir
>

---

From: Fred Baker <[email-masked]>
Date: Sun, 9 Oct 2011 07:33:51 -0400

> out to a specific set of technologies, LLN (Low power and Lossy Networks, …).

I'll argue that those refer to a specific category of such networks, one using IEEE 802.15.4; there are a number of other link layer technologies in use that don't necessarily have the same characteristics and for which 6lowpan isn't obviously relevant. I see tying it to a specific MAC/PHY as a trap. The important thing for us is that IP (of which 6lowpan is a compression) transcends the MAC/PHY in use and potentially connects it to networks composed of more traditional technologies such as IEEE 802.3.

> Thanks for updating the charter, I would just propose to replace "telemetry and control" by "sensing and actuating".

Willing enough, although I again see a potential trap. When we talk about industrial automation, management of water displays like the Bellagio Fountains, and so on, "actuating" is a great word in it primary meaning of "cause (a machine or device) to operate"; that goes straight back to Latin. That said, not every "action" in a network is the movement of a device; it also might change the thresholds in the sensor or do some other non-physical thing - that for which we might use the term "configuration". I talk about "control", because it includes both. Similarly, sensing to me is somewhat limited; the obvious meaning would be to somehow measure some physical thing like movement or temperature. In a building control system, it the actions might also include reporting state, such as "you announced that lamp X should change state to 'on'; lamp X is now 'on'". In space communications, the paradigm has been for some time "command and telemetry"; someone tells a satellite or space probe to do something, such as turn a camera in a specific direction, and the continuous stream of data from the satellite/probe might include the direction the camera is pointed. We observe, eventually, that the command has had a certain effect because we see the change in the telemetry it reports. Hence I use the terms "control" and "telemetry", as they include "sensing" and "actuating" but are not limited to their meanings.

Other opinions?

---

From: Vint Cerf <[email-masked]>
Date: Sun, 9 Oct 2011 08:23:29 -0400

some people might argue that "management" captures both telemetry and control...

v

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 9 Oct 2011 20:22:24 +0200

Looks OK to me. 

In a couple of places you left Smart Power. Is this intentional, or
rather s/Smart Power/Smart Objects/? 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:smartobjectdir-
> [email-masked]] On Behalf Of Fred Baker
> Sent: Saturday, October 08, 2011 5:49 PM
> To: [email-masked]
> Subject: Re: [smartobjectdir] Charter
> 
> 
> A question I would ask is how "Smart Objects" differs from "Internet
of
> Things". The latter is a content-free marketing term that was
> originally coined by the ITU to refer to RFID technologies and is now
> widely used to refer to various aspects of distributed identification,
> telemetry, and control technologies. To me, "Smart Objects" is a
better
> term for the same thing.
> 
> The Smart Grid is a special case of the use of distributed telemetry
> and control technologies. Note that I left out identification.
> 
> Reports to the General Area Director (currently the IETF Chair), and
> provides coordination between the IETF and others working on Smart
> Power.
> 
> Charter
> 
> There are many initiatives related to distributed identification,
> telemetry, and control technologies; one of these is the Smart Grid,
> but more generally this includes industrial automation and any
> application of networked sensors and control elements. The key
> component is the use of intelligent monitoring and control in a
> function for which humans set policy but are not directly involved in
> most specific decisions, and uses two-way and/or multicast
> communications to reduce cost, improve reliability, and increase
> transparency.
> 
> The Smart Object Directorate provides review and coordination on the
> use of Internet protocols to provide communications in networks
> performing distributed identification, telemetry, and control. The
goal
> is to point other organizations to relevant IETF documents and provide
> review of documents from other organizations that depend upon Internet
> protocols. If the directorate identifies a gap that requires new work
> in the IETF, the directorate will raise the issue with the IESG. The
> directorate will not develop new protocols or enhance existing ones.
> This review and coordination will require expertise from all of the
> Areas in the IETF.
> 
> Mail List
>

---

From: Fred Baker <[email-masked]>
Date: Sun, 9 Oct 2011 16:21:41 -0400

> some people might argue that "management" captures both telemetry and control...

Other people would remember that the M in SNMP stands for Management, and in that case it only means Monitoring :-)

---

From: Fred Baker <[email-masked]>
Date: Sun, 9 Oct 2011 16:22:10 -0400

yes, I meant the substitution. oops.

---

From: Fred Baker <[email-masked]>
Date: Sun, 9 Oct 2011 17:04:16 -0400

Let me step out on a limb here, one which Ersue and Dan will very quickly try to saw off. I'm of the opinion that our "Management" protocols, SNMP and NetConf, are very poorly suited to the world of Smart Objects, and that if we simply describe this as "management" the Internet Community will dismiss it as a previously solved problem.

Let me give you two relatively simple examples.

You will recall that when we were developing SNMP, we talked a lot about the Internet Toaster, and that Epilogue developed a Toaster MIB (which can still be found of you ask Google) to demonstrate the operation of it. The premise of the Toaster MIB is that there is some central controller; someone places bread into the toaster, wanders off to the toaster controller, and the toaster controller might do a SET to put actuate the toaster, and then might monitor is SNMP objects to see how things were going.

The simplest example is what I call the Internet Light Bulb, something on which I have an internet draft half written. Let's imagine I have a single light bulb (or a multicast group full of lightbulbs, but for the moment it is one bulb) that is operated by two (or more) switches. Electrically, that's not hard -

                            ,-.
         +-----|||---------(   )----------------+
         |                  `-'                 |
         |      /-------------------------      |
         +-----/                           /----+
                 -------------------------/

I have two switches, each with two positions. If they are both in the same position current flows, and if they are in different positions current doesn't flow.

In a building control environment (Echelon makes this product, and I am describing their implementation), each switch has an identity and each light bulb has an identity. When someone throws a switch, the switch announces "I am X, and I command Y to go to the state 'ON'". Y receives the command, verifies that it is still Y (all the other light bulbs receive it too, and note that they are not Y), verifies that X is authorized to give it that command, and turns itself on. It then announces "I am Y, and I am in the state 'ON'". Each other switch X' receives the announcement, decides whether it cares what state Y is in, and if so records that Y is in fact on. Subsequently, if someone else tells another switch to turn Y on, it will do nothing; Y is already on. But if someone throws any of the switches to turn Y off, the switch will say "I am X', and I think Y should be off".

Here's a slightly more complex example: a thermostat. Somewhere, there is, let's imagine, an energy management system. It is being told by the utility that between this time and that the price is HIGH and is otherwise LOW. It has a policy that includes telling the thermostat (at times this and that) to change its thresholds. The thermostat, in turn, has two thresholds. If the temperature falls below one temperature it will turn on the heat, and if the temperature goes above that it will turn off the heat. If the temperature rises above a second threshold it will turn on the air conditioning, and if it falls below, it will turn the air conditioning off. When the price is LOW, the two thresholds might be at 71 and 73 degrees Fahrenheit respectively; when the price is HIGH, they might be at 68 and 78. So the EMS might set the thresholds from time to time using whatever protocol it likes, perhaps NetConf; when the thermostat observes the temperature crossing one threshold or the other, it could report that to the EMS and let the EMS send a command to the heater or the air conditioner; more likely, it will announce that it thinks the temperature is "Cold", "Nice", or "Hot", and the heater and the air conditioner will observe that their policy is that when it is "Cold" or "Hot" (respectively) it policy (controlled by the EMS) is to turn itself on, and when it is "Nice" to turn itself off.

The information that needs to be exchanged, in each case, is the source's identity ("I am X"), the target's identity ("I think that Y..."), a variable name ("on/off status"), and a value ("on"). It also needs to announce a method (it is reporting current state or it is requesting a state change), and it needs whatever information is necessary to prove its identity. Current equipment used in embedded systems - the stuff our proposed system is trying to displace - does this (Echelon's equipment) in a total of 11K ROM and 2-4K RAM for the entire system, never mind the management interpreter. I know of no SNMP implementation that can do that, nor any XML implementation, and they certainly don't use one protocol to read information and another to write it. So for the purpose at hand, protocols I am seeing presented as The One True Religion have implementers of existing commercial systems telling me while giggling in their sleaves that they have "no fear of real competition" from an IETF/IRTF implementation. That's quote/unquote.

I could imagine the thing being in JavaScript Object Notation, a notation designed along the lines of RFC 5545, or a variety of other approaches. My point is S-I-M-P-L-E, and designed to enable conversations among actors in the game but without religious dogma about who is a controller and who is controlled. They are actors with state, and an actor might be a controller or a controllee in subsequent milliseconds.

---

From: Vint Cerf <[email-masked]>
Date: Sun, 9 Oct 2011 17:11:20 -0400

If everyone interpreted my "management" suggestion as identical to
SNMP, give me a break!

I was commenting on terminology and not invoking any particular protocol.

sheesh!

v

On 10/9/11, Fred Baker <[email-masked]> wrote:
> Let me step out on a limb here, one which Ersue and Dan will very quickly
> try to saw off. I'm of the opinion that our "Management" protocols, SNMP and
> NetConf, are very poorly suited to the world of Smart Objects, and that if
> we simply describe this as "management" the Internet Community will dismiss
> it as a previously solved problem.
>
> You will recall that when we were developing SNMP, we talked a lot about the
> Internet Toaster, and that Epilogue developed a Toaster MIB (which can still
> be found of you ask Google) to demonstrate the operation of it. The premise
> of the Toaster MIB is that there is some central controller; someone places
> bread into the toaster, wanders off to the toaster controller, and the
> toaster controller might do a SET to put actuate the toaster, and then might
> monitor is SNMP objects to see how things were going.
>
> The simplest example is what I call the Internet Light Bulb, something on
> which I have an internet draft half written. Let's imagine I have a single
> light bulb (or a multicast group full of lightbulbs, but for the moment it
> is one bulb) that is operated by two (or more) switches. Electrically,
> that's not hard -
>
>                             ,-.
> I have two switches, each with two positions. If they are both in the same
> position current flows, and if they are in different positions current
> doesn't flow.
>
> In a building control environment (Echelon makes this product, and I am
> describing their implementation), each switch has an identity and each light
> bulb has an identity. When someone throws a switch, the switch announces "I
> am X, and I command Y to go to the state 'ON'". Y receives the command,
> verifies that it is still Y (all the other light bulbs receive it too, and
> note that they are not Y), verifies that X is authorized to give it that
> command, and turns itself on. It then announces "I am Y, and I am in the
> state 'ON'". Each other switch X' receives the announcement, decides whether
> it cares what state Y is in, and if so records that Y is in fact on.
> Subsequently, if someone else tells another switch to turn Y on, it will do
> nothing; Y is already on. But if someone throws any of the switches to turn
> Y off, the switch will say "I am X', and I think Y should be off".
>
> Here's a slightly more complex example: a thermostat. Somewhere, there is,
> let's imagine, an energy management system. It is being told by the utility
> that between this time and that the price is HIGH and is otherwise LOW. It
> has a policy that includes telling the thermostat (at times this and that)
> to change its thresholds. The thermostat, in turn, has two thresholds. If
> the temperature falls below one temperature it will turn on the heat, and if
> the temperature goes above that it will turn off the heat. If the
> temperature rises above a second threshold it will turn on the air
> conditioning, and if it falls below, it will turn the air conditioning off.
> When the price is LOW, the two thresholds might be at 71 and 73 degrees
> Fahrenheit respectively; when the price is HIGH, they might be at 68 and 78.
> So the EMS might set the thresholds from time to time using whatever
> protocol it likes, perhaps NetConf; when the thermostat observes the
> temperature crossing one threshold or the other, it could report that to the
> EMS and let the EMS send a command to the heater or the air conditioner;
> more likely, it will announce that it thinks the temperature is "Cold",
> "Nice", or "Hot", and the heater and the air conditioner will observe that
> their policy is that when it is "Cold" or "Hot" (respectively) it policy
> (controlled by the EMS) is to turn itself on, and when it is "Nice" to turn
> itself off.
>
> The information that needs to be exchanged, in each case, is the source's
> identity ("I am X"), the target's identity ("I think that Y..."), a variable
> name ("on/off status"), and a value ("on"). It also needs to announce a
> method (it is reporting current state or it is requesting a state change),
> and it needs whatever information is necessary to prove its identity.
> Current equipment used in embedded systems - the stuff our proposed system
> is trying to displace - does this (Echelon's equipment) in a total of 11K
> ROM and 2-4K RAM for the entire system, never mind the management
> interpreter. I know of no SNMP implementation that can do that, nor any XML
> implementation, and they certainly don't use one protocol to read
> information and another to write it. So for the purpose at hand, protocols I
> am seeing presented as The One True Religion have implementers of existing
> commercial systems telling me while giggling in their sleaves that they have
> "no fear of real competition" from an IETF/IRTF implementation. That's
> quote/unquote.
>
> I could imagine the thing being in JavaScript Object Notation, a notation
> designed along the lines of RFC 5545, or a variety of other approaches. My
> point is S-I-M-P-L-E, and designed to enable conversations among actors in
> the game but without religious dogma about who is a controller and who is
> controlled. They are actors with state, and an actor might be a controller
> or a controllee in subsequent milliseconds.

---

From: Fred Baker <[email-masked]>
Date: Sun, 9 Oct 2011 18:00:50 -0400

:-)

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 10 Oct 2011 12:52:18 +0200

Hi,

I do not think that management equals SNMP and Netconf
I do not think that management equals the manager-agents architecture
I do not think that management equals control and telemetry

We need to think with fresh and open minds starting with the use cases
about how smart objects exchange status and measured parameters
information, and how they need to behave from a control plane point of
view in order to meet the requirements of a smart system. 

Then we can make an assessment of what of the management protocols and
data models developed (in the IETF and elsewhere) in the two decades of
network management experience in the Internet can be re-used and what
needs new development. 

Dan

> Sent: Sunday, October 09, 2011 11:04 PM
> To: Vint Cerf
> Cc: [email-masked]
> Subject: [smartobjectdir] "Management" vs "control and telemetry"
> 
> Let me step out on a limb here, one which Ersue and Dan will very
> quickly try to saw off. I'm of the opinion that our "Management"
> protocols, SNMP and NetConf, are very poorly suited to the world of
> Smart Objects, and that if we simply describe this as "management" the
> Internet Community will dismiss it as a previously solved problem.
> 
> You will recall that when we were developing SNMP, we talked a lot
> about the Internet Toaster, and that Epilogue developed a Toaster MIB
> (which can still be found of you ask Google) to demonstrate the
> operation of it. The premise of the Toaster MIB is that there is some
> central controller; someone places bread into the toaster, wanders off
> to the toaster controller, and the toaster controller might do a SET
to
> put actuate the toaster, and then might monitor is SNMP objects to see
> how things were going.
> 
> The simplest example is what I call the Internet Light Bulb, something
> on which I have an internet draft half written. Let's imagine I have a
> single light bulb (or a multicast group full of lightbulbs, but for
the
> moment it is one bulb) that is operated by two (or more) switches.
> Electrically, that's not hard -
> 
>                             ,-.
> I have two switches, each with two positions. If they are both in the
> same position current flows, and if they are in different positions
> current doesn't flow.
> 
> describing their implementation), each switch has an identity and each
> light bulb has an identity. When someone throws a switch, the switch
> announces "I am X, and I command Y to go to the state 'ON'". Y
receives
> the command, verifies that it is still Y (all the other light bulbs
> receive it too, and note that they are not Y), verifies that X is
> authorized to give it that command, and turns itself on. It then
> announces "I am Y, and I am in the state 'ON'". Each other switch X'
> receives the announcement, decides whether it cares what state Y is
in,
> and if so records that Y is in fact on. Subsequently, if someone else
> tells another switch to turn Y on, it will do nothing; Y is already
on.
> But if someone throws any of the switches to turn Y off, the switch
> will say "I am X', and I think Y should be off".
> 
> Here's a slightly more complex example: a thermostat. Somewhere, there
> is, let's imagine, an energy management system. It is being told by
the
> utility that between this time and that the price is HIGH and is
> otherwise LOW. It has a policy that includes telling the thermostat
(at
> times this and that) to change its thresholds. The thermostat, in
turn,
> has two thresholds. If the temperature falls below one temperature it
> will turn on the heat, and if the temperature goes above that it will
> turn off the heat. If the temperature rises above a second threshold
it
> will turn on the air conditioning, and if it falls below, it will turn
> the air conditioning off. When the price is LOW, the two thresholds
> might be at 71 and 73 degrees Fahrenheit respectively; when the price
> is HIGH, they might be at 68 and 78. So the EMS might set the
> thresholds from time to time using whatever protocol it likes, perhaps
> NetConf; when the thermostat observes the temperature crossing one
> threshold or the
>  other, it could report that to the EMS and let the EMS send a command
> to the heater or the air conditioner; more likely, it will announce
> that it thinks the temperature is "Cold", "Nice", or "Hot", and the
> heater and the air conditioner will observe that their policy is that
> when it is "Cold" or "Hot" (respectively) it policy (controlled by the
> EMS) is to turn itself on, and when it is "Nice" to turn itself off.
> 
> The information that needs to be exchanged, in each case, is the
> source's identity ("I am X"), the target's identity ("I think that
> Y..."), a variable name ("on/off status"), and a value ("on"). It also
> needs to announce a method (it is reporting current state or it is
> requesting a state change), and it needs whatever information is
> necessary to prove its identity. Current equipment used in embedded
> systems - the stuff our proposed system is trying to displace - does
> this (Echelon's equipment) in a total of 11K ROM and 2-4K RAM for the
> entire system, never mind the management interpreter. I know of no
SNMP
> implementation that can do that, nor any XML implementation, and they
> certainly don't use one protocol to read information and another to
> write it. So for the purpose at hand, protocols I am seeing presented
> as The One True Religion have implementers of existing commercial
> systems telling me while giggling in their sleaves that they have "no
> fear of real competition" from a
>  n IETF/IRTF implementation. That's quote/unquote.
> 
> I could imagine the thing being in JavaScript Object Notation, a
> notation designed along the lines of RFC 5545, or a variety of other
> approaches. My point is S-I-M-P-L-E, and designed to enable
> conversations among actors in the game but without religious dogma
> about who is a controller and who is controlled. They are actors with
> state, and an actor might be a controller or a controllee in
subsequent
> milliseconds.