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