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

Is not this discussion better fit for yang@ietf.org or even discuss@apps.ietf.org? 

Dan

> -----Original Message-----
> From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] 
> Sent: Thursday, November 29, 2007 6:04 PM
> To: Ladislav Lhotka
> Cc: ngo@ietf.org
> Subject: Re: [NGO] Re: Why NETCONF needs a data modeling language
> 
> 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
> NGO@ietf.org
> https://www1.ietf.org/mailman/listinfo/ngo
> 

_______________________________________________
NGO mailing list
NGO@ietf.org
https://www1.ietf.org/mailman/listinfo/ngo