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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> 


_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]