Re: [OPSAWG] network management data models - a rewrite

"t.petch" <ietfc@btconnect.com> Thu, 24 November 2011 10:38 UTC

Return-Path: <ietfc@btconnect.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 34BFB21F8C35 for <opsawg@ietfa.amsl.com>; Thu, 24 Nov 2011 02:38:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599]
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 UvMGXDIWi3Rt for <opsawg@ietfa.amsl.com>; Thu, 24 Nov 2011 02:38:34 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDE221F8C04 for <opsawg@ietf.org>; Thu, 24 Nov 2011 02:38:33 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2bthomr13.btconnect.com with SMTP id FHA89066; Thu, 24 Nov 2011 10:38:24 +0000 (GMT)
Message-ID: <009601ccaa8d$162780a0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, opsawg@ietf.org
References: <20111117041857.GA25801@elstar.local> <EDC652A26FB23C4EB6384A4584434A0405297F01@307622ANEX5.global.avaya.com>
Date: Thu, 24 Nov 2011 10:40:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4ECE1E9E.00AA, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.24.93016:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_CONTACT_NUM, __CP_URI_IN_BODY, __C230066_P5, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4ECE1EA2.0165, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
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: Thu, 24 Nov 2011 10:38:35 -0000

----- Original Message -----
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>;
<opsawg@ietf.org>
Sent: Thursday, November 17, 2011 7:05 AM
>
> It's not only Mehmet and Benoit, it's also me (as contributor and AD),
> and at least one position expressed in the meeting and also the silent
> majority in the WG meeting (to be confirmed on the list) that agree with
> us or do not care. You missed I think that part of the OPSAWG meeting,
> but what was said and agreed I think (pending on list confirmation) is
> that the goal of the document or one of its principal goals is to
> provide a view of the IETF data models for NM for external SDOs.

Mmmm

Looking at the minutes of the meeting, I would not have known that that was the
outcome, but no matter.

Writing this doubtless debars me from being in the silent majority, but I do
think that FCAPS should be in, as the least bad way of surveying the subject.  I
started off with a seven topic structure of management, saw that expand to ten
and shrink to six and three.  Any one would do, but we do need something in that
space; FCAPS seems the most likely to be understood.

By contrast, saying that IETF MIB modules are not like that is an
'implementation detail'.  It is how the IETF has chosen to implement its design
in the problem space, and omitting the 'big picture' of the problem space can
only reinforce the view that the IETF is something of an oddball.

In passing, you could do with a reference for [FCAPS].

Tom Petch



Many of
> those look at management apps via a FCAPS view, and providing both views
> is equally important. This is the reason for which while agreeing with
> your view that we must emphasize the way data modeling happens in the
> IETF and explain it, I believe that keeping a minimal but meaningful
> level of presentation of the models through the FCAPS perspective is
> necessary for the participants out of the IETF.
>
> Dan
>
>
>
> > -----Original Message-----
> > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On
> > Behalf Of Juergen Schoenwaelder
> > Sent: Thursday, November 17, 2011 6:19 AM
> > To: opsawg@ietf.org
> > Subject: [OPSAWG] network management data models - a rewrite
> >
> > Hi,
> >
> > draft-ietf-opsawg-management-stds-02 has a section on "Network
> > Management Data Models" which is structured around FCAPS which I
> happen
> > to dislike for several reasons (data model work in the IETF is not
> > organized around FCAPS, the discussion is constantly changing
> > abstraction levels, some of the examples picked are somewhat
> > surprising). To be constructive, I have written a replacement for this
> > section that I think better summarizes what the IETF has to offer and
> > how data modeling work happens to be done in the IETF. In addition, it
> > is also shorter.
> >
> > I do not mind if my proposed rewrite is followed by a section
> > discussing how all this fits into an FCAPS view of the world but such
> a
> > section should be much shorter and different from what is in the
> > current section 4. (For me, a short explanation that the IETF does not
> > organize data models around FCAPS is really sufficient but I guess
> > Mehmet and Benoit might not agree with that.)
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>