[scrm-wg] FW: [netmod] WG Action: NETCONF Data Modeling Language (netmod)

[Romascanu, Dan (Dan)]

I believe that this announcement about the formation of the IETF NETCONF
Data Modeling Language (netmod) WG may be of interest. 

Dan


-----Original Message-----
From: netmod-bounces at ietf.org [mailto:netmod-bounces at ietf.org] On Behalf
Of The IESG
Sent: Wednesday, April 30, 2008 5:44 AM

Subject: [netmod] WG Action: NETCONF Data Modeling Language (netmod)

A new IETF working group has been formed in the Operations and
Management Area.  For additional information, please contact the Area
Directors or the WG Chairs.

NETCONF Data Modeling Language (netmod)
---------------------------------------------

Chair(s): 

David Harrington <dbharrington at comcast.net> David Partain
<david.partain at ericsson.com>

Operations and Management Area Director(s):

Dan Romascanu <dromasca at avaya.com>
Ronald Bonica >rbonica at juniper.net>

Operations and Management Area Advisor:
Dan Romascanu <dromasca at avaya.com>

Mailing Lists:

General Discussion: netmod at ietf.org
To Subscribe: netmod-request at ietf.org
In Body: in msg body: subscribe
Archive: http://www.ietf.org/mail-archive/web/netmod/

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