Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

  
  
Hello Andy,
Martin's main problem was that we would need to update the
  original modules if the mount changes. I showed that design-time
  mount can be defined without modifying the original modules, if
  you specify the mount information in a separate file. So what
  specific problems are you concerned about?
I do not want to make schema-mount a purely design-time solution.
  However I feel that the ability to define the mounts in design
  time is an important use-case that does not cause any problems.

regards Balazs


On 2016-08-26 19:53, Andy Bierman
  wrote:


  
  Hi,


I agree with Martin about not specifying which YANG modules
can be mounted under some mount point, in the YANG module.


The mount point needs some basic properties (like "config
  root", "opstate root", whatever).
Then data nodes are classified somehow (e.g.
  config=true/false) and that determines
what content can be mounted under that mount-point.


The combination of modules on the server needs to be a
  deployment decision to
prevent issues like Martin describes below.




Andy


  
  
On Fri, Aug 26, 2016 at 5:38 AM, Martin
  Bjorklund 
  wrote:
  Ladislav
Lhotka  wrote:
> Martin Bjorklund 
writes:
>
> > Hi,
> >
> > [replying to the first post in this (old) thread;
the thread got a bit
> > off-topic]
> >
> > Balazs Lengyel 
wrote:
> >> Hello,
> >>
> >> As I understand it, Schema-mount today does
not support an important
> >> use-case which we definitely need, but others
also indicated they
> >> want.
> >>
> >> I want to specify off-line in design time
which models will be mounted
> >> where. Many of my nodes know in design-time
what their model structure
> >> will be, so I want a way to be able to
document this in YANG.
> >
> > I'd like to understand this use case in more
detail.  You say that
> > that a "node knows in design-time" that YANG
models it will use.  Thus
> > it seems natural to be able to specify which other
modules to mount in
> > the YANG module itself.
>
> Did you have a chance to look into my slides from
Berlin? I sketched some
> solutions there.

Well, that's a *solution*.  I'd like to understand the
*problem* first ;)

> > The problem I see with this is that it is very
limited to the use case
> > where each implementation defines its own YANG
modules.  Suppose you
> > have such a model, for example:
> >
> >    module A {
> >      ...
> >      mount ... {
> >        mount-module B;
> >        mount-module C;
> >      }
> >   }
> >
> > [pseudo-code for module A that specifies that it
mounts B and C]
> >
> > Now, suppose you take this module A to another
implementation, and it
> > needs to augment something into module C;
essentially this means that
> > it would like to mount B, C and new module D. 
 This will not be
> > possible unless it modifies module A.
>
> Not necessarily, D could contain an augment with a
target specified by a
> schema node identifier that uses nodes from both A and
C.

Not if B and D are defined as standalone modules, e.g. if B
is
ietf-interfaces and D is ietf-ip.

> Imagine that instead of "ietf-ip" augmenting
"ietf-interfaces" it would
> be the other way around: "ietf-interfaces" mounts
"ietf-ip". Then the
> augment in ietf-ipv6-router-advertisements
>
>   augment "/if:interfaces-state/if:interface/ip:ipv6"
{ ... }
>
> needn't be changed.

This would be an entirely different kind of mount!  The
current mount
doesn't work like that; it doesn't give you visibility into
the
combined models - by design.

Re: [netmod] Design-Time schema mount

[Andy Bierman]

Hi,

I agree with Martin about not specifying which YANG modules
can be mounted under some mount point, in the YANG module.

The mount point needs some basic properties (like "config root", "opstate
root", whatever).
Then data nodes are classified somehow (e.g. config=true/false) and that
determines
what content can be mounted under that mount-point.

The combination of modules on the server needs to be a deployment decision
to
prevent issues like Martin describes below.


Andy


On Fri, Aug 26, 2016 at 5:38 AM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> >
> > > Hi,
> > >
> > > [replying to the first post in this (old) thread; the thread got a bit
> > > off-topic]
> > >
> > > Balazs Lengyel  wrote:
> > >> Hello,
> > >>
> > >> As I understand it, Schema-mount today does not support an important
> > >> use-case which we definitely need, but others also indicated they
> > >> want.
> > >>
> > >> I want to specify off-line in design time which models will be mounted
> > >> where. Many of my nodes know in design-time what their model structure
> > >> will be, so I want a way to be able to document this in YANG.
> > >
> > > I'd like to understand this use case in more detail.  You say that
> > > that a "node knows in design-time" that YANG models it will use.  Thus
> > > it seems natural to be able to specify which other modules to mount in
> > > the YANG module itself.
> >
> > Did you have a chance to look into my slides from Berlin? I sketched some
> > solutions there.
>
> Well, that's a *solution*.  I'd like to understand the *problem* first ;)
>
> > > The problem I see with this is that it is very limited to the use case
> > > where each implementation defines its own YANG modules.  Suppose you
> > > have such a model, for example:
> > >
> > >module A {
> > >  ...
> > >  mount ... {
> > >mount-module B;
> > >mount-module C;
> > >  }
> > >   }
> > >
> > > [pseudo-code for module A that specifies that it mounts B and C]
> > >
> > > Now, suppose you take this module A to another implementation, and it
> > > needs to augment something into module C; essentially this means that
> > > it would like to mount B, C and new module D.   This will not be
> > > possible unless it modifies module A.
> >
> > Not necessarily, D could contain an augment with a target specified by a
> > schema node identifier that uses nodes from both A and C.
>
> Not if B and D are defined as standalone modules, e.g. if B is
> ietf-interfaces and D is ietf-ip.
>
> > Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it would
> > be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the
> > augment in ietf-ipv6-router-advertisements
> >
> >   augment "/if:interfaces-state/if:interface/ip:ipv6" { ... }
> >
> > needn't be changed.
>
> This would be an entirely different kind of mount!  The current mount
> doesn't work like that; it doesn't give you visibility into the
> combined models - by design.
>
>
> > The major problem with this IMO is that it needs a new YANG statement.
> >
> > >
> > >> In
> > >> today's proposal the only way to find the Yang-Mounts is to read it
> > >> from the live node.
> > >>
> > >> * OAM integrators or operators want to be able to write CLI scripts
> > >>   and Netconf messages without accessing (expensive) real nodes. For
> > >>   this they need to know the mounts
> > >> * We want to generate some fancy documentation from YANG automatically
> > >>   in design-time.
> > >
> > > In a way this is no different from the situation today - in order to
> > > learn what YANG modules a device supports you need to connect and
> > > parse the  message (or ietf-yang-library data in the near
> > > future).  This info could also be made available off-line in a file.
> >
> > Yup. So we just need some machine-readable description of the structure
> > of mounted schemas.
> >
> > >
> > > It should certainly be possible to define a file format that a device
> > > somehow could "publish" off-line that contained all the info that is
> > > available at run-time.  This file format could be exactly the same as
> > > you would get if you did a NETCONF  operation with some filter
> > > to only retreive the ietf-yang-library data at the mount points.
> >
> > Well, if you have multiple levels of mounts, it will get messy: you
> > wouldn't know which yang-library data belongs to which mount point.
>
> Why not - imagine that you do a full  on such a device, it will
> return the nested yang library data just fine.
>
>
> /martin
>
>
> > I believe some variation on YSDL could work, and as I wrote in another
> > thread, we could also incorporate datastores: after defining the
> > (multilevel) schemas, each datastore will get one assigned - and they
> > can also share them where needed.
> >
> > Lada
> >
> > >
> > >
> > >
> > > /martin
> > >
> > >
> > >>
> > >> * Many use cases 

Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

  
  
Hello Martin,
  As I see in your answer, you do not question that the design time
  mount is an important and possibly frequent use-case, and I
  certainly think it is. 
  I also found this on the Juniper website: What
are the benefits of a Juniper devices publishing Junos YANG
module off box?
  See other comments below.
  regards Balazs
  
  On 2016-08-26 10:21, Martin Bjorklund wrote:


  Hi,

[replying to the first post in this (old) thread; the thread got a bit
off-topic]

Balazs Lengyel  wrote:

  
Hello,

As I understand it, Schema-mount today does not support an important
use-case which we definitely need, but others also indicated they
want.

I want to specify off-line in design time which models will be mounted
where. Many of my nodes know in design-time what their model structure
will be, so I want a way to be able to document this in YANG.

  
  
I'd like to understand this use case in more detail.  You say that
that a "node knows in design-time" that YANG models it will use.  Thus
it seems natural to be able to specify which other modules to mount in
the YANG module itself.

The problem I see with this is that it is very limited to the use case
where each implementation defines its own YANG modules.  Suppose you
have such a model, for example:

   module A {
 ...
 mount ... {
   mount-module B;
   mount-module C;
 }
  }
  
[pseudo-code for module A that specifies that it mounts B and C]

Now, suppose you take this module A to another implementation, and it
needs to augment something into module C; essentially this means that
it would like to mount B, C and new module D.   This will not be
possible unless it modifies module A.

BALAZS: No you don't need to modify module A.   You can use a
separate file  
  to define mounting modD into modA.  Even my proposed
solution allows this.
module mount-list {
   import moduleA { prefix moda; }
   import moduleD {}

   // indicate that moduleD is mounted somewhere
   schema-mount moduleD {  
  // indicate where it is mounted
  schema-mount-target /moda:baseContainer ;
   }
}

  


  
In
today's proposal the only way to find the Yang-Mounts is to read it
from the live node.

* OAM integrators or operators want to be able to write CLI scripts
  and Netconf messages without accessing (expensive) real nodes. For
  this they need to know the mounts
* We want to generate some fancy documentation from YANG automatically
  in design-time.

  
  
In a way this is no different from the situation today - in order to
learn what YANG modules a device supports you need to connect and
parse the  message (or ietf-yang-library data in the near
future).  This info could also be made available off-line in a file.

BALAZS: actually it is made available in our case, also describing
support for features

  

It should certainly be possible to define a file format that a device
somehow could "publish" off-line that contained all the info that is
available at run-time.  This file format could be exactly the same as
you would get if you did a NETCONF  operation with some filter
to only retreive the ietf-yang-library data at the mount points.

BALAZS: That would be an INTERESTING idea for multiple reasons (and
I know some implementations who already do this). 
Some potential use-cases:
- Mount descriptors
- defining default security rules for Netconf-acm
- listing available notification streams
- listing supported modules & features from yang-library

  



/martin



  

* Many use cases need the possibility to mount schemas, but do not
  need the added complexity of schema changes in run-time.
  Notwithstanding the case of "YANG Features", for me the model schema
  is a mostly static description of a nodes capabilities. Most of the
  time I do not want to worry about the node changing its schema on
  the fly.


For this I propose 2 YANG extensions

extension schema-mount {
description "Indicates that a YANG Module is to be mounted into
another module.
The argument specifies the name of the module to be mounted.";
argument mounted-module;
}

extension schema-mount-target {
description "Specifies the target node under which a YANG module is to
be mounted.
The statement can only be used inside a schema-mount statement.
The argument follows the same rules as an augment statement's target.
argument target-node;
}

The two extension statements can be placed in a separate module or the
mounted module.

I don't insist on the solution, but I need the off-line/design-time
specification of yang-mount to be possible. IMHO the design-time mount
use-case is more important than the dynamic-mount.

regards Balazs
--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  

Re: [netmod] Design-Time schema mount

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Hi,
> >
> > [replying to the first post in this (old) thread; the thread got a bit
> > off-topic]
> >
> > Balazs Lengyel  wrote:
> >> Hello,
> >> 
> >> As I understand it, Schema-mount today does not support an important
> >> use-case which we definitely need, but others also indicated they
> >> want.
> >> 
> >> I want to specify off-line in design time which models will be mounted
> >> where. Many of my nodes know in design-time what their model structure
> >> will be, so I want a way to be able to document this in YANG.
> >
> > I'd like to understand this use case in more detail.  You say that
> > that a "node knows in design-time" that YANG models it will use.  Thus
> > it seems natural to be able to specify which other modules to mount in
> > the YANG module itself.
> 
> Did you have a chance to look into my slides from Berlin? I sketched some
> solutions there.

Well, that's a *solution*.  I'd like to understand the *problem* first ;)

> > The problem I see with this is that it is very limited to the use case
> > where each implementation defines its own YANG modules.  Suppose you
> > have such a model, for example:
> >
> >module A {
> >  ...
> >  mount ... {
> >mount-module B;
> >mount-module C;
> >  }
> >   }
> >   
> > [pseudo-code for module A that specifies that it mounts B and C]
> >
> > Now, suppose you take this module A to another implementation, and it
> > needs to augment something into module C; essentially this means that
> > it would like to mount B, C and new module D.   This will not be
> > possible unless it modifies module A.
> 
> Not necessarily, D could contain an augment with a target specified by a
> schema node identifier that uses nodes from both A and C.

Not if B and D are defined as standalone modules, e.g. if B is
ietf-interfaces and D is ietf-ip.

> Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it would
> be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the
> augment in ietf-ipv6-router-advertisements
> 
>   augment "/if:interfaces-state/if:interface/ip:ipv6" { ... }
> 
> needn't be changed.

This would be an entirely different kind of mount!  The current mount
doesn't work like that; it doesn't give you visibility into the
combined models - by design.


> The major problem with this IMO is that it needs a new YANG statement. 
> 
> >
> >> In
> >> today's proposal the only way to find the Yang-Mounts is to read it
> >> from the live node.
> >> 
> >> * OAM integrators or operators want to be able to write CLI scripts
> >>   and Netconf messages without accessing (expensive) real nodes. For
> >>   this they need to know the mounts
> >> * We want to generate some fancy documentation from YANG automatically
> >>   in design-time.
> >
> > In a way this is no different from the situation today - in order to
> > learn what YANG modules a device supports you need to connect and
> > parse the  message (or ietf-yang-library data in the near
> > future).  This info could also be made available off-line in a file.
> 
> Yup. So we just need some machine-readable description of the structure
> of mounted schemas.
> 
> >
> > It should certainly be possible to define a file format that a device
> > somehow could "publish" off-line that contained all the info that is
> > available at run-time.  This file format could be exactly the same as
> > you would get if you did a NETCONF  operation with some filter
> > to only retreive the ietf-yang-library data at the mount points.
> 
> Well, if you have multiple levels of mounts, it will get messy: you
> wouldn't know which yang-library data belongs to which mount point.

Why not - imagine that you do a full  on such a device, it will
return the nested yang library data just fine.


/martin


> I believe some variation on YSDL could work, and as I wrote in another
> thread, we could also incorporate datastores: after defining the
> (multilevel) schemas, each datastore will get one assigned - and they
> can also share them where needed.
> 
> Lada
> 
> >
> >
> >
> > /martin
> >
> >
> >> 
> >> * Many use cases need the possibility to mount schemas, but do not
> >>   need the added complexity of schema changes in run-time.
> >>   Notwithstanding the case of "YANG Features", for me the model schema
> >>   is a mostly static description of a nodes capabilities. Most of the
> >>   time I do not want to worry about the node changing its schema on
> >>   the fly.
> >> 
> >> 
> >> For this I propose 2 YANG extensions
> >> 
> >> extension schema-mount {
> >> description "Indicates that a YANG Module is to be mounted into
> >> another module.
> >> The argument specifies the name of the module to be mounted.";
> >> argument mounted-module;
> >> }
> >> 
> >> extension schema-mount-target {
> >> description "Specifies the target node under which a YANG module is to
> >> be 

Re: [netmod] Design-Time schema mount

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Hi,
>
> [replying to the first post in this (old) thread; the thread got a bit
> off-topic]
>
> Balazs Lengyel  wrote:
>> Hello,
>> 
>> As I understand it, Schema-mount today does not support an important
>> use-case which we definitely need, but others also indicated they
>> want.
>> 
>> I want to specify off-line in design time which models will be mounted
>> where. Many of my nodes know in design-time what their model structure
>> will be, so I want a way to be able to document this in YANG.
>
> I'd like to understand this use case in more detail.  You say that
> that a "node knows in design-time" that YANG models it will use.  Thus
> it seems natural to be able to specify which other modules to mount in
> the YANG module itself.

Did you have a chance to look into my slides from Berlin? I sketched some
solutions there.

>
> The problem I see with this is that it is very limited to the use case
> where each implementation defines its own YANG modules.  Suppose you
> have such a model, for example:
>
>module A {
>  ...
>  mount ... {
>mount-module B;
>mount-module C;
>  }
>   }
>   
> [pseudo-code for module A that specifies that it mounts B and C]
>
> Now, suppose you take this module A to another implementation, and it
> needs to augment something into module C; essentially this means that
> it would like to mount B, C and new module D.   This will not be
> possible unless it modifies module A.

Not necessarily, D could contain an augment with a target specified by a
schema node identifier that uses nodes from both A and C.

Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it would
be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the
augment in ietf-ipv6-router-advertisements

  augment "/if:interfaces-state/if:interface/ip:ipv6" { ... }

needn't be changed.

The major problem with this IMO is that it needs a new YANG statement. 

>
>> In
>> today's proposal the only way to find the Yang-Mounts is to read it
>> from the live node.
>> 
>> * OAM integrators or operators want to be able to write CLI scripts
>>   and Netconf messages without accessing (expensive) real nodes. For
>>   this they need to know the mounts
>> * We want to generate some fancy documentation from YANG automatically
>>   in design-time.
>
> In a way this is no different from the situation today - in order to
> learn what YANG modules a device supports you need to connect and
> parse the  message (or ietf-yang-library data in the near
> future).  This info could also be made available off-line in a file.

Yup. So we just need some machine-readable description of the structure
of mounted schemas.

>
> It should certainly be possible to define a file format that a device
> somehow could "publish" off-line that contained all the info that is
> available at run-time.  This file format could be exactly the same as
> you would get if you did a NETCONF  operation with some filter
> to only retreive the ietf-yang-library data at the mount points.

Well, if you have multiple levels of mounts, it will get messy: you
wouldn't know which yang-library data belongs to which mount point.

I believe some variation on YSDL could work, and as I wrote in another
thread, we could also incorporate datastores: after defining the
(multilevel) schemas, each datastore will get one assigned - and they
can also share them where needed.

Lada

>
>
>
> /martin
>
>
>> 
>> * Many use cases need the possibility to mount schemas, but do not
>>   need the added complexity of schema changes in run-time.
>>   Notwithstanding the case of "YANG Features", for me the model schema
>>   is a mostly static description of a nodes capabilities. Most of the
>>   time I do not want to worry about the node changing its schema on
>>   the fly.
>> 
>> 
>> For this I propose 2 YANG extensions
>> 
>> extension schema-mount {
>> description "Indicates that a YANG Module is to be mounted into
>> another module.
>> The argument specifies the name of the module to be mounted.";
>> argument mounted-module;
>> }
>> 
>> extension schema-mount-target {
>> description "Specifies the target node under which a YANG module is to
>> be mounted.
>> The statement can only be used inside a schema-mount statement.
>> The argument follows the same rules as an augment statement's target.
>> argument target-node;
>> }
>> 
>> The two extension statements can be placed in a separate module or the
>> mounted module.
>> 
>> I don't insist on the solution, but I need the off-line/design-time
>> specification of yang-mount to be possible. IMHO the design-time mount
>> use-case is more important than the dynamic-mount.
>> 
>> regards Balazs
>> --
>> Balazs Lengyel   Ericsson Hungary Ltd.
>> Senior Specialist
>> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>
> ___
> netmod mailing 

Re: [netmod] Design-Time schema mount

[Martin Bjorklund]

Hi,

[replying to the first post in this (old) thread; the thread got a bit
off-topic]

Balazs Lengyel  wrote:
> Hello,
> 
> As I understand it, Schema-mount today does not support an important
> use-case which we definitely need, but others also indicated they
> want.
> 
> I want to specify off-line in design time which models will be mounted
> where. Many of my nodes know in design-time what their model structure
> will be, so I want a way to be able to document this in YANG.

I'd like to understand this use case in more detail.  You say that
that a "node knows in design-time" that YANG models it will use.  Thus
it seems natural to be able to specify which other modules to mount in
the YANG module itself.

The problem I see with this is that it is very limited to the use case
where each implementation defines its own YANG modules.  Suppose you
have such a model, for example:

   module A {
 ...
 mount ... {
   mount-module B;
   mount-module C;
 }
  }
  
[pseudo-code for module A that specifies that it mounts B and C]

Now, suppose you take this module A to another implementation, and it
needs to augment something into module C; essentially this means that
it would like to mount B, C and new module D.   This will not be
possible unless it modifies module A.

> In
> today's proposal the only way to find the Yang-Mounts is to read it
> from the live node.
> 
> * OAM integrators or operators want to be able to write CLI scripts
>   and Netconf messages without accessing (expensive) real nodes. For
>   this they need to know the mounts
> * We want to generate some fancy documentation from YANG automatically
>   in design-time.

In a way this is no different from the situation today - in order to
learn what YANG modules a device supports you need to connect and
parse the  message (or ietf-yang-library data in the near
future).  This info could also be made available off-line in a file.

It should certainly be possible to define a file format that a device
somehow could "publish" off-line that contained all the info that is
available at run-time.  This file format could be exactly the same as
you would get if you did a NETCONF  operation with some filter
to only retreive the ietf-yang-library data at the mount points.



/martin


> 
> * Many use cases need the possibility to mount schemas, but do not
>   need the added complexity of schema changes in run-time.
>   Notwithstanding the case of "YANG Features", for me the model schema
>   is a mostly static description of a nodes capabilities. Most of the
>   time I do not want to worry about the node changing its schema on
>   the fly.
> 
> 
> For this I propose 2 YANG extensions
> 
> extension schema-mount {
> description "Indicates that a YANG Module is to be mounted into
> another module.
> The argument specifies the name of the module to be mounted.";
> argument mounted-module;
> }
> 
> extension schema-mount-target {
> description "Specifies the target node under which a YANG module is to
> be mounted.
> The statement can only be used inside a schema-mount statement.
> The argument follows the same rules as an augment statement's target.
> argument target-node;
> }
> 
> The two extension statements can be placed in a separate module or the
> mounted module.
> 
> I don't insist on the solution, but I need the off-line/design-time
> specification of yang-mount to be possible. IMHO the design-time mount
> use-case is more important than the dynamic-mount.
> 
> regards Balazs
> --
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] Design-Time schema mount

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Tue, Aug 02, 2016 at 01:12:34PM +0200, Ladislav Lhotka wrote:
>> 
>> Yes, but if the YANG version is bumped, the client can immediately see
>> that it is not compatible, and disconnect. In contrast, sec. 6.3.1 says
>> that an extension "MAY be ignored in its entirety". According to the
>> RFC 2119 semantics, doing so should not affect interoperability, which
>> is clearly not the case here.
>>
>
> This is apparently where views substantially differ; I do not consider
> it an interoperability failure if an old client does not understand a
> part of a datamodel of an updated server that the old client is not
> dealing with. For me, interoperability means that a server can upgrade
> while old clients continue to function as they did before. For me,
> interoperability does not mean that server and clients always have to
> be updated at the same time and it does not mean that a client needs
> to understand and support the entire set of datamodels exposed by a
> server.

If this was the only aspect of interoperability, then the best data
model would perhaps be just anydata at the top and nothing else.

In my view, it is the information from the data model that reduces
entropy and thus increases interoperability. Of course, it depends on
the purpose of the client but, in general, a client that understands
only a part of the data model is less interoperable with the given
server than a client that understands it fully.

Notwithstanding terminology, I think it is rather important to keep YANG
extensions strictly optional because otherwise we will see vendor
extensions that effectively limit the choice of clients and management
systems.

Lada

>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] Design-Time schema mount

[Juergen Schoenwaelder]

On Tue, Aug 02, 2016 at 01:12:34PM +0200, Ladislav Lhotka wrote:
> 
> Yes, but if the YANG version is bumped, the client can immediately see
> that it is not compatible, and disconnect. In contrast, sec. 6.3.1 says
> that an extension "MAY be ignored in its entirety". According to the
> RFC 2119 semantics, doing so should not affect interoperability, which
> is clearly not the case here.
>

This is apparently where views substantially differ; I do not consider
it an interoperability failure if an old client does not understand a
part of a datamodel of an updated server that the old client is not
dealing with. For me, interoperability means that a server can upgrade
while old clients continue to function as they did before. For me,
interoperability does not mean that server and clients always have to
be updated at the same time and it does not mean that a client needs
to understand and support the entire set of datamodels exposed by a
server.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Design-Time schema mount

[Ladislav Lhotka]

Balazs Lengyel  writes:

> Hello Lada,
>
> I see 2 statements in your mail:
>
> "Yes, but a client that doesn't understand them can still safely work
> with an NACM-aware server." 
> IMHO simply ignoring security information is not acceptable in any
> way. So the nacm extensions are not "optional" either.

Not really, there are no security implications because access control
policies are enforced at the server side. The client can use this
information for avoiding requests that result in access-denied error, or
perhaps reflect it in the user interface. 

>
> "The regular client doesn't know the mounted parts of the data model,
> so no automation is possible for this data."
> That to me says: a client who doesn't support schema-mount will not
> really understand schema-mount. True, but that is valid for any
> schema-mount solution, so if we want schema mount we must live with
> it.

Yes, but if the YANG version is bumped, the client can immediately see
that it is not compatible, and disconnect. In contrast, sec. 6.3.1 says
that an extension "MAY be ignored in its entirety". According to the
RFC 2119 semantics, doing so should not affect interoperability, which
is clearly not the case here.

>
> Do you have any better alternative than extensions? (For me run-time
> data or plain English text are worse.)

For me too. As I said, I would prefer some kind of meta-schema approach,
such as extending YANG library.

Lada

>
> Balazs
>
> On 2016-08-01 17:11, Ladislav Lhotka wrote:
>
> 
> 
> On 01 Aug 2016, at 16:09, Andy Bierman  wrote:
>
>
>
> On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka  wrote:
> Balazs Lengyel  writes:
>
> 
> Hello,
>
> As I understood Andy, it was already agreed that if you advertise
> support for a model that defines extensions you MUST support those
> extensions. So you effectively advertise support for those extensions.
>
> 
> OK, so let's say a server advertises "ietf-system" (that imports
> "ietf-netconf-acm") with conformance-type "implement" and
> "ietf-netconf-acm" with conformance-type "import". Does the server
> support "nacm:default-deny-*" extensions or not?
>
>
> The server is only claiming conformance on the modules that it implements.
> The YANG conformance model has issues.  This is not news.
>
> 
> My point was that "advertise" isn't sufficient.
>
> 
> 
>  
> Moreover, clients don't advertise any modules.
>
>
> not sure why this matters
>
> 
> If the server can learn what extensions this client supports, it could adjust 
> its behaviour (probably impossible for something like schema mount though).
>
> 
> 
>  
> 
> As an example if you claim support for nacm, you MUST support its
> extensions.
>
> 
> NACM is different in that the nacm:default-deny-* extensions just give
> auxiliary information - they help NACM-aware clients avoid sending
> requests that result in access-denied errors.
>
>
> they are quite clear wrt/ how a NACM implementation must treat the extensions.
>
> 
> Yes, but a client that doesn't understand them can still safely work with an 
> NACM-aware server.
>
> 
> 
>  
> In contrast, a client that doesn't support schema mount cannot be used
> with a server that does.
>
>
> why not?
>
>anydata mount-point {
>   mount:extension1;
>   mount:extension2;
>}
>
> A regular client will see an anydata node with schema-less child nodes.
> A mount-aware client will see a mount-point and know how to determine
> the schema for the child nodes of the mount-point.
>
> 
> The regular client doesn't know the mounted parts of the data model, so no 
> automation is possible for this data.
>
> Lada 
>
> 
> 
>
> Lada
>
> Andy
>  
>
> 
> 
> Balazs
>
>
> On 2016-07-29 15:31, Ladislav Lhotka wrote:
>
> 
> For this approach to work, we would need to change the 
> character of
> extensions, in particular:
>
> - an implementation should be able to signal which extensions are
>supported,
>
> - extensions that change the data model need to be labelled as mandatory
>to support.
>
> 
> --
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___

Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

  
  
Hello Lada,
I see 2 statements in your mail:
"Yes, but a client that doesn't understand them can still
safely work with an NACM-aware server."  
  IMHO simply ignoring security information is not acceptable in any
  way. So the nacm extensions are not "optional" either.
"The regular client doesn't know the mounted parts of the data
model, so no automation is possible for this data."
  That to me says: a client who doesn't support schema-mount will
  not really understand schema-mount. True, but that is valid for
  any schema-mount solution, so if we want schema mount we must live
  with it.
Do you have any better alternative than extensions?  (For me
  run-time data or plain English text are worse.)

Balazs


On 2016-08-01 17:11, Ladislav Lhotka
  wrote:


  

  
On 01 Aug 2016, at 16:09, Andy Bierman  wrote:



On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka  wrote:
Balazs Lengyel  writes:



  Hello,

As I understood Andy, it was already agreed that if you advertise
support for a model that defines extensions you MUST support those
extensions. So you effectively advertise support for those extensions.



OK, so let's say a server advertises "ietf-system" (that imports
"ietf-netconf-acm") with conformance-type "implement" and
"ietf-netconf-acm" with conformance-type "import". Does the server
support "nacm:default-deny-*" extensions or not?


The server is only claiming conformance on the modules that it implements.
The YANG conformance model has issues.  This is not news.

  
  
My point was that "advertise" isn't sufficient.


  

 
Moreover, clients don't advertise any modules.


not sure why this matters

  
  
If the server can learn what extensions this client supports, it could adjust its behaviour (probably impossible for something like schema mount though).


  

 


  As an example if you claim support for nacm, you MUST support its
extensions.



NACM is different in that the nacm:default-deny-* extensions just give
auxiliary information - they help NACM-aware clients avoid sending
requests that result in access-denied errors.


they are quite clear wrt/ how a NACM implementation must treat the extensions.

  
  
Yes, but a client that doesn't understand them can still safely work with an NACM-aware server.


  

 
In contrast, a client that doesn't support schema mount cannot be used
with a server that does.


why not?

   anydata mount-point {
  mount:extension1;
  mount:extension2;
   }

A regular client will see an anydata node with schema-less child nodes.
A mount-aware client will see a mount-point and know how to determine
the schema for the child nodes of the mount-point.

  
  
The regular client doesn't know the mounted parts of the data model, so no automation is possible for this data.

Lada 


  


Lada

Andy
 



  
Balazs


On 2016-07-29 15:31, Ladislav Lhotka wrote:

  
For this approach to work, we would need to change the character of
extensions, in particular:

- an implementation should be able to signal which extensions are
   supported,

- extensions that change the data model need to be labelled as mandatory
   to support.

  
  
--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com




--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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


  
  
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C








-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  


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

Re: [netmod] Design-Time schema mount

[Ladislav Lhotka]

> On 01 Aug 2016, at 16:09, Andy Bierman  wrote:
> 
> 
> 
> On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka  wrote:
> Balazs Lengyel  writes:
> 
> > Hello,
> >
> > As I understood Andy, it was already agreed that if you advertise
> > support for a model that defines extensions you MUST support those
> > extensions. So you effectively advertise support for those extensions.
> 
> OK, so let's say a server advertises "ietf-system" (that imports
> "ietf-netconf-acm") with conformance-type "implement" and
> "ietf-netconf-acm" with conformance-type "import". Does the server
> support "nacm:default-deny-*" extensions or not?
> 
> 
> The server is only claiming conformance on the modules that it implements.
> The YANG conformance model has issues.  This is not news.

My point was that "advertise" isn't sufficient.

> 
>  
> Moreover, clients don't advertise any modules.
> 
> 
> not sure why this matters

If the server can learn what extensions this client supports, it could adjust 
its behaviour (probably impossible for something like schema mount though).

> 
>  
> > As an example if you claim support for nacm, you MUST support its
> > extensions.
> 
> NACM is different in that the nacm:default-deny-* extensions just give
> auxiliary information - they help NACM-aware clients avoid sending
> requests that result in access-denied errors.
> 
> 
> they are quite clear wrt/ how a NACM implementation must treat the extensions.

Yes, but a client that doesn't understand them can still safely work with an 
NACM-aware server.

> 
>  
> In contrast, a client that doesn't support schema mount cannot be used
> with a server that does.
> 
> 
> why not?
> 
>anydata mount-point {
>   mount:extension1;
>   mount:extension2;
>}
> 
> A regular client will see an anydata node with schema-less child nodes.
> A mount-aware client will see a mount-point and know how to determine
> the schema for the child nodes of the mount-point.

The regular client doesn't know the mounted parts of the data model, so no 
automation is possible for this data.

Lada 

> 
> 
> Lada
> 
> Andy
>  
> 
> >
> > Balazs
> >
> >
> > On 2016-07-29 15:31, Ladislav Lhotka wrote:
> >> For this approach to work, we would need to change the character of
> >> extensions, in particular:
> >>
> >> - an implementation should be able to signal which extensions are
> >>supported,
> >>
> >> - extensions that change the data model need to be labelled as mandatory
> >>to support.
> >
> > --
> > Balazs Lengyel   Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> >
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] Design-Time schema mount

[Andy Bierman]

On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka  wrote:

> Balazs Lengyel  writes:
>
> > Hello,
> >
> > As I understood Andy, it was already agreed that if you advertise
> > support for a model that defines extensions you MUST support those
> > extensions. So you effectively advertise support for those extensions.
>
> OK, so let's say a server advertises "ietf-system" (that imports
> "ietf-netconf-acm") with conformance-type "implement" and
> "ietf-netconf-acm" with conformance-type "import". Does the server
> support "nacm:default-deny-*" extensions or not?
>
>
The server is only claiming conformance on the modules that it implements.
The YANG conformance model has issues.  This is not news.



> Moreover, clients don't advertise any modules.
>
>
not sure why this matters



> > As an example if you claim support for nacm, you MUST support its
> > extensions.
>
> NACM is different in that the nacm:default-deny-* extensions just give
> auxiliary information - they help NACM-aware clients avoid sending
> requests that result in access-denied errors.
>
>
they are quite clear wrt/ how a NACM implementation must treat the
extensions.



> In contrast, a client that doesn't support schema mount cannot be used
> with a server that does.
>
>
why not?

   anydata mount-point {
  mount:extension1;
  mount:extension2;
   }

A regular client will see an anydata node with schema-less child nodes.
A mount-aware client will see a mount-point and know how to determine
the schema for the child nodes of the mount-point.


Lada
>

Andy


>
> >
> > Balazs
> >
> >
> > On 2016-07-29 15:31, Ladislav Lhotka wrote:
> >> For this approach to work, we would need to change the character of
> >> extensions, in particular:
> >>
> >> - an implementation should be able to signal which extensions are
> >>supported,
> >>
> >> - extensions that change the data model need to be labelled as mandatory
> >>to support.
> >
> > --
> > Balazs Lengyel   Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> ___
> 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

Re: [netmod] Design-Time schema mount

[Ladislav Lhotka]

Balazs Lengyel  writes:

> Hello,
>
> As I understood Andy, it was already agreed that if you advertise 
> support for a model that defines extensions you MUST support those 
> extensions. So you effectively advertise support for those extensions.

OK, so let's say a server advertises "ietf-system" (that imports
"ietf-netconf-acm") with conformance-type "implement" and
"ietf-netconf-acm" with conformance-type "import". Does the server
support "nacm:default-deny-*" extensions or not?

Moreover, clients don't advertise any modules.

> As an example if you claim support for nacm, you MUST support its 
> extensions.

NACM is different in that the nacm:default-deny-* extensions just give
auxiliary information - they help NACM-aware clients avoid sending
requests that result in access-denied errors.

In contrast, a client that doesn't support schema mount cannot be used
with a server that does.

Lada

>
> Balazs
>
>
> On 2016-07-29 15:31, Ladislav Lhotka wrote:
>> For this approach to work, we would need to change the character of
>> extensions, in particular:
>>
>> - an implementation should be able to signal which extensions are
>>supported,
>>
>> - extensions that change the data model need to be labelled as mandatory
>>to support.
>
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

Hello,

As I understood Andy, it was already agreed that if you advertise 
support for a model that defines extensions you MUST support those 
extensions. So you effectively advertise support for those extensions. 
As an example if you claim support for nacm, you MUST support its 
extensions.


Balazs


On 2016-07-29 15:31, Ladislav Lhotka wrote:

For this approach to work, we would need to change the character of
extensions, in particular:

- an implementation should be able to signal which extensions are
   supported,

- extensions that change the data model need to be labelled as mandatory
   to support.


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] Design-Time schema mount

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Thu, Jul 28, 2016 at 04:14:42PM +0200, Ladislav Lhotka wrote:
>> 
>> We could define it using built-in statements, and bump YANG version number. 
>> I don't get why this is worse that introducing "standard extensions", except 
>> at Layer 8 (Political) - we can claim that YANG is stable even though it 
>> isn't.
>>
>
> - Running a document of the size and complexity of the YANG
>   specification through the IETF and publication process is expensive.

This is just a procedural issue. Updates to some protocols (e.g. OSPFv3)
were specified as a diff.

>
> - It is not clear at this point in time that YANG mounts are required
>   to be supported everywhere.

Well, we already have things in base YANG that arguably aren't required
to be supported everywhere, for example notifications or actions.

But either way - if an implementation doesn't support a fundamental data
modelling function that's used in a module, then this implementation
cannot use this module, no matter whether the function is implemented as
built-in or extension.

>
> - It is up to this WG to keep YANG 1.1 stable. Claiming YANG isn't
>   stable as a justification to make it not stable is a somewhat
>   circular logic.

I don't see anything circular here. If any implementor can randomly
choose from a host of extensions, there will be no standard YANG at
all. We all remember browser wars, right? They were caused by extensions
to web standards. I am concerned that this can easily happen here, too. 

>
> I strongly believe that it is feature to work with extensions wherever
> possible. Gain experience with language extensions first and if they
> are widely deployed and used, consider to move them into the core at
> some point in time. I believe it is desirable to keep the complexity
> of the core YANG language somewhat under control.

For this approach to work, we would need to change the character of
extensions, in particular:

- an implementation should be able to signal which extensions are
  supported,

- extensions that change the data model need to be labelled as mandatory
  to support. 

Lada

>
> You likely won't agree with any of this and this is fine. But I also
> do not agree with your statement that working with extensions is just
> a layer 8 (political) issue.
>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] Design-Time schema mount

[Andy Bierman]

On Thu, Jul 28, 2016 at 9:00 AM, Balazs Lengyel  wrote:

>
>
> On 2016-07-28 17:13, Robert Wilton wrote:
>
>> On 28/07/2016 15:51, Juergen Schoenwaelder wrote:
>>
>> One issue I see is that extensions are effectively required to be
>> optional, allowing tooling to ignore them if they wish.  This seems to
>> hamper their usefulness in some scenarios.
>>
> BALAZS: Any better ideas? IMHO if you want to support yang-mount you will
> support the needed extensions.
>
>>
>> For the example given here, I feel that something stronger would be
>> useful, i.e. an extension that must be implemented by the tooling for the
>> particular YANG module to make sense.
>>
>> Perhaps when a module includes an extension it could indicate whether
>> support for that extension is regarded as required for the module to be
>> useful, or conversely if the module is still sane even if support for the
>> extension isn't implemented.
>>
> BALAZS: Agree, in the RFC text or in the extension's description we could
> indicate whether it is mandatory to support the extension in order to
> support the module.
> Or we could add a formal statement, but no updates to YANG, so add an
> extension to indicate this, and we are back in to step one.
> By the way we already have IETF-defined extensions in nacm. Is it
> mandatory to support those? IMHO no.
>
>>
>>
Actually we have been over this issue many times already with YANG 1.1.

An implementation that claims conformance to NACM MUST implement the
extensions defined for NACM (default-deny-write, default-deny-all).
A generic tool that claims to support YANG does not need to claim
conformance to NACM and therefore does not need to implement the NACM
extensions.




> Thanks,
>> Rob
>>
>
>

Andy


> --
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>
> ___
> 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

Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

  
  
Hello,
I agree that revising the RFC6020bis) now is not the way to go.
  But if we want schema-mount we need a solution. Both for the
  current provisional proposal and for design-time mount yang
  extensions are used.  IMHO this is a viable solution and a much
  better one then putting all information about mounting into plain
  English or run-time data. 

regards Balazs


On 2016-07-28 17:14, Andy Bierman
  wrote:


  
  Hi,


+1 to concerns about stability.




Andy





  
On Thu, Jul 28, 2016 at 7:51 AM,
  Juergen Schoenwaelder 
  wrote:
  On
Thu, Jul 28, 2016 at 04:14:42PM +0200, Ladislav Lhotka
wrote:
>
> We could define it using built-in statements, and
bump YANG version number. I don't get why this is worse
that introducing "standard extensions", except at Layer
8 (Political) - we can claim that YANG is stable even
though it isn't.
>

- Running a document of the size and complexity of the
YANG
  specification through the IETF and publication process
is expensive.

- It is not clear at this point in time that YANG mounts
are required
  to be supported everywhere.

- It is up to this WG to keep YANG 1.1 stable. Claiming
YANG isn't
  stable as a justification to make it not stable is a
somewhat
  circular logic.

I strongly believe that it is feature to work with
extensions wherever
possible. Gain experience with language extensions first
and if they
are widely deployed and used, consider to move them into
the core at
some point in time. I believe it is desirable to keep
the complexity
of the core YANG language somewhat under control.

You likely won't agree with any of this and this is
fine. But I also
do not agree with your statement that working with
extensions is just
a layer 8 (political) issue.

/js

--
Juergen Schoenwaelder           Jacobs University
Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 |
28759 Bremen | Germany
Fax:   +49 421 200 3103         

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


  

  


-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  


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

Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

On 2016-07-28 17:13, Robert Wilton wrote:

On 28/07/2016 15:51, Juergen Schoenwaelder wrote:

One issue I see is that extensions are effectively required to be 
optional, allowing tooling to ignore them if they wish.  This seems to 
hamper their usefulness in some scenarios.
BALAZS: Any better ideas? IMHO if you want to support yang-mount you 
will support the needed extensions.


For the example given here, I feel that something stronger would be 
useful, i.e. an extension that must be implemented by the tooling for 
the particular YANG module to make sense.


Perhaps when a module includes an extension it could indicate whether 
support for that extension is regarded as required for the module to 
be useful, or conversely if the module is still sane even if support 
for the extension isn't implemented.
BALAZS: Agree, in the RFC text or in the extension's description we 
could indicate whether it is mandatory to support the extension in order 
to support the module.
Or we could add a formal statement, but no updates to YANG, so add an 
extension to indicate this, and we are back in to step one.
By the way we already have IETF-defined extensions in nacm. Is it 
mandatory to support those? IMHO no.


Thanks,
Rob


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] Design-Time schema mount

[Andy Bierman]

Hi,

+1 to concerns about stability.


Andy




On Thu, Jul 28, 2016 at 7:51 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Jul 28, 2016 at 04:14:42PM +0200, Ladislav Lhotka wrote:
> >
> > We could define it using built-in statements, and bump YANG version
> number. I don't get why this is worse that introducing "standard
> extensions", except at Layer 8 (Political) - we can claim that YANG is
> stable even though it isn't.
> >
>
> - Running a document of the size and complexity of the YANG
>   specification through the IETF and publication process is expensive.
>
> - It is not clear at this point in time that YANG mounts are required
>   to be supported everywhere.
>
> - It is up to this WG to keep YANG 1.1 stable. Claiming YANG isn't
>   stable as a justification to make it not stable is a somewhat
>   circular logic.
>
> I strongly believe that it is feature to work with extensions wherever
> possible. Gain experience with language extensions first and if they
> are widely deployed and used, consider to move them into the core at
> some point in time. I believe it is desirable to keep the complexity
> of the core YANG language somewhat under control.
>
> You likely won't agree with any of this and this is fine. But I also
> do not agree with your statement that working with extensions is just
> a layer 8 (political) issue.
>
> /js
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> 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

Re: [netmod] Design-Time schema mount

[Robert Wilton]

On 28/07/2016 15:51, Juergen Schoenwaelder wrote:

On Thu, Jul 28, 2016 at 04:14:42PM +0200, Ladislav Lhotka wrote:

We could define it using built-in statements, and bump YANG version number. I don't get 
why this is worse that introducing "standard extensions", except at Layer 8 
(Political) - we can claim that YANG is stable even though it isn't.


- Running a document of the size and complexity of the YANG
   specification through the IETF and publication process is expensive.

- It is not clear at this point in time that YANG mounts are required
   to be supported everywhere.

- It is up to this WG to keep YANG 1.1 stable. Claiming YANG isn't
   stable as a justification to make it not stable is a somewhat
   circular logic.

I strongly believe that it is feature to work with extensions wherever
possible. Gain experience with language extensions first and if they
are widely deployed and used, consider to move them into the core at
some point in time. I believe it is desirable to keep the complexity
of the core YANG language somewhat under control.

I agree with this point (and also the similar one that Balazs made).

One issue I see is that extensions are effectively required to be 
optional, allowing tooling to ignore them if they wish.  This seems to 
hamper their usefulness in some scenarios.


For the example given here, I feel that something stronger would be 
useful, i.e. an extension that must be implemented by the tooling for 
the particular YANG module to make sense.


Perhaps when a module includes an extension it could indicate whether 
support for that extension is regarded as required for the module to be 
useful, or conversely if the module is still sane even if support for 
the extension isn't implemented.


Thanks,
Rob




You likely won't agree with any of this and this is fine. But I also
do not agree with your statement that working with extensions is just
a layer 8 (political) issue.

/js



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

Re: [netmod] Design-Time schema mount

[Juergen Schoenwaelder]

On Thu, Jul 28, 2016 at 04:14:42PM +0200, Ladislav Lhotka wrote:
> 
> We could define it using built-in statements, and bump YANG version number. I 
> don't get why this is worse that introducing "standard extensions", except at 
> Layer 8 (Political) - we can claim that YANG is stable even though it isn't.
>

- Running a document of the size and complexity of the YANG
  specification through the IETF and publication process is expensive.

- It is not clear at this point in time that YANG mounts are required
  to be supported everywhere.

- It is up to this WG to keep YANG 1.1 stable. Claiming YANG isn't
  stable as a justification to make it not stable is a somewhat
  circular logic.

I strongly believe that it is feature to work with extensions wherever
possible. Gain experience with language extensions first and if they
are widely deployed and used, consider to move them into the core at
some point in time. I believe it is desirable to keep the complexity
of the core YANG language somewhat under control.

You likely won't agree with any of this and this is fine. But I also
do not agree with your statement that working with extensions is just
a layer 8 (political) issue.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

  
  
Hello Lada,
I want a formal way to define mount data. I want tools to
  understand it, so RFC text or an unspecified file  is a not a good
  solution. 

We could have described any data model in plain English. The
  whole point of YANG is to have a formal definition. If containing
  one container in another is described in a formal way why is
  containing a full module in a container less important? 

My solution would only use standard YANG files with a well
  specified content. I need the same level of precision from any
  alternative.

Balazs


On 2016-07-28 16:14, Ladislav Lhotka
  wrote:


  
Solution: My problem is that the specific data in the yang-library or in ietf-yang-schema-mount is only defined and available in run-time, so I don't understand how it could solve the design-time schema-mount requirement. IMHO whatever the solution, it needs to be in a file.

  
  YANG library data can appear in the RFC text, in a file, or elsewhere off line.

We could do the same with "mount-points" data as defined in draft-ietf-netmod-schema-mount-02 but only with one level of mounts. 




-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  


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

Re: [netmod] Design-Time schema mount

[Ladislav Lhotka]

> On 28 Jul 2016, at 15:30, Balazs Lengyel  wrote:
> 
> Hello,
> 
> Yes this is similar to your proposal, so we should be able to hammer out 
> something.
> 
> I am happy to see you agree that this is an important use-case, YANG needs to 
> support.
> 
> Solution: My problem is that the specific data in the yang-library or in 
> ietf-yang-schema-mount is only defined and available in run-time, so I don't 
> understand how it could solve the design-time schema-mount requirement. IMHO 
> whatever the solution, it needs to be in a file.

YANG library data can appear in the RFC text, in a file, or elsewhere off line.

We could do the same with "mount-points" data as defined in 
draft-ietf-netmod-schema-mount-02 but only with one level of mounts. 

> 
> Procedure: I assume we will not update the YANG language in the next year or 
> more, so I don't see what else can we do beside yang-extensions.

We could define it using built-in statements, and bump YANG version number. I 
don't get why this is worse that introducing "standard extensions", except at 
Layer 8 (Political) - we can claim that YANG is stable even though it isn't.

> In one other modeling environment it is common practice, that new modeling 
> concepts are first introduced as extensions, then at every release of the 
> model language the important extensions are incorporated as proper language 
> statements. This gives a fast path to implement new things, provides a method 
> to "experiment" with new things and to do a shake-down on new things before 
> they are incorporated into the modeling language. Again I don't insist on 
> extensions, but what is the alternative?

We could do that, but it would require to change the character of extensions as 
something that implementations can ignore. Some upfront signalling that an 
implementation isn't using standard YANG would also be useful.

Lada

> 
> Balazs
> 
> 
> On 2016-07-28 15:05, Ladislav Lhotka wrote:
>> Hi Balazs,
>> 
>> I agree with you, we need a machine-readable offline specification of
>> the entire schema. After Martin returns from his vacation, I plan to
>> discuss this with him.
>> 
>> Some comments are inline.
>> 
>> Balazs Lengyel  writes:
>> 
>>> Hello,
>>> 
>>> As I understand it, Schema-mount today does not support an important
>>> use-case which we definitely need, but others also indicated they
>>> want.
>>> 
>>> I want to specify off-line in design time which models will be mounted
>>> where. Many of my nodes know in design-time what their model structure
>>> will be, so I want a way to be able to document this in YANG. In
>>> today's proposal the only way to find the Yang-Mounts is to read it
>>> from the live node.
>>> 
>>> * OAM integrators or operators want to be able to write CLI scripts
>>>   and Netconf messages without accessing (expensive) real nodes. For
>>>   this they need to know the mounts
>>> * We want to generate some fancy documentation from YANG automatically
>>>   in design-time.
>> In fact, I met several people in Berlin that expect to be able to
>> standardise data models utilising schema-mount.
>> 
>>>   * Many use cases need the possibility to mount schemas, but do not
>>>   need the added complexity of schema changes in run-time.
>>>   Notwithstanding the case of "YANG Features", for me the model schema
>>>   is a mostly static description of a nodes capabilities. Most of the
>>>   time I do not want to worry about the node changing its schema on
>>>   the fly.
>>>   
>>> For this I propose 2 YANG extensions
>>> 
>>> extension schema-mount {
>>> description "Indicates that a YANG Module is to be mounted into
>>> another module.
>>> The argument specifies the name of the module to be mounted.";
>>> argument mounted-module;
>>> }
>>> 
>>> extension schema-mount-target {
>>> description "Specifies the target node under which a YANG module is to
>>> be mounted.
>>> The statement can only be used inside a schema-mount statement.
>>> The argument follows the same rules as an augment statement's target.
>>> argument target-node;
>>> }
>> This looks similar to the RELAX NG "external" pattern that I briefly
>> described in slide 9 of my presentation in Berlin:
>> 
>> https://www.ietf.org/proceedings/96/slides/slides-96-netmod-7.pdf
>> 
>> However, I am not in favour of introducing extesions for such
>> fundamental data modelling functions because doing so undermines the
>> value of YANG as a standard.
>> 
>> That's why I would prefer to use a solution based on a meta-schema
>> language (see my slide 10). After all, YANG library in fact already is a
>> meta-schema language, so we could just extend it to support schema
>> mount.
>> 
>> Lada
>> 
>>> The two extension statements can be placed in a separate module or the
>>> mounted module.
>>> 
>>> I don't insist on the solution, but I need the off-line/design-time
>>> specification of yang-mount to be possible. IMHO the design-time mount
>>> use-case is more 

Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

Hello,

Yes this is similar to your proposal, so we should be able to hammer out 
something.


I am happy to see you agree that this is an important use-case, YANG 
needs to support.


Solution: My problem is that the specific data in the yang-library or in 
ietf-yang-schema-mount is only defined and available in run-time, so I 
don't understand how it could solve the design-time schema-mount 
requirement. IMHO whatever the solution, it needs to be in a file.


Procedure: I assume we will not update the YANG language in the next 
year or more, so I don't see what else can we do beside yang-extensions.
In one other modeling environment it is common practice, that new 
modeling concepts are first introduced as extensions, then at every 
release of the model language the important extensions are incorporated 
as proper language statements. This gives a fast path to implement new 
things, provides a method to "experiment" with new things and to do a 
shake-down on new things before they are incorporated into the modeling 
language. Again I don't insist on extensions, but what is the alternative?


Balazs


On 2016-07-28 15:05, Ladislav Lhotka wrote:

Hi Balazs,

I agree with you, we need a machine-readable offline specification of
the entire schema. After Martin returns from his vacation, I plan to
discuss this with him.

Some comments are inline.

Balazs Lengyel  writes:


Hello,

As I understand it, Schema-mount today does not support an important
use-case which we definitely need, but others also indicated they
want.

I want to specify off-line in design time which models will be mounted
where. Many of my nodes know in design-time what their model structure
will be, so I want a way to be able to document this in YANG. In
today's proposal the only way to find the Yang-Mounts is to read it
from the live node.

* OAM integrators or operators want to be able to write CLI scripts
   and Netconf messages without accessing (expensive) real nodes. For
   this they need to know the mounts
* We want to generate some fancy documentation from YANG automatically
   in design-time.

In fact, I met several people in Berlin that expect to be able to
standardise data models utilising schema-mount.

   
* Many use cases need the possibility to mount schemas, but do not

   need the added complexity of schema changes in run-time.
   Notwithstanding the case of "YANG Features", for me the model schema
   is a mostly static description of a nodes capabilities. Most of the
   time I do not want to worry about the node changing its schema on
   the fly.
   


For this I propose 2 YANG extensions

extension schema-mount {
description "Indicates that a YANG Module is to be mounted into
another module.
The argument specifies the name of the module to be mounted.";
argument mounted-module;
}

extension schema-mount-target {
description "Specifies the target node under which a YANG module is to
be mounted.
The statement can only be used inside a schema-mount statement.
The argument follows the same rules as an augment statement's target.
argument target-node;
}

This looks similar to the RELAX NG "external" pattern that I briefly
described in slide 9 of my presentation in Berlin:

https://www.ietf.org/proceedings/96/slides/slides-96-netmod-7.pdf

However, I am not in favour of introducing extesions for such
fundamental data modelling functions because doing so undermines the
value of YANG as a standard.

That's why I would prefer to use a solution based on a meta-schema
language (see my slide 10). After all, YANG library in fact already is a
meta-schema language, so we could just extend it to support schema
mount.

Lada


The two extension statements can be placed in a separate module or the
mounted module.

I don't insist on the solution, but I need the off-line/design-time
specification of yang-mount to be possible. IMHO the design-time mount
use-case is more important than the dynamic-mount.

regards Balazs
--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] Design-Time schema mount

[Ladislav Lhotka]

Hi Balazs,

I agree with you, we need a machine-readable offline specification of
the entire schema. After Martin returns from his vacation, I plan to
discuss this with him.

Some comments are inline.

Balazs Lengyel  writes:

> Hello,
>
> As I understand it, Schema-mount today does not support an important
> use-case which we definitely need, but others also indicated they
> want.
>
> I want to specify off-line in design time which models will be mounted
> where. Many of my nodes know in design-time what their model structure
> will be, so I want a way to be able to document this in YANG. In
> today's proposal the only way to find the Yang-Mounts is to read it
> from the live node.
>
> * OAM integrators or operators want to be able to write CLI scripts
>   and Netconf messages without accessing (expensive) real nodes. For
>   this they need to know the mounts 
> * We want to generate some fancy documentation from YANG automatically
>   in design-time.

In fact, I met several people in Berlin that expect to be able to
standardise data models utilising schema-mount.

>   
> * Many use cases need the possibility to mount schemas, but do not
>   need the added complexity of schema changes in run-time.
>   Notwithstanding the case of "YANG Features", for me the model schema
>   is a mostly static description of a nodes capabilities. Most of the
>   time I do not want to worry about the node changing its schema on
>   the fly.
>   
>
> For this I propose 2 YANG extensions
>
> extension schema-mount {
> description "Indicates that a YANG Module is to be mounted into
> another module.
> The argument specifies the name of the module to be mounted.";
> argument mounted-module;
> }
>
> extension schema-mount-target {
> description "Specifies the target node under which a YANG module is to
> be mounted.
> The statement can only be used inside a schema-mount statement.
> The argument follows the same rules as an augment statement's target.
> argument target-node;
> }

This looks similar to the RELAX NG "external" pattern that I briefly
described in slide 9 of my presentation in Berlin:

https://www.ietf.org/proceedings/96/slides/slides-96-netmod-7.pdf

However, I am not in favour of introducing extesions for such
fundamental data modelling functions because doing so undermines the
value of YANG as a standard.

That's why I would prefer to use a solution based on a meta-schema
language (see my slide 10). After all, YANG library in fact already is a
meta-schema language, so we could just extend it to support schema
mount.

Lada

>
> The two extension statements can be placed in a separate module or the
> mounted module.
>
> I don't insist on the solution, but I need the off-line/design-time
> specification of yang-mount to be possible. IMHO the design-time mount
> use-case is more important than the dynamic-mount.
>
> regards Balazs
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

[netmod] Design-Time schema mount

[Balazs Lengyel]

  
  
Hello,
As I understand it, Schema-mount today does not support an
  important use-case which we definitely need, but others also
  indicated they want.
I want to specify off-line in design time which models will be
  mounted where. Many of my nodes know in design-time what their
  model structure will be, so I want a way to be able to document
  this in YANG. In today's proposal the only way to find the
  Yang-Mounts is to read it from the live node.


  OAM integrators or operators want to be able to write CLI
scripts and Netconf messages without accessing (expensive) real
nodes. For this they need to know the mounts
  We want to generate some fancy documentation from YANG
automatically in design-time. 
  
  Many use cases need the possibility to mount schemas, but do
not need the added complexity of schema changes in run-time.
Notwithstanding the case of "YANG Features", for me the model
schema is a mostly static description of a nodes capabilities.
Most of the time I do not want to worry about the node changing
its schema on the fly.
  

For this I propose 2 YANG extensions

extension schema-mount {
    description "Indicates that a YANG Module is to be
  mounted into another module.
    The argument specifies the name of the module to be
  mounted.";
      argument mounted-module;
  }
  
  extension schema-mount-target {
      description "Specifies the target node under which a YANG
  module is to be mounted.
      The statement can only be used inside a schema-mount
  statement.
      The argument follows the same rules as an augment
  statement's target.
    argument target-node;
  }
  
  The two extension statements can be placed in a separate module or
  the mounted module.
    
I don't insist on the solution, but I need the
off-line/design-time specification of yang-mount to be possible.
  IMHO the design-time mount use-case is more important than the
  dynamic-mount.
  
regards Balazs
-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  


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