[netmod] Updated YANG Datastore Design Team

[Lou Berger]

All,

The NETMOD Working Group has formed the Updated YANG Datastore Design Team. 
The mandate for the DT is to build on the drafts [1] and [2] and 
discussions related to using a conceptual datastore-based approach to 
support  vs  configuration, and deliver a baseline 
individual draft for discussion by the Working Group prior to the next IETF 
(IETF 97, Seoul). The proposed solution should also take into consideration 
support for ephemeral state as documented by the I2RS Working Group. The 
published individual draft will be discussed and progressed per normal WG 
process.


The DT has limited membership and will choose how it works to produce its 
draft. For example, the DT may choose to publicize their calls/progress or 
not. We recognize that not all who have contributed to this discussion are 
identified as DT members. Those who are willing to provide input to the DT 
should contact them directly. The DT mailing list is netmod-ds...@ietf.org. 
Keep in mind that there will be plenty of opportunity for input, per normal 
WG process, once the DT's individual draft is published and once there is a 
WG draft accepted on this topic.


The members of the DT are:
Martin Bjorklund 
Christian Hopps 
Juergen Schoenwaelder 
Phil Shafer  -- Lead
Robert Wilton 

[1] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores
[2] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores

Lou and Kent



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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Rob Shakir]

Balazs,

> On 2 Aug, 2016, at 10:29 AM, Balazs Lengyel  
> wrote:
> I prefer a tight definition so even if we allow both 1) and 2)  we should 
> state that other combinations e.g. trees spliting close to the leaves or a 
> mix of 1) and 2) in the same module are not allowed (VER STRONGLY 
> discouraged). 

What is the motivation for this very strongly discouraged statement? The 
problem I take with this is that you are not only getting zero consistency that 
will let a user determine how a model might look  (painful for those actually 
*using the models* rather than writing them - who are hugely under-represented 
in this discussion), but you’re also throwing out a bunch of models (both 
inside and outside of the IETF) at the same time.

Apologies to pick specifically on this email, but I have still yet to see any 
justification why anything other than a solution that is already being 
implemented is preferable to this WG other than it seeming like the WG doesn’t 
like the aesthetics of the modules in this case.

I am soon going to shut up on this topic, but it’s quite frankly lamentable 
that such a division is being created with no reasonable justification.

Note that the statement that Benoit/Lou/Kent made in Berlin related to applied 
config - the structure that is being objected to can be trivially implemented 
without those leaves if one wanted to.

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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Balazs Lengyel]

  
  
I don't know if we can make them a rule, but IMHO single-rooted
  modules are definitely easier to use. E.g. just as a single
  example: we only need one set of access control rules. Similar
  double handling is needed often.  I don't like foo-state trees.

Balazs


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


  
  
  
  
  On 27/07/2016 20:44, Acee Lindem
(acee) wrote:
  
  





   From: netmod 
on behalf of Mahesh Jethanandani 
Date: Wednesday, July
27, 2016 at 9:07 PM
To: Xufeng Liu 
Cc: netmod WG 
Subject: Re: [netmod]
OpsState Direction Impact on Recommended IETF YANG Model
Structure
  
  
  
  

  
Robert mentions IS-IS, and if I look at OSPF, I see a
clear separation of rw and ro nodes. 

  



Right - and this separation is based on the routing and
  routing-state split in the ietf-routing-cfg model. In general,
  ietf-routing-cfg specifies that all control plane protocol
  YANG models should adapt this structure. Anyone who thinks
  collapsing all the models one config/state tree is simply a
  matter of moving a few counters should taking a better look at
  the existing drafts. I outlined the options in the E-mail
  thread prior to IETF 96.  Now, with the context of IETF 96
  behind us, I believe more NETMOD participants will understand
  the options. To review the options specified in the previous
  E-mail thread. 



  
   1. Do nothing - allow them proceed as they are with
  multiple ways of
       representing the applied configuration. This
  would provide visibility to
       the data independent of whether or not the
  device supported the revised 
       data-stores supporting implicit retrieval of the
  applied configuration.
   2. Prune out the redundant data nodes except those
  required as list
        keys, etc, since they can be obtained from the
  applied state data store.
  3. #2 plus collapse the config (read-write) and
   system-state
       (read-only) into common containers. No more
  branching of
       -config and
  -state at the top level of the model.
  



Prior to IETF 96, I don’t believe we had selected a
  direction. However, I believe we agreed on option #1 in order
  to allow the publication of these models within the next year.
  We’d still be able to avail the benefits of applied vs
  intended configuration on network devices supporting these
  data stores. 

  
  My take is that I think that the leaning at IETF was towards 2.
  
  I.e. I think that we ruled out 1.  I.e. the models must not have
  separate nodes to represent applied configuration because that
  will be solved by the datastore solution.
  
  But it feels a bit inconsistent that the models don't need to have
  explicit leaves for foo vs foo-applied (because it will be solved
  by datastores), but the models do still need explicit leaves for
  foo vs foo-state (even though this could/should also be solved by
  an operational state datastore - noting that both draft-schoenw
  and draft-wilton propose a solution to this problem).
  
  My preference, if we can get quick consensus would be to do 3, or
  if consensus is not possible for 3, then we should fallback to
  doing 2, as the next best option.  But whatever the decision, I
  favour agreeing a direction quickly so that the other WGs know
  what to put in the RFCs.
  
  Thanks,
  Rob
  
  


Thanks,
Acee 







  

  


  

  On Jul 27, 2016, at 11:22 AM, Xufeng
Liu 
wrote:
  
  

   The assumption of “I
suspect that all the routing models will be
structured similarly” is not correct. Very
few models in routing area structure this
 

[netmod] OpsState and Schema-Mount

[Balazs Lengyel]

Hello,
If we allow foo and foo-state for opstate, mounting models atop such a 
multi rooted yang module will be fun.

mount modB-config-part onto modA-config-part
mount modB-state-part onto modA-state-part
One mount becomes two and you have to maintain parallel mounts otherwise 
you are mounting half modules.


Actually the problem is not caused by opstate, but rather by 
multi-rooted models. but avoiding foo-state would make life easier once 
more.


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] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Balazs Lengyel]

  
  
Hello,
Later I will try to provide a text proposal as well, but some
  points:

  I prefer a tight definition so even if we allow both 1) and
2)  we should state that other combinations e.g. trees spliting
close to the leaves or a mix of 1) and 2) in the same module are
not allowed (VER STRONGLY discouraged). 
  
  In one of the earlier mails there was a a statement: if we
have foo and foo-state trees, the containers/list/key-leafs
SHOULD be the same in the two. The structures of the two trees
SHOULD not just be si,i;ar, they should be the same.

This way you could look at the root objects of the module and
  immediately know what is the situation.
regards Balazs




On 2016-07-29 18:32, Juergen
  Schoenwaelder wrote:


  On Fri, Jul 29, 2016 at 04:35:05PM +0100, Robert Wilton wrote:
 

  
I would like to know what should the common approach for IETF standard
models be?  E.g. is it one of the following:

1) All config false leaves for foo must go under /foo-state.

  
  
I think if you have /foo-state, then this is a logical consequence. Do
we have any data models that have a /foo-state tree and config false
nodes under the /foo tree?


  
2) All config false leaves for foo must go under /foo

  
  
This apparently does not make sense in certain circumstances until we
have a revised datastore solution defined and implemented that may
allow this to work in all situations.


  
3) All config false leaves go under /foo where possible, or /foo-state
otherwise (e.g. for restconf-monitoring).

  
  
I think it should be fairly easy for a tool to figure out whether a
/foo tree is a pure config true tree or whether there are any config
false leafs as well and /foo is a mixed tree. Things are fairly easy
as long as people split at the root if they split.


  
4) Config false leaves go wherever the model writer decides is appropriate.

  
  
I think we will have to live for a while with both the (i) /foo (pure
config true tree) and /foo-state (pure config false tree) split at the
root approach and the (ii) /foo (mixed config true and false tree)
approach. We need to document the trade-offs between the two so that
module writers can make an informed decision. Whether a module uses
(i) or (ii) should be possible to determine by inspecting the
properties of the schema tree, in particular if module writers follow
the guideline to use consistent names and structure in the /foo and
/foo-state approach wherever possible.

I think we also wanted to strongly discourage models where (iii) the
trees split at the leaves or very close to the leaves.

/js




-- 
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

[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