[netmod] closing issues on opstate-reqs

[Kent Watsen]

Seven issues were filed against draft-chairs-netmod-opstate-reqs-00:

https://github.com/netmod-wg/opstate-reqs/issues


These issues are all currently in the NEW state.  FYI, all the issue tracking 
states are described here:

https://github.com/netmod-wg/opstate-reqs/blob/master/README.md#issue-tracking


Immediately I plan to start a thread to track some of these issues to closure.  
I will start with an easy issue so we can see how it goes.

Thanks,
Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

[Kent Watsen]

Regarding https://github.com/netmod-wg/opstate-reqs/issues/7


  Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
others are now defining YANG modules?

  Benoit> Good point. We need to provide guidance for the other SDOs.


Current text says:

   7.  Ability for distinct modules to leverage a common model-structure
   A.  Scope is limited to IETF-defined modules
   B.  Multiple domain-specific trees are okay
   C.  Multiple namespaces are okay



Background:

  I pulled 7A from Andy's message here:


https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U

  and put a stake in the ground so that, if nothing else, it could
  be discussed...and here we are!

  FWIW, I wrote 7A this way because I didn't see how it can be
  enforced outside of the IETF.  But maybe that doesn't matter?
  Of course, we can have 6087bis guidance for other SDOs, but
  I didn't put that in the text.


Thoughts on how the text should be updated?


PS: Please Reply-All to the list rather than post comments to the GitHub
issue tracker.


Thanks,
Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y60 - coexistence with YANG 1.0

[Martin Bjorklund]

Andy Bierman  wrote:
> On Thu, Sep 17, 2015 at 3:39 AM, Martin Bjorklund  wrote:
> 
> > Ladislav Lhotka  wrote:
> > >
> > > > On 15 Sep 2015, at 15:54, Martin Bjorklund  wrote:
> > > >
> > > > Juergen Schoenwaelder  wrote:
> > > >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> > > >>>
> > > >>> Sure.  The use case is for example servers that implement ietf-ip
> > > >>> (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> > > >>> update ietf-interfaces to 1.1.  It should still be ok for a server to
> > > >>> implement ietf-ip with the new ietf-interfaces.
> > > >>>
> > > >>
> > > >> Is the confusion is between implements and imports here? The module
> > > >> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> > > >> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> > > >> this not going to work?
> > > >>
> > >  Would it not work if an import of ietf-interfaces from a
> > >  version 1 module simply resolves to the latest ietf-interfaces
> > >  revision that is still version 1?
> > > >>>
> > > >>> But that would mean either that a server is stuck implementing
> > version
> > > >>> 1 modules, or that the server must implement both the version 1 and
> > > >>> version 1.1 module - and we have already said that this isn't
> > > >>> possible.
> > > >>
> > > >> But this seems only true if import === implemented.
> > > >>
> > > >>> A set of simpler rules would be:
> > > >>>
> > > >>>   A YANG version 1.1 module MUST NOT include a version 1 module.
> > > >>>   A YANG version 1 module MUST NOT include a version 1.1 module.
> > > >>>
> > > >>>   A YANG version 1.1 (sub)module MAY import a version 1 module.
> > > >>>   A YANG version 1 (sub)module MAY import a version 1.1 module.
> > > >>
> > > >> It is the last one we are discussing, no? I am trying again: Why is
> > > >> the MAY needed? Why is it not sufficient for a version 1 module to
> > > >> work with an import for (the latest) version 1 module?
> > > >
> > > > How about this:
> > > >
> > > > ---
> > > >
> > > > * Coexistence with YANG version 1 @coexistence@
> > > >
> > > > A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
> > > > and a YANG version 1 module MUST NOT include a YANG version 1.1
> > > > submodule.
> > >
> > > Does this apply only to include-by-revision? Because otherwise how can
> > > we tell?
> >
> > It is supposed to apply to both; if it is include by revision it is
> > obvious, but for include w/o revision it means that any tool (server,
> > client, ...) MUST treat version mismatch as an error.
> >
> 
> This is still a problem:
> 
> A YANG version 1 (sub)module MAY import a version 1.1 module.

But my proposed text doesn't say that.  It was rewritten to:

  If a YANG version 1 module A imports module B without revision, and
  module B is updated to YANG version 1.1, a server MAY implement both
  these modules at the same time.  In such cases, a NETCONF server
  MUST advertise both modules using the rules defined in ^announce^,
  and SHOULD advertise module A and the latest revision of module B
  that is specified with YANG version 1 according to the rules defined
  in ^RFC6020^.

> This assumes the tools understand YANG 1.1.
> YANG 1 says it is undefined what happens if the YANG 1 compiler
> finds a yang-version value other than '1'.
> 
> You want to make a distinction between a YANG 1.1 capable tool
> and a YANG 1.0 capable tool. Obviously a YANG 1 capable tool
> is not required to EVER accept a YANG 1.1 module.

Agreed.

> So when the YANG author imports a YANG 1.1 module from a YANG 1 module
> and no revision date is given, there really are no rules that YANG 1.1 can
> specify
> that would apply to a YANG 1 tool.  There is no way to enforce any
> interoperability
> requirements wrt/ the revision of the imported module that is used in this
> case.

It is not that the version 1 module author imports a 1.1 module w/o
revision; the use case is an implementation that MAY *implement* both.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod