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

"Bert Wijnen - IETF" <bertietf@bwijnen.net> Tue, 22 April 2008 17:14 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 98D453A6E1B; Tue, 22 Apr 2008 10:14:07 -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 041AB3A68D0 for <ietf@core3.amsl.com>; Tue, 22 Apr 2008 10:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 s7S5SD3lleRA for <ietf@core3.amsl.com>; Tue, 22 Apr 2008 10:14:03 -0700 (PDT)
Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 12A1C3A6D6B for <ietf@ietf.org>; Tue, 22 Apr 2008 10:14:02 -0700 (PDT)
Received: (qmail 57135 invoked from network); 22 Apr 2008 17:14:08 -0000
Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Apr 2008 17:14:08 -0000
From: "Bert Wijnen - IETF" <bertietf@bwijnen.net>
To: "Eric Rescorla" <ekr@networkresonance.com>, <ietf@ietf.org>, <iesg@ietf.org>
Subject: RE: WG Review: NETCONF Data Modeling Language (netmod)
Date: Tue, 22 Apr 2008 19:14:10 +0200
Message-ID: <NIEJLKBACMDODCGLGOCNGEGIEMAA.bertietf@bwijnen.net>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <20080422161010.94BC15081A@romeo.rtfm.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Importance: Normal
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....

REALLY... ????

I heard during that BOF that there was consensus to start the work.
I also saw that quite a few liked the YANG proposal, and several
wanted to have mappings to either XSD or RELAX or DSDL.

The smaller meetings that happened after the NOF, included people
from all of the proposals that were on the table, including people
who were in teh Design Team for the requirements. We had
fruitfull discussions that converged onto a single approach.

We then got all the people from the various proposls together on
the rdcml mailing list (the one that was used by the requirements
design team), and we had a 2 week long discussion with multiple
hundereds of emails and opinions, and again, we converged to a
common and acceptable draft WG charter.

That draft WG charter was then put to the NGO mailing list were
we had further discussion with various other people. Again we seem
to have consensus. Several non-original-netconf people are on
that mailing list, as a result of the BOF discussions we have had
in the past thow IETF meetings.

Then, Dan brought it to IESG, and the IESG agreed to send the
WG proposal out for IETF Wide review. That is where we are now,
and sure you can vent your opinion, but claiming (or accusing us)
that there was no wide discussion or that there is no consensus at
all and that there were/are just 4 different groups with conflicting
proposals does not seem valid to me.

Further, the change you propose to the WG charter, could be done,.
and then in the first WG session we could declare victory for the
milestone you want. I believe that virtually all of the interested
people were involved in the discussion sofar. So I do not see why
we would need long in a newly formed WG to come to the same
conclusion again.

But if we do what you propose, then we will consume again more
cycles of IESG/IAB and the IETF at large, because they will have
to look once more at the WG rechartering in 3 months time.

Bert Wijnen

> -----Oorspronkelijk bericht-----
> Van: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]Namens Eric
> Rescorla
> Verzonden: dinsdag 22 april 2008 18:10
> Aan: ietf@ietf.org; iesg@ietf.org
> Onderwerp: Re: WG Review: NETCONF Data Modeling Language (netmod)
>
>
> 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.
>
> 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.
>
> -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 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