Re: WG Review: NETCONF Data Modeling Language (netmod)
Andy Bierman <ietf@andybierman.com> Tue, 22 April 2008 17:08 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246D328C213; Tue, 22 Apr 2008 10:08:50 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59FDF3A68F1 for <ietf@core3.amsl.com>; Tue, 22 Apr 2008 10:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkJbRKQsWkFI for <ietf@core3.amsl.com>; Tue, 22 Apr 2008 10:08:47 -0700 (PDT)
Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id F38823A6D5F for <ietf@ietf.org>; Tue, 22 Apr 2008 10:08:46 -0700 (PDT)
Received: (qmail 15307 invoked from network); 22 Apr 2008 17:08:52 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.242.137 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 22 Apr 2008 17:08:51 -0000
X-YMail-OSG: S1lCwr4VM1m6r39k7KTVe2LlZNxLakJk8lZ242wJPWIYFNaSb6AoXAdIWei4RnP_OS8erWE8g7wpTVCJeDQekzR1Pl9Ics_8kqN78DUrBEufP8CygaCLYY_9Le4-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <480E1BA1.1080606@andybierman.com>
Date: Tue, 22 Apr 2008 10:08:49 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
Subject: Re: WG Review: NETCONF Data Modeling Language (netmod)
References: <20080422161010.94BC15081A@romeo.rtfm.com>
In-Reply-To: <20080422161010.94BC15081A@romeo.rtfm.com>
Cc: ietf@ietf.org, iesg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Eric Rescorla wrote: > I object to the formation of this WG with this charter. > > While there was a clear sense during the BOF that there was interest > in forming a WG, there was absolutely no consensus on technical > direction. Rather, a number of proposals were presented, but no > strawpoll, hum, or sense of the room was taken, nor, as far as I can > determine, has there been any such consensus call been taken on any > list I'm aware of. This wasn't an accident--the BOF was explicitly > intended only to determine whether some work in this area should > proceed, not to select a technical approach. > > I understand that an approach like this was proposed in the OPSAREA > meeting by Chris Newman and then that there was a breakout meeting > where it was discussed further. The minutes don't record any consensus > call on this combined direction (only strawpolls on the individual > proposals), and even if such a consensus call had been held, the > OPSAREA meeting would not be the appropriate place for it: this > discussion needs to happen in either the BOF (to allow cross-area > review) or in the designated WG, when it is formed. > I believe there was consensus in the CANMOD BoF that the requirements were sufficiently understood, and the purpose of that BoF had been fulfilled. After the CANMOD BoF, a 15 person design team was formed, which reached consensus on a technical approach, embodied in the charter text. There was also unanimous agreement on the charter, outside the design team (on the NGO mailing list). > Accordingly, if this WG is to be formed, the entire section (and > corresponding milestones) which specifies the technology needs to be > removed. Rather, the first work item should be to select a technical > approach. I thought the charter text did specify a technical approach, which is to utilize YANG as a high-level DML and map YANG constructs to DSDL and XSD. Can you explain this work item further? > > -Ekr Andy > >> NETCONF Data Modeling Language (netmod) >> ---------------------------------------- >> Last modified: 2008-04-10 >> >> Current Status: Proposed Working Group >> >> Chair(s): >> >> TBD >> >> Operations and Management Area Director(s): >> Dan Romascanu <dromasca at avaya.com> >> Ronald Bonica rbonica at juniper.net >> >> Mailing Lists: >> >> General Discussion: ngo at ietf.org >> >> Description: >> >> The NETCONF Working Group has completed a base protocol to be >> used for configuration management. However, the NETCONF protocol >> does not include a standard content layer. The specifications do >> not include a modeling language or accompanying rules that can be >> used to model the management information that is to be configured >> using NETCONF. This has resulted in inconsistent syntax and >> interoperability problems. The purpose of NETMOD is to support >> the ongoing development of IETF and vendor-defined data models >> for NETCONF. >> >> NETMOD's requirements are drawn from the RCDML requirements draft >> (draft-presuhn-rcdml) and documents referenced therein. > > >> The WG will define a "human-friendly" modeling language defining >> the semantics of operational data, configuration data, >> notifications, and operations. This language will focus on >> readability and ease of use. This language must be able to serve >> as the normative description of NETCONF data models. The WG will >> use YANG (draft-bjorklund-yang) as its starting point for this >> language. >> >> Language abstractions that facilitate model extensibility and >> reuse have been identified as a work area and will be considered >> as a work item or may be integrated into the YANG document based >> on WG consensus. >> >> The WG will define a canonical mapping of this language to >> NETCONF XML instance documents, the on-the-wire format of >> YANG-defined XML content. Only data models defined in YANG will >> have to adhere to this on-the-wire format. >> >> In order to leverage existing XML tools for validating NETCONF >> data in various contexts and also facilitate exchange of data >> models and schemas with other IETF working groups, the WG will >> define standard mapping rules from YANG to the DSDL data modeling >> framework (ISO/IEC 19757) with additional annotations to preserve >> semantics. >> >> The initial YANG mapping rules specifications are expressly defined for >> NETCONF modeling. However, there may be future areas of >> applicability beyond NETCONF, and the WG must provide suitable >> language extensibility mechanisms to allow for such future work. >> The NETMOD WG will only address modeling NETCONF devices and the >> language extensibility mechanisms. Any application of YANG to >> other protocols is future work. >> >> The WG will consult with the NETCONF WG to ensure that NETMOD's >> decision do not conflict with planned work in NETCONF (e.g., >> locking, notifications). >> >> While it is desirable to provide a migration path from existing >> MIB modules to YANG data models (modules), it is not a >> requirement to provide full compatibility between SMIv2 and YANG. >> The Working Group will determine which constructs (e.g., conformance >> statements) are not relevant for translation from SMIv2 to YANG. YANG is >> also permitted to introduce constructs that cannot be expressed in SMIv2. >> However, all basic types that can be represented in SMIv2 must be >> expressible in YANG. >> >> Initial deliverables are below. The working group may choose to >> combine multiple deliverables into a single document where deemed >> appropriate. >> >> 1. An architecture document explaining the relationship >> between YANG and its inputs and outputs. (informational) >> >> 2. The YANG data modeling language and semantics (proposed >> standard) >> >> 3. Mapping rules of YANG to XML instance data in NETCONF >> (proposed standard) >> >> 4. YIN, a semantically equivalent fully reversible mapping to an >> XML-based syntax for YANG. YIN is simply the data model in an XML syntax >> that can be manipulated using existing XML tools (e.g., XSLT) (proposed >> standard) >> >> 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC >> 19757), including annotations for DSDL to preserve top-level >> semantics during translation (proposed standard). >> >> 6. A standard type library for use by YANG (proposed standard) >> >> Goals and Milestones: >> >> Jun 2008 - All _individual_ drafts available that will be used as >> input into the WG documents (draft-bjorklund-yang, architecture >> draft, YIN draft, YANG standard library draft, DSDL mapping rules >> draft) >> >> Aug 2008 - Initial set of WG drafts: architecture, YANG, YIN, >> YANG standard library, DSDL mapping rules (if there is one/more >> individual draft), based on WG decisions in Dublin >> >> Sep 2008 - Initial DSDL mapping rules document >> >> Oct 2008 - 01 of YANG, DSDL, architecture, YIN, and standard >> library draft. If split out, -00 of on-the-wire XML draft. >> >> Feb 2009 - WGLC for architecture doc >> >> Mar 2009 - Submit the architecture doc to the IESG for >> publication as an Informational RFC >> >> Aug 2009 - WGLC for YANG, YIN, XML on-the-wire (if split out), >> YANG standard library, DSDL mapping rules >> >> Sep 2009 - Submit YANG, YIN, XML on-the-wire (if split out), YANG >> standard library, DSDL mapping rules to the IESG for publication as a >> Proposed Standard >> _______________________________________________ > _______________________________________________ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: WG Review: NETCONF Data Modeling Language (ne… Chris Newman
- Re: [NGO] WG Review: NETCONF Data Modeling Langua… Phil Shafer
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Andy Bierman
- RE: WG Review: NETCONF Data Modeling Language (ne… Bert Wijnen - IETF
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Randy Presuhn
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- RE: WG Review: NETCONF Data Modeling Language (ne… Bert Wijnen - IETF
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- Re: WG Review: NETCONF Data Modeling Language (ne… Andy Bierman
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- RE: WG Review: NETCONF Data Modeling Language (ne… Bert Wijnen - IETF
- RE: WG Review: NETCONF Data Modeling Language (ne… Bert Wijnen - IETF
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Randy Presuhn
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Dave Crocker
- Re: WG Review: NETCONF Data Modeling Language (ne… Randy Presuhn
- RE: WG Review: NETCONF Data Modeling Language (ne… David Harrington
- Re: WG Review: NETCONF Data Modeling Language (ne… Harald Alvestrand
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Andy Bierman
- Rough consensus among WHOM? Dave Crocker
- RE: WG Review: NETCONF Data Modeling Language (ne… Mehmet Ersue
- RE: WG Review: NETCONF Data Modeling Language (ne… Bert Wijnen - IETF
- Re: WG Review: NETCONF Data Modeling Language (ne… Michael Thomas
- RE: WG Review: NETCONF Data Modeling Language (ne… David Harrington
- Re: WG Review: NETCONF Data Modeling Language (ne… Andy Bierman
- RE: WG Review: NETCONF Data Modeling Language (ne… Leslie Daigle
- Re: WG Review: NETCONF Data Modeling Language (ne… Wes Hardaker
- Re: WG Review: NETCONF Data Modeling Language (ne… Tom.Petch
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- Re: WG Review: NETCONF Data Modeling Language (ne… Bernard Aboba
- RE: WG Review: NETCONF Data Modeling Language (ne… David Harrington
- Re: WG Review: NETCONF Data Modeling Language (ne… Bernard Aboba
- Re: WG Review: NETCONF Data Modeling Language (ne… Randy Presuhn