Re: [OPSAWG] network management data models - a rewrite
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 28 November 2011 14:45 UTC
Return-Path: <dromasca@avaya.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6921F8BF7 for <opsawg@ietfa.amsl.com>; Mon, 28 Nov 2011 06:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.998
X-Spam-Level:
X-Spam-Status: No, score=-100.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 svibceJM7mQD for <opsawg@ietfa.amsl.com>; Mon, 28 Nov 2011 06:45:47 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id E0C4A21F87D9 for <opsawg@ietf.org>; Mon, 28 Nov 2011 06:45:46 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAF2d007GmAcF/2dsb2JhbABDgk2oMYEFgXIBAQEBAxIKEQNZAgEIDQEHDQYMCwEGAUURAQEEARIIGqMHm0WJf2MEmiqMLA
X-IronPort-AV: E=Sophos; i="4.69,584,1315195200"; d="scan'208,217"; a="316737004"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Nov 2011 09:45:44 -0500
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Nov 2011 09:43:50 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCADDC.67AA0911"
Date: Mon, 28 Nov 2011 15:45:42 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0405AD5564@307622ANEX5.global.avaya.com>
In-Reply-To: <4ECFC961.4030708@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPSAWG] network management data models - a rewrite
Thread-Index: AcyrlLblVpLCzC9wTsi6kvLSPctYIgCRzqrA
References: <20111117041857.GA25801@elstar.local> <4ECFC961.4030708@cisco.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Benoit Claise <bclaise@cisco.com>, opsawg@ietf.org
Subject: Re: [OPSAWG] network management data models - a rewrite
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2011 14:45:48 -0000
Hi, One comment on Benoit's comment: From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise The second important infrastructure data model is defined in the Entity MIB [RFC4133]. It exports the containment hierarchy of the physical entities (slots, modules, ports) that make up a networking device and as such it is a key data model for inventory management. Physical entities can have pointers to other data models that provide more specific information about a physical entity (e.g. physical ports usually point to the related network interface). Entity MIB extensions exist for physical sensors such as temperature sensors embedded on line cards or sensors that report fan rotation speeds [RFC3433]. BC> I would not mention this ENTITY-MIB extension about sensor. To the audience, it might seem that we have master the Internet of Things with SNMP, which is not correct at all! Another extension models states and alarms of physical entities [RFC4268]. Some vendors have extended the basic Entity MIB with several proprietary data models. [[DR]] I respectfully disagree with Benoit's comment. There is not claim that 'we have mastered the IoT management', just an example of the way the Entity MIB can be used and extended to represent information from physical sensors, followed by another example about alarms. I would rather leave them as written by Juergen. Dan (speaking as contributor)
- [OPSAWG] network management data models - a rewri… Juergen Schoenwaelder
- Re: [OPSAWG] network management data models - a r… Romascanu, Dan (Dan)
- Re: [OPSAWG] network management data models - a r… Ersue, Mehmet (NSN - DE/Munich)
- Re: [OPSAWG] network management data models - a r… Christopher LILJENSTOLPE
- Re: [OPSAWG] network management data models - a r… Juergen Schoenwaelder
- Re: [OPSAWG] network management data models - a r… Juergen Schoenwaelder
- Re: [OPSAWG] network management data models - a r… Romascanu, Dan (Dan)
- Re: [OPSAWG] network management data models - a r… Ersue, Mehmet (NSN - DE/Munich)
- Re: [OPSAWG] network management data models - a r… Bert Wijnen (IETF)
- Re: [OPSAWG] network management data models - a r… Juergen Schoenwaelder
- Re: [OPSAWG] network management data models - a r… Randy Presuhn
- Re: [OPSAWG] network management data models - a r… Ersue, Mehmet (NSN - DE/Munich)
- Re: [OPSAWG] network management data models - a r… Benoit Claise
- Re: [OPSAWG] network management data models - a r… t.petch
- Re: [OPSAWG] network management data models - a r… Benoit Claise
- Re: [OPSAWG] network management data models - a r… Juergen Schoenwaelder
- Re: [OPSAWG] network management data models - a r… Benoit Claise
- Re: [OPSAWG] network management data models - a r… Romascanu, Dan (Dan)