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

[Balazs Lengyel <[e-mail]>]

Hello Ladislav,
Thanks for the comments. Some replies.
regards Balazs

Ladislav Lhotka wrote:
> Juergen Schoenwaelder píše v Čt 29. 11. 2007 v 12:34 +0100:
>  
>> 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"?
[BALAZS]: What can we validate? The Netconf data on the wire. However due to the structure of 
NETCONF, validation possibilities based on RNG or XSD have major limitations.

95% of XML elements will have to be optional because in many cases we do not specify what must 
be in an operation, but rather what has to be in the configuration datastore as a result of the 
operation.
E.g. We have a data model

list interface {
     key IfName;
     leaf IfName {
         type string;
     }
     leaf IfSpeed {
         type uint16;
         mandatory true;
     }
     leaf IfMtu {
         type uint16;
         mandatory true;
     }
}

If an interface is already there, you can send an edit-config just adjusting IfSpeed without 
including IfMtu. So in RNG/XSD you have to make IfSpeed optional and similarly IfMtu. This is 
why YANG  models the stored configuration data as a base, and the NETCONF operations are just 
derived from this.

There are other parts of the data model that I believe can not be validated either. e.g. things 
included in the YANG statements
- must
- unique
- keyref
- configuration data in operational data containers
- min-elements, max-elements (because we don't know how many elements exist already)

> 
> 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.
> 
[BALAZS]: Traditional tools CAN be used based on the XML YIN format and the XSD (and possibly 
also RNG) conversion. Consistency is an issue for the conversion tool makers, but they will be 
a very small part of the YANG user community.


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