Re: WG Review: NETCONF Data Modeling Language (netmod)

Andy Bierman <> Tue, 22 April 2008 17:08 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 246D328C213; Tue, 22 Apr 2008 10:08:50 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59FDF3A68F1 for <>; Tue, 22 Apr 2008 10:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vkJbRKQsWkFI for <>; Tue, 22 Apr 2008 10:08:47 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id F38823A6D5F for <>; 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 ? ( with plain) by with SMTP; 22 Apr 2008 17:08:51 -0000
X-YMail-OSG: S1lCwr4VM1m6r39k7KTVe2LlZNxLakJk8lZ242wJPWIYFNaSb6AoXAdIWei4RnP_OS8erWE8g7wpTVCJeDQekzR1Pl9Ics_8kqN78DUrBEufP8CygaCLYY_9Le4-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Tue, 22 Apr 2008 10:08:49 -0700
From: Andy Bierman <>
User-Agent: Thunderbird (Windows/20080213)
MIME-Version: 1.0
To: Eric Rescorla <>
Subject: Re: WG Review: NETCONF Data Modeling Language (netmod)
References: <>
In-Reply-To: <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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


>> 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>
>> Ronald Bonica rbonica at
>> Mailing Lists:
>> General Discussion: ngo at
>> 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 mailing list