Re: [smartobjectdir] "Management" vs "control and telemetry"
Vint Cerf <vint@google.com> Sun, 09 October 2011 21:11 UTC
Return-Path: <vint@google.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 1CD6221F86B3 for <smartobjectdir@ietfa.amsl.com>; Sun, 9 Oct 2011 14:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 1h8bpV-wFm0V for <smartobjectdir@ietfa.amsl.com>; Sun, 9 Oct 2011 14:11:25 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id EA25B21F85D1 for <smartobjectdir@ietf.org>; Sun, 9 Oct 2011 14:11:24 -0700 (PDT)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p99LBM4C001918 for <smartobjectdir@ietf.org>; Sun, 9 Oct 2011 14:11:22 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318194682; bh=x78UYS3INnG0G4sfM4zurFBOGRg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kFBg3LoicuOo+L/vwAAoDGiGuc+CTc6eEfm7kvt7l0nEKaXauH9tIG6nGQB8Byo/5 5q0ZhJJS1R/mQtyW19SDg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=SIWastegBFc4ba0VcHn6QlYTflz4Jq3rY7//ztCRW4lni2C/YqlcUIbnWxkB+kqMh GzQ8CqmEZr35Vcw181GMw==
Received: from iaen33 (iaen33.prod.google.com [10.12.165.33]) by wpaz5.hot.corp.google.com with ESMTP id p99LBLGV007228 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <smartobjectdir@ietf.org>; Sun, 9 Oct 2011 14:11:21 -0700
Received: by iaen33 with SMTP id n33so8384335iae.10 for <smartobjectdir@ietf.org>; Sun, 09 Oct 2011 14:11:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OeSReq9YZmyGvmn6NzqdvgV9hsbhzoS1hOnWLQ5LwrA=; b=pRaNRJnYdOc3DJbpJtCxOcezJam9hXrz19JpnrYJUTx4KpXNukDq5qA6Z8ANFu2lcL 6tEN48Tp3LGUdW8iAZhw==
Received: by 10.231.5.225 with SMTP id 33mr7213693ibw.3.1318194681000; Sun, 09 Oct 2011 14:11:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.5.225 with SMTP id 33mr7213685ibw.3.1318194680829; Sun, 09 Oct 2011 14:11:20 -0700 (PDT)
Received: by 10.231.30.202 with HTTP; Sun, 9 Oct 2011 14:11:20 -0700 (PDT)
In-Reply-To: <78B90A3F-91AC-4124-82F7-70162A442913@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>
Date: Sun, 09 Oct 2011 17:11:20 -0400
Message-ID: <CAHxHggfyv-O3bqBqKq+p3qoBY2EOeTZrBryskf0OB+omKPEwfA@mail.gmail.com>
From: Vint Cerf <vint@google.com>
To: Fred Baker <fred@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
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 21:11:26 -0000
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.
- [smartobjectdir] Charter Russ Housley
- [smartobjectdir] FW: Charter Ersue, Mehmet (NSN - DE/Munich)
- Re: [smartobjectdir] FW: Charter Romascanu, Dan (Dan)
- Re: [smartobjectdir] Charter Fred Baker
- Re: [smartobjectdir] Charter JP Vasseur
- Re: [smartobjectdir] Charter Fred Baker
- Re: [smartobjectdir] Charter Vint Cerf
- Re: [smartobjectdir] Charter Romascanu, Dan (Dan)
- Re: [smartobjectdir] Charter Fred Baker
- Re: [smartobjectdir] Charter Fred Baker
- [smartobjectdir] "Management" vs "control and tel… Fred Baker
- Re: [smartobjectdir] "Management" vs "control and… Vint Cerf
- Re: [smartobjectdir] "Management" vs "control and… Fred Baker
- Re: [smartobjectdir] "Management" vs "control and… Romascanu, Dan (Dan)
- [smartobjectdir] meeting? Jari Arkko
- Re: [smartobjectdir] meeting? Fred Baker
- Re: [smartobjectdir] meeting? Ersue, Mehmet (NSN - DE/Munich)
- Re: [smartobjectdir] meeting? Romascanu, Dan (Dan)
- Re: [smartobjectdir] meeting? Peter Saint-Andre
- Re: [smartobjectdir] meeting? Romascanu, Dan (Dan)
- Re: [smartobjectdir] meeting? Peter Saint-Andre
- Re: [smartobjectdir] meeting? Polk, William T.
- Re: [smartobjectdir] meeting? Zach Shelby
- Re: [smartobjectdir] meeting? Joe Touch
- Re: [smartobjectdir] meeting? Richard Shockey
- Re: [smartobjectdir] meeting? Jari Arkko
- Re: [smartobjectdir] meeting? Fred Baker
- Re: [smartobjectdir] meeting? Ersue, Mehmet (NSN - DE/Munich)
- Re: [smartobjectdir] meeting? Fred Baker
- Re: [smartobjectdir] meeting? Fred Baker
- Re: [smartobjectdir] meeting? Polk, William T.
- [smartobjectdir] 83 SOD - Breakfast ? Ersue, Mehmet (NSN - DE/Munich)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Fred Baker
- Re: [smartobjectdir] 83 SOD - Breakfast ? Ersue, Mehmet (NSN - DE/Munich)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Fred Baker
- Re: [smartobjectdir] 83 SOD - Breakfast ? Polk, William T.
- Re: [smartobjectdir] 83 SOD - Breakfast ? Ralph Droms
- Re: [smartobjectdir] 83 SOD - Breakfast ? Romascanu, Dan (Dan)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Ersue, Mehmet (NSN - DE/Munich)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Fred Baker
- Re: [smartobjectdir] 83 SOD - Breakfast ? Ersue, Mehmet (NSN - DE/Munich)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Fred Baker
- Re: [smartobjectdir] 83 SOD - Breakfast ? Romascanu, Dan (Dan)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Ersue, Mehmet (NSN - DE/Munich)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Peter Saint-Andre
- Re: [smartobjectdir] 83 SOD - Breakfast ? Ralph Droms
- Re: [smartobjectdir] 83 SOD - Breakfast ? Geoff Mulligan (IETF)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Fred Baker
- Re: [smartobjectdir] 83 SOD - Breakfast ? Romascanu, Dan (Dan)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Ersue, Mehmet (NSN - DE/Munich)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Ralph Droms
- Re: [smartobjectdir] 83 SOD - Breakfast ? Polk, William T.
- Re: [smartobjectdir] 83 SOD - Breakfast ? Jari Arkko
- Re: [smartobjectdir] 83 SOD - Breakfast ? Fred Baker
- Re: [smartobjectdir] 83 SOD - Breakfast ? Romascanu, Dan (Dan)
- Re: [smartobjectdir] 83 SOD - Breakfast ? Ersue, Mehmet (NSN - DE/Munich)