Writing as technical contributor...
On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote:
> Hi,
>
> Here's a short summary, and then some questions for the WG.
>
> The ietf-yang-library module is designed to serve two purposes:
>
> 1. A protocol-independent advertisement mechanism for YANG 1.1
> modules.
>
> 2. A list of the YANG modules stored in a server.
>
>
> Q1. Do you agree with these goals?
I primarily care about goal 1.
> Q2. Should this module be designed to work with both YANG 1.0 and
> YANG 1.1 servers - i.e., should it have yang-version 1.1 or not?
>
> If it should not be defined using YANG 1.1, why is this module
> special?
I assume this module will sooner or later be YANG 1.1 anyway.
> Q3. Should the /modules/module list be designed to store both YANG
> 1.0 and YANG 1.1 modules?
Yes. Even if YANG 1.1 hits the street tomorrow, we will not have
revised all published YANG data models that were written using YANG
1.0. So a server needs to be able to announce both YANG 1.0 and YANG
1.1 modules.
> Q4. Consider these modules, which both import foo without revision:
>
> module a { ... import foo; ... }
> module b { ... import foo; ... }
>
> Do we require a server that implements both a and b to use the
> same revision of foo?
>
> If the answer is yes, we need to indicate the default revision
> that the server uses in the model:
>
> container modules {
> ...
> list module {
> ...
> leaf default-revision {
> type boolean;
> default false;
> description
> "Indicates that this revision is used by the server if
> this module is imported without a specific revision
> date.";
> }
> }
> }
>
> If the answer is no, note that this puts an implementation burden
> on the client. A client cannot simply download all listed
> modules, and load/compile/process them as one set.
>
> If the anwser is no, I propose that we extend the module as such:
>
> container modules {
> ...
> list module {
> ...
> list imported-without-revision {
> key "name revision";
> ...
> }
> }
> }
>
> A server could then list:
>
> <module>
> <name>a</name>
> <revision>2015-01-01</revision>
> <imported-without-revision>
> <name>foo</name>
> <revision>2002-02-02</revision>
> </imported-without-revision>
> </module>
> <module>
> <name>b</name>
> <revision>2015-01-01</revision>
> <imported-without-revision>
> <name>foo</name>
> <revision>2001-01-01</revision>
> </imported-without-revision>
> </module>
I believe truth is advertisement is a good thing. In the SNMP world,
not all pieces of the instrumentation were moving at the same pace and
I would be somewhat surprised if this would be the case for all
implementations in the NETCONF world. Hence, I rather accept that an
import of foo without revision may resolve to different versions of
foo for different imports.
/js
--
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
