Hi,
I am going to update the draft so the conformance leaf
is an enumeration with 'implement' and 'import' enums.
The 'none' enum is not needed because the deviations are
listed inside the module entry. A module server would return
the conformance for the proxied server, not itself.
No new objects will be added.
Only item # is being addressed.
Every module the server implements with be listed once
with conformance=implement. Every module and revision
that those modules import (rippled through all imports) will be listed
in the library, with conformance=import, except of
course if the imported module is also an implemented module.
No other modules will be listed.
Andy
On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman <a...@yumaworks.com> wrote:
>
>
> On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
>> 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.
>>
>
>
> Yes -- We also agreed that we would not be republishing modules
> just to change the yang-version to 1.1.
>
> There are lots of YANG modules in progress at this time.
> Perhaps 3 out of 100 are relying on YANG 1.1 statements.
> It seems rather disruptive to declare all module must be YANG 1.1
> since it has not even made it through WGLC yat, let alone
> be published as an RFC, let alone be implemented
> in real tool-chains.
>
> I suspect if people find out the only think YANG 1.1 in their module
> (preventing their existing tools from working) is a yang-version-stmt,
> they might not be too happy.
>
>
> Andy
>
>
>>
>> > 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
>>
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
