Re: [NGO] Re: Why NETCONF needs a data modeling language

[Andy Bierman <[e-mail]>]

Ladislav Lhotka wrote:
> Juergen Schoenwaelder píše v Čt 29. 11. 2007 v 12:34 +0100:
> 
>> Statements like 'config true;' are essential for the processing of
>> NETCONF messages and also for validating content exchanged in NETCONF
>> messages (and this is why for example generic XML validation tools are
>> only of limited value for NETCONF implementors).
> 
> Yes, I think pure RNG is not an option. But again, RNG is considerably
> more open to extensions than XSD (no appinfo wrappers needed). However,
> to be fair, using foreign elements/namespaces (and annotations)
> seriously damages the readability of the compact syntax (not so much the
> XML syntax).


Exactly.
I was one of the 'researchers' that spent the last 3 years trying
to build NETCONF tools from XSD, then RNG-compact, then my own NCX
language, and now YANG.

Operators have made it clear (to me anyway) that they prefer
to read and write text.  To them, text does not mean tons
of angle brackets and verbose tagging, hiding the real info.
The config file mindset is alive and well.

IMO, YANG has the best balance between syntax and semantics
that I have ever seen.  Neither is sacrificed whatsoever.
(However, YANG chooses not to support XML attributes or xsd:list
data type, because they are bad wrt/ NETCONF tools).

XSD and RNG have more powerful (and more complex) features than YANG,
which are suited to constructing XML instance documents.  YANG has
configuration features, Xpath-based object-constraint features,
lots of vendor extensibility, and a very easy-to-grok syntax,
no matter how complicated the data model gets. YANG is not
a general purpose XML language, like XSD and RNG.

(Ever notice that your carpenter doesn't use those all-in-one
tools advertised on late-night TV?)

> 
>> a) that doing so will lead to a large reuse of available RNG tools for
>>    processing NETCONF data models (since they don't know the RNG
>>    subset nor the semantic additions)
> 
> For example, NETCONF data could be validated (as an XML document) using
> the existing tools, RNG specification requires that foreign elements be
> ignored. As for the subset of RNG - could it perhaps be just a
> convention, like "avoid mixed content"?
>

I don't see how an RNG validation tool can possibly help an agent,
or even a manager implementation.  RNG doesn't know which data
is writable vs. read-only.  It doesn't know interface[eth0] from interface[eth1].
It doesn't know about the NETCONF 'operation' attribute in <edit-config>.

In short, RNG doesn't know anything about NETCONF.

That is YANG's reason for existing.
NETCONF is all YANG does, and it covers the details better
than add-ons to RNG ever could.


>> b) that the effort to specify such an extended subset will be less
>>    than the effort for defining a domain specific language like YANG
> 
> I'd say the former effort will be *significantly* smaller than the
> latter since the main issue - defining document structure - comes for
> free and has already been thoroughly tested. A problem may be though
> that the hybrid language could turn out to be less readable for humans.
>   
>> c) that the effort to implement tools understanding the adapted subset
>>    of RNG will be less than writing proper tools for a domain specific
>>    language from scratch
> 
> It would make sense if one could use both the traditional XML tools and
> new NETCONF-specific tools. The big advantage would be that both
> categories would use exactly the same data model specification. Even if
> someone writes conversion tools like YANG->RNG, it would be more
> difficult to guarantee consistency.
> 
>> d) that there will be long term (say 20 year) reliable change control
>>    exercised by the organization that has change control over NETCONF
> 
> For the extension within an IETF-controlled namespace this could be
> guaranteed, but of course if the XML world turns entirely to Yet Another
> Schema Language, the extension would have to be ported to it. Given the
> momentum behind RNG these days, I don't think it is very likely.
> 
> Lada
> 

Andy


_______________________________________________
NGO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ngo