On Tue, Jul 19, 2016 at 03:20:17AM -0700, Andy Bierman wrote:
> On Tue, Jul 19, 2016 at 3:13 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> > We may have to be more explicit. A decent client talking to a
> > NETCONF/RESTCONF server should pick the latest version of the YANG
> > modules announced in the server's YANG library. A development tool
> > should pick the latest version available to the tool. In case the tool
> > is used to develop code running on the server, then this version
> > should be announced as the latest version on the server.
> >
> >
> Our tools use a module search path approach, plus pick latest as the
> 'supported' version.
> It is very common (in programming anyway) to control the versions used by
> controlling the include and library search paths.
>
> IMO the IETF should not specify how implementations should work
> except the normative text in RFCs. So write a new RFC and get IETF
> consensus
> on it in order to enforce a rule like this one.
>
In case this was not clear, this has been input to the discussion of
RFC 6087bis based on my naive understanding of things.
Note that 'latest version available to the tool' essentially
translates to search paths in typical implementations (at least that
was the intention).
/js
PS: Perhaps replace "A decent client talking to a NETCONF/RESTCONF
server" with "A client capable of adapting to the data models
implemented by a NETCONF/RESTCONF server" to phrase things better.
The key was to point out that using version X to generate the code
and then announcing version Y later may cause trouble with clients
that do dynamically adapt based on the versions announced in the
YANG library.
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
