RE: [OPSAWG] Basic ietf process question ...

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Thu, 02 August 2012 17:16 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0408821F8652; Thu, 2 Aug 2012 10:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.426
X-Spam-Level:
X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, 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 Ni9ZI9zSsKi9; Thu, 2 Aug 2012 10:16:24 -0700 (PDT)
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 29B1721F8622; Thu, 2 Aug 2012 10:16:24 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAJG0GlDGmAcF/2dsb2JhbABFhXuyK3OBB4IgAQEBAQMBAQEPEQ0EOgsMBAIBCA0EAQMBAQECAgYGDAsBAgICAQElHwMGCAEBBBMIGodrC59eih6TOQSBIYophXIyYAObRIoQgmE
X-IronPort-AV: E=Sophos;i="4.77,702,1336363200"; d="scan'208";a="360156194"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Aug 2012 13:12:23 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Aug 2012 13:11:50 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Subject: RE: [OPSAWG] Basic ietf process question ...
Date: Thu, 02 Aug 2012 19:16:20 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0407E24718@307622ANEX5.global.avaya.com>
In-Reply-To: <CABCOCHQwi7-Bi8itu5fZDpmEZDAufXwpS=zx68Xyq1xLzwOLng@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPSAWG] Basic ietf process question ...
Thread-Index: Ac1w0jSaA+9gSCWUS0eENw3bix/ixQAABTow
References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com><CALaySJK6RE1pnk0RJZjpU8jHb9KKb3zOjGc5NqTcVyb7kTBOyw@mail.gmail.com><CAL0qLwZaoVDtt_8o1Qr5NqG-rBk6jkAMMVT+jUUoiD2rhEvmuw@mail.gmail.com><501AA9DF.6010208@raszuk.net><EDC652A26FB23C4EB6384A4584434A0407E24713@307622ANEX5.global.avaya.com> <CABCOCHQwi7-Bi8itu5fZDpmEZDAufXwpS=zx68Xyq1xLzwOLng@mail.gmail.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Andy Bierman <andy@yumaworks.com>
Cc: opsawg@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 17:16:25 -0000

Yes. The question is whether a basic information model written in XML can be a useful starting point (trying to interpret the proposal made by Robert). 

Dan

> -----Original Message-----
> From: Andy Bierman [mailto:andy@yumaworks.com]
> Sent: Thursday, August 02, 2012 8:14 PM
> To: Romascanu, Dan (Dan)
> Cc: robert@raszuk.net; opsawg@ietf.org; ietf@ietf.org
> Subject: Re: [OPSAWG] Basic ietf process question ...
> 
> On Thu, Aug 2, 2012 at 9:59 AM, Romascanu, Dan (Dan)
> <dromasca@avaya.com> wrote:
> > Hi,
> >
> > The OPSAWG/OPSAREA open meeting this afternoon has an item on the
> > agenda concerning the revision of RFC1052 and discussing a new
> > architecture for management protocols.
> >
> >
> > My personal take is that no one protocol, or one data modeling
> > language can match the operational requirements to configure and
> > manage the wide and wider range of hosts, routers and other network
> > devices that are used to implement IP networks and protocols. We
> > should be talking nowadays about a toolset rather than one tool that
> > fits all. However, this is a discussion that just starts.
> 
> NMS developers need to spend too many resources on translating naming
> and other data-modeling specific details so they can be usable within
> the application.  So if 1 data modeling language is not used, then
> deterministic, loss-less, round-trip translation between data modeling
> languages is needed.  Multiple protocols are not the problem --
> incompatible data from multiple protocols is the problem.
> 
> >
> > Regards,
> >
> > Dan
> >
> 
> Andy
> 
> >
> >
> >
> >> -----Original Message-----
> >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
> > Of
> >> Robert Raszuk
> >> Sent: Thursday, August 02, 2012 7:25 PM
> >> Cc: ietf@ietf.org
> >> Subject: Basic ietf process question ...
> >>
> >> All,
> >>
> >> IETF documents have number of mandatory sections .. IANA Actions,
> >> Security Considerations, Refs, etc ...
> >>
> >> Does anyone have a good reason why any new protocol definition or
> >> enhancement does not have a build in mandatory "XML schema" section
> >> which would allow to actually use such standards based enhancement in
> >> vendor agnostic way ?
> >>
> >> There is a lot of talk about reinventing APIs, building network wide
> > OS
> >> platform, delivering SDNs (whatever it means at any point of time for
> >> one) ... but how about we start with something very basic yet IMHO
> >> necessary to slowly begin thinking of network as one plane.
> >>
> >> I understand that historically we had/still have SNMP however I have
> >> never seen this being mandatory section of any standards track
> > document.
> >> Usually SNMP comes 5 years behind (if at all) making it obsolete by
> >> design.
> >>
> >> NETCONF is great and very flexible communication channel for
> >> provisioning. However it is sufficient to just look at number of ops
> >> lists to see that those who tried to use it quickly abandoned their
> >> efforts due to complete lack of XML schema from each vendor they
> > happen
> >> to use or complete mismatch of vendor to vendor XML interpretation.
> >>
> >> And while perhaps this is obvious I do not think that any new single
> >> effort will address this. This has to be an atomic and integral part
> > of
> >> each WG's document.
> >>
> >> Looking forward for insightful comments ...
> >>
> >> Best,
> >> R.
> >>
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg