Subject: [netmod] FW: staying in synch on data model discovery

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Aug 2009 19:00:50 +0200

From: ext Juergen Schoenwaelder Wednesday, August 12, 2009 1:33 PM
> 
> On Wed, Aug 12, 2009 at 12:17:07PM +0200, Ersue, Mehmet (NSN 
> - DE/Munich) wrote:
>  
> > NETCONF WG developed "capabilities" and introduced several of them.
> > Is it your proposal they shouldn't be used?  I am wondering whether
> > we need a WG decision or BCP-like statement saying it shouldn't be
> > used.  It would be interesting if you elaborate a bit why YANG
> > features should be used instead of NETCONF capabilities.  (I know
> > some of the reasons but might be missing others. At the end we need
> > a record on the maillist if we want to push such a decision.)
> 
> I believe we did not communicate this well...
> 
> NETCONF provides a capability exchange mechanism which uses URIs to
> identify capabilities. The NETCONF protocol defines some core
> capability URIs but otherwise leaves the format of capability URIs
> pretty much open. YANG uses the NETCONF capability exchange and
> imposes a format on the URIs to communicate among other things data
> model defined features. The common format of the URIs allows to write
> generic code to analyse these URIs. So everything is actually pretty
> fine in the sense that NETCONF provides a mechanism and YANG uses and
> further restricts the mechanism in order to enhance interoperability.
> 
> All we want to achieve is to do away with handcrafted URI formats
> (often miscommunicated as "avoid capabilities") and instead use the
> YANG feature mechanisms. The existing NETCONF URIs of course won't be
> changed - but for new URIs, we like to use the YANG format.

Using NETCONF URIs in a specific way is fine from NETCONF POV.
I support what has been proposed in Ch. 4.4. Conditional Statements 
of the "YANG Usage guidelines" document.

Mehmet