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

Fred Baker <fred@cisco.com> Sun, 09 October 2011 22:01 UTC

Return-Path: <fred@cisco.com>
X-Original-To: smartobjectdir@ietfa.amsl.com
Delivered-To: smartobjectdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570A021F8997 for <smartobjectdir@ietfa.amsl.com>; Sun, 9 Oct 2011 15:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.893
X-Spam-Level:
X-Spam-Status: No, score=-101.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmaLmFg-fXrF for <smartobjectdir@ietfa.amsl.com>; Sun, 9 Oct 2011 15:01:01 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A8A9B21F853B for <smartobjectdir@ietf.org>; Sun, 9 Oct 2011 15:01:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=6263; q=dns/txt; s=iport; t=1318197661; x=1319407261; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=yO5ScidkwT1xP7itmmpPNUXUoVuA2eWQDE/JObMRx7c=; b=V9OwyyNF+AdP+MyYOI+WsGKmPF/VAOecwzTNlQr089Kr5PcDchgYWvHt e923UxxR0Hvb/G0uo/t3d4sMvIOJ6hbuDxxVcFBCnXk7kY6NyvSVmkK2l SFxZg61hsZUaS5Z5pYV5gha9dMAjn6c9uEEwg1o0ocPdr9lCpgsSRdmGi A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAE8Ykk6rRDoJ/2dsb2JhbAA5CagYgQWBUwEBAQMBEgEnPwULCxguVwYTFA6HXJhSAZ0ZhBWCTWEEk3eFKYxE
X-IronPort-AV: E=Sophos;i="4.68,513,1312156800"; d="scan'208";a="6828686"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 09 Oct 2011 22:01:01 +0000
Received: from Freds-Computer.local (sjc-vpn7-1782.cisco.com [10.21.150.246]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p99M10cs017188; Sun, 9 Oct 2011 22:01:00 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 09 Oct 2011 18:01:00 -0400
X-PGP-Universal: processed; by Freds-Computer.local on Sun, 09 Oct 2011 18:01:00 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <CAHxHggfyv-O3bqBqKq+p3qoBY2EOeTZrBryskf0OB+omKPEwfA@mail.gmail.com>
Date: Sun, 9 Oct 2011 18:00:50 -0400
Message-Id: <CD7C2110-45E1-4D72-B986-00A9EFFEFD52@cisco.com>
References: <B6C7A935-C40D-4E3E-B6C9-7179EDE0C99C@vigilsec.com> <8BE7D920-176C-4A16-AEB3-D525B6396060@cisco.com> <95201571-B862-4FAA-B3BA-76FE0E62F608@cisco.com> <DC512462-0FD5-40F0-B6A4-9F580133E3DE@cisco.com> <CAHxHggf53Veca_Sso3fy3o60URNb5eM1p2VqCa+3iiCgW=UjGw@mail.gmail.com> <D605DDB6-B09D-4A37-83C0-BC7663C2C0E9@cisco.com> <78B90A3F-91AC-4124-82F7-70162A442913@cisco.com> <CAHxHggfyv-O3bqBqKq+p3qoBY2EOeTZrBryskf0OB+omKPEwfA@mail.gmail.com>
To: Vint Cerf <vint@google.com>
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: smartobjectdir@ietf.org
Subject: Re: [smartobjectdir] "Management" vs "control and telemetry"
X-BeenThere: smartobjectdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <smartobjectdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smartobjectdir>, <mailto:smartobjectdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartobjectdir>
List-Post: <mailto:smartobjectdir@ietf.org>
List-Help: <mailto:smartobjectdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartobjectdir>, <mailto:smartobjectdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Oct 2011 22:01:02 -0000

:-)

On Oct 9, 2011, at 5:11 PM, Vint Cerf wrote:

> 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 <fred@cisco.com> 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.