On Fri, Jul 3, 2015 at 1:45 PM, Martin Bjorklund <m...@tail-f.com> wrote:
> Andy Bierman <a...@yumaworks.com> wrote:
> > 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.
>
> Don't we have to list the deviation module's revision as well? As you
> noted, the revision is needed in <get-schema>.
>
> If we don't list the deviation module in the main list, it won't be
> possible to download such modules over RESTCONF.
>
>
That means that the deviation leaf-list has to be a list
to include name and revision. Then there can be a schema leaf
in each of those entries.
If the deviations module also has other definitions
(a bad practice) then it can be present in the 'module' list
for 'implements' or 'imports'. This should be rare.
> > A module server would return
> > the conformance for the proxied server, not itself.
> >
> > No new objects will be added.
>
> This is up to the WG to decide. So far, three people (myself
> included) have said that they want to solve the advertisement problem,
> "indicate the import tree" as you put it, and the two proposed
> solutions require new nodes in the module.
>
>
I should say no new objects to this release.
The WG can always decide another revision is needed.
It would be good to hear from more people.
>
> I think your objection to addressing this problem is that if import
> w/o revision is used, the client by design cannot/should not know
> which revision the server used. Did I get that right?
>
>
I propose this text in the conformance leaf:
For import statements that do not specify a revision
date, the most recent revision in the library SHOULD
be used by the server.";
It seems like a lot of data will be needed to model the dependency tree
for every import-stmt in every module. Don't forget every include-stmt
as well, since submodules can import with or without revision.
IMO "SHOULD use latest" is good enough.
Perhaps modules should use import-by-revision when they
are published as RFCs (as Lada suggested).
As Jeff pointed out, the only time it is safe to use
import/include without revision is if you are sure the imported
module (or included submodule) is the one and only
revision that has, or ever will exist.
Even within a single naming organization this might be
a bad assumption to make.
> /martin
>
Andy
>
>
>
> > 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
