Re: [smartobjectdir] "Management" vs "control and telemetry"

[Vint Cerf <[e-mail]>]

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 <[e-mail]> 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.
>
> 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.