Re: [netmod] Questions on NMDA and "merged config and state"

2017-08-06 Thread Bogaert, Bart (Nokia - BE/Antwerp) 
Hello Juergen,

I have also noticed this but when I look at the type of remarks Andy is
making I get an impression that "dust has not settled" on how this will work
in "real life".

Regards, Bart
-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Saturday, August 05, 2017 10:36 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) 
Cc: Andy Bierman ; netmod@ietf.org
Subject: Re: [netmod] Questions on NMDA and "merged config and state"

On Fri, Aug 04, 2017 at 07:03:43AM +, Bogaert, Bart (Nokia - BE/Antwerp)
wrote:
> Maybe a stupid question from my side (I'm not involved  in the NMDA 
> work) but is there some kind of consensus on what is proposed in this 
> draft RFC or are we miles away from such a consensus?  Since this is 
> linked to how a server has to handle state in the proposed merging of 
> config and state under one branch of the tree coming to a conclusion 
> to me seems a requirement since in the current implementation we just 
> can't change a CT leaf in the running DS by a value that is 
> dynamically learned; in the NMDA approach that would be possible as 
> the operational DS contains both CT and CF leaves and consequently a 
> value as configured by the client can be overwritten by a dynamically 
> learned value as the value configured by the client remains untouched 
> in the running DS.  In the current implementation we would need to 
> model a CF leaf for this purpose.  At least that is how I have always 
> understood how it should be done.  As long as we do not have 
> NDMA-based server implementations we can't design and implement YANG
models as proposed in NMDA and its associated guidelines.
>

Bart,

you may want to look at draft-dsdt-nmda-guidelines-01. Protocol updates to
support NMDA are on the way as well, draft-dsdt-nmda-netconf-00 and
draft-dsdt-netconf-restconf-nmda-00.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Questions on NMDA and "merged config and state"

2017-08-05 Thread Juergen Schoenwaelder 
On Fri, Aug 04, 2017 at 07:03:43AM +, Bogaert, Bart (Nokia - BE/Antwerp) 
wrote:
> Maybe a stupid question from my side (I'm not involved  in the NMDA work)
> but is there some kind of consensus on what is proposed in this draft RFC or
> are we miles away from such a consensus?  Since this is linked to how a
> server has to handle state in the proposed merging of config and state under
> one branch of the tree coming to a conclusion to me seems a requirement
> since in the current implementation we just can't change a CT leaf in the
> running DS by a value that is dynamically learned; in the NMDA approach that
> would be possible as the operational DS contains both CT and CF leaves and
> consequently a value as configured by the client can be overwritten by a
> dynamically learned value as the value configured by the client remains
> untouched in the running DS.  In the current implementation we would need to
> model a CF leaf for this purpose.  At least that is how I have always
> understood how it should be done.  As long as we do not have NDMA-based
> server implementations we can't design and implement YANG models as proposed
> in NMDA and its associated guidelines.
>

Bart,

you may want to look at draft-dsdt-nmda-guidelines-01. Protocol updates
to support NMDA are on the way as well, draft-dsdt-nmda-netconf-00 and
draft-dsdt-netconf-restconf-nmda-00.

/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] Questions on NMDA and "merged config and state"

2017-08-04 Thread Andy Bierman 
On Thu, Aug 3, 2017 at 11:29 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Aug 03, 2017 at 10:06:23AM -0700, Andy Bierman wrote:
> >
> > So you are saying there is no such thing as an NMDA-compliant server.
> > There are protocols that may use specific datastores in various ways.
> > Different protocols can have different behavior for the same datastore.
> > Sounds very fun for client developers to figure out.
> >
>
> This is what I wrote:
>
>   The protocols (with their various capabilities) expose different sets
>   of datastores. I agree, the protocol documents should state clearly
>   what is required to expose for the different protocols and what is
>   optional to expose.
>
> I did not write that different protocols can have different behavior
> for the same datastore. I did not write that protocols may use
> specific datastores in various ways.
>
>

So the protocol designers will some how agree on the properties of a
standard datastore?
Actually it seems much worse than that. It seems each server implementation
decides what it wants to support and just lists that.

The 7895bis draft proposes that each server will list the properties it
supports for each datastore

container properties {
   leaf-list property {
 type identityref {
   base ds:property;
 }
 description
   "A property of the datastore.";
   }
   description
 "A list of properties supported by this datastore.";
 }


Of course, these properties are just a list of identityrefs that match the
base 'ds:property'.
There is no official list of properties that a datastore is expected to
support.

There is this list in ietf-datastores that seems to be intended to replace
the existing capability URIs for various NETCONF capabilities:
There does not seem to be any guidance or normative text.
NMS developers should take notice of these changes because the
impact on code design could be significant.



 identity property {
   description
"Abstract base identity for datastore identities.";
 }

 identity writable {
   base property;
   description
 "Used on the 'running' datastore to indicate that it can be
  written to."

 }

 identity auto-persist {
   base property;
   description
 "Used on the 'running' datastore to indicate that writes to
  it will be automatically persisted.

  If the 'startup' datastore is also supported, clients may
  query its contents to ensure its synchronization.

  If the 'startup' datastore is not supported, and this
  property is not set, then clients must use a mechanism
  provided by the protocol to explicitly persist the
  'running' datastore's contents.";
 }

 identity rollback-on-error {
   base property;
   description
 "Used on either the 'running' or 'candidate' datastores to
  indicate that clients may request atomic update behavior.";
 }

 identity confirmed-commit {
   base property;
   description
 "Used on the 'candidate' datastore to indicate that
  clients may request confirmed-commit update behavior.";
 }

 identity validate {
   base property;
   description
 "Used on the 'candidate' datastore to indicate that
  clients may request datastore validation.";
 }




> /js
>


Andy


>
> --
> 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] Questions on NMDA and "merged config and state"

2017-08-04 Thread Bogaert, Bart (Nokia - BE/Antwerp) 
Maybe a stupid question from my side (I'm not involved  in the NMDA work)
but is there some kind of consensus on what is proposed in this draft RFC or
are we miles away from such a consensus?  Since this is linked to how a
server has to handle state in the proposed merging of config and state under
one branch of the tree coming to a conclusion to me seems a requirement
since in the current implementation we just can't change a CT leaf in the
running DS by a value that is dynamically learned; in the NMDA approach that
would be possible as the operational DS contains both CT and CF leaves and
consequently a value as configured by the client can be overwritten by a
dynamically learned value as the value configured by the client remains
untouched in the running DS.  In the current implementation we would need to
model a CF leaf for this purpose.  At least that is how I have always
understood how it should be done.  As long as we do not have NDMA-based
server implementations we can't design and implement YANG models as proposed
in NMDA and its associated guidelines.

Regards, Bart

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Friday, August 04, 2017 8:29 AM
To: Andy Bierman 
Cc: Bogaert, Bart (Nokia - BE/Antwerp) ;
netmod@ietf.org
Subject: Re: [netmod] Questions on NMDA and "merged config and state"

On Thu, Aug 03, 2017 at 10:06:23AM -0700, Andy Bierman wrote:
> 
> So you are saying there is no such thing as an NMDA-compliant server.
> There are protocols that may use specific datastores in various ways.
> Different protocols can have different behavior for the same datastore.
> Sounds very fun for client developers to figure out.
>

This is what I wrote:

  The protocols (with their various capabilities) expose different sets
  of datastores. I agree, the protocol documents should state clearly
  what is required to expose for the different protocols and what is
  optional to expose.

I did not write that different protocols can have different behavior for the
same datastore. I did not write that protocols may use specific datastores
in various ways.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Questions on NMDA and "merged config and state"

2017-08-03 Thread Bogaert, Bart (Nokia - BE/Antwerp) 
On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

On Thu, Aug 03, 2017 at 06:59:58AM +, Bogaert, Bart (Nokia - BE/Antwerp) 
wrote:
>
> Just to get confirmation on my assumptions:
>
> In section 4.7.3 the origin metadata does not include 'running' as origin
> but only 'intended'.  So it seems to be mandatory for a NC server to support
> the intended datastore?

If your server does not support templates or inactive configuration or
the like, then intended is just an alias for running.





IMO this is not correct.

There are no standards at all to define these things.

Our server supports an implementation of config templates that expands the

template when it is first created.  A different proprietary implementation MAY 
choose

to expand templates in some other way.  Since there are no standards for this 
purpose,

any proprietary implementation decision is valid.



The contents of the "intended" datastore are purely proprietary.

The opaque nature of this datastore is by design and the WG accepts that 
servers

are free to choose to implement whatever datastores they want.

The origin metadata should just reflect what the server does, not mandate

any sort of datastore conformance.

[Bart Bogaert] In that case I would expect that the running is also included 
as an origin of the data in the operational datastore?



Regards, Bart





Andy







I do not think
you need to expose intended in this case. Still, the value of the
origin attribute is 'intended' since in the general case, the
configuration is coming from .

> With the introduction of the operational datastore I assume it also means
> that when someone wants to know what the client has configured on the device
> a get-config on the running datastore is required while to know the 'in-use'
> configuration a get(-config) on the operational datastore is required?

Yes. The operation, however, is likely called get-data in NETCONF, at
least this is what draft-dsdt-nmda-netconf-00 suggested.

> The Guidelines for YANG Module Authors (NMDA) - draft-dsdt-nmda-guidelines
> mentions that a derived module can be generated from the YANG models where
> state and config are merged in a single branch.  In the simple example this
> results in another YANG model with its own namespace.  I assume that this
> state YANG model will then also show up in the hello message?

The general idea is that we produce YANG modules that have config and
state merged into a single branch. Out of this YANG module, people may
generate a separate module that consists of the config false nodes
plus any additional key nodes needed to make it work. Such a YANG
module will be treated as any other YANG module. Note that YANG 1.1
started to move module announcements to the ietf-yang-library to avoid
very long module announcements during session startup.

/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





smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Questions on NMDA and "merged config and state"

2017-08-03 Thread Juergen Schoenwaelder 
On Thu, Aug 03, 2017 at 10:06:23AM -0700, Andy Bierman wrote:
> 
> So you are saying there is no such thing as an NMDA-compliant server.
> There are protocols that may use specific datastores in various ways.
> Different protocols can have different behavior for the same datastore.
> Sounds very fun for client developers to figure out.
>

This is what I wrote:

  The protocols (with their various capabilities) expose different sets
  of datastores. I agree, the protocol documents should state clearly
  what is required to expose for the different protocols and what is
  optional to expose.

I did not write that different protocols can have different behavior
for the same datastore. I did not write that protocols may use
specific datastores in various ways.

/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] Questions on NMDA and "merged config and state"

2017-08-03 Thread Andy Bierman 
On Thu, Aug 3, 2017 at 9:53 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Aug 03, 2017 at 09:49:25AM -0700, Andy Bierman wrote:
> > On Thu, Aug 3, 2017 at 9:32 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierman wrote:
> > > > On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder <
> > > > j.schoenwael...@jacobs-university.de> wrote:
> > > >
> > > > > On Thu, Aug 03, 2017 at 06:59:58AM +, Bogaert, Bart (Nokia -
> > > > > BE/Antwerp) wrote:
> > > > > >
> > > > > > Just to get confirmation on my assumptions:
> > > > > >
> > > > > > In section 4.7.3 the origin metadata does not include 'running'
> as
> > > origin
> > > > > > but only 'intended'.  So it seems to be mandatory for a NC
> server to
> > > > > support
> > > > > > the intended datastore?
> > > > >
> > > > > If your server does not support templates or inactive
> configuration or
> > > > > the like, then intended is just an alias for running.
> > > >
> > > > IMO this is not correct.
> > > > There are no standards at all to define these things.
> > > > Our server supports an implementation of config templates that
> expands
> > > the
> > > > template when it is first created.  A different proprietary
> > > implementation
> > > > MAY choose
> > > > to expand templates in some other way.  Since there are no standards
> for
> > > > this purpose,
> > > > any proprietary implementation decision is valid.
> > >
> > > So your implementation allows a client to write something to 
> > > that transforms into something different at the time it is written (or
> > > committed I assume)? Anyway, my statement was:
> > >
> > >   If your server does not support templates or inactive configuration
> or
> > >   the like, then intended is just an alias for running.
> > >
> > > So it does not apply to your implementation.
> > >
> > >
> >
> > IMO the concept of NMDA conformance is still very under-specified.
>
> Seems you are changing topic.
>
> > There should be a clear statement in RFC 2119 terms for the exact
> > datastores that are considered standard datastores.  This needs to
> > be 100% backward compatible with RFC 7950 and RFC 6241 requirements
> > for the 3 traditional datastores.
>
> The protocols (with their various capabilities) expose different sets
> of datastores. I agree, the protocol documents should state clearly
> what is required to expose for the different protocols and what is
> optional to expose.
>
> > I don't care if new datastore usage is unbounded, as long as the
> > client developer knows what to expect from an NMDA-compliant server.
> >
> > The WG needs to deliberately (not haphazardly) determine the
> > interoperability boundaries.
>
> Yes, but it is not this WG but the other WG I think.
>

So you are saying there is no such thing as an NMDA-compliant server.
There are protocols that may use specific datastores in various ways.
Different protocols can have different behavior for the same datastore.
Sounds very fun for client developers to figure out.



>
> /js
>
>
Andy


> --
> 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] Questions on NMDA and "merged config and state"

2017-08-03 Thread Juergen Schoenwaelder 
On Thu, Aug 03, 2017 at 09:49:25AM -0700, Andy Bierman wrote:
> On Thu, Aug 3, 2017 at 9:32 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierman wrote:
> > > On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder <
> > > j.schoenwael...@jacobs-university.de> wrote:
> > >
> > > > On Thu, Aug 03, 2017 at 06:59:58AM +, Bogaert, Bart (Nokia -
> > > > BE/Antwerp) wrote:
> > > > >
> > > > > Just to get confirmation on my assumptions:
> > > > >
> > > > > In section 4.7.3 the origin metadata does not include 'running' as
> > origin
> > > > > but only 'intended'.  So it seems to be mandatory for a NC server to
> > > > support
> > > > > the intended datastore?
> > > >
> > > > If your server does not support templates or inactive configuration or
> > > > the like, then intended is just an alias for running.
> > >
> > > IMO this is not correct.
> > > There are no standards at all to define these things.
> > > Our server supports an implementation of config templates that expands
> > the
> > > template when it is first created.  A different proprietary
> > implementation
> > > MAY choose
> > > to expand templates in some other way.  Since there are no standards for
> > > this purpose,
> > > any proprietary implementation decision is valid.
> >
> > So your implementation allows a client to write something to 
> > that transforms into something different at the time it is written (or
> > committed I assume)? Anyway, my statement was:
> >
> >   If your server does not support templates or inactive configuration or
> >   the like, then intended is just an alias for running.
> >
> > So it does not apply to your implementation.
> >
> >
> 
> IMO the concept of NMDA conformance is still very under-specified.

Seems you are changing topic.

> There should be a clear statement in RFC 2119 terms for the exact
> datastores that are considered standard datastores.  This needs to
> be 100% backward compatible with RFC 7950 and RFC 6241 requirements
> for the 3 traditional datastores.

The protocols (with their various capabilities) expose different sets
of datastores. I agree, the protocol documents should state clearly
what is required to expose for the different protocols and what is
optional to expose.

> I don't care if new datastore usage is unbounded, as long as the
> client developer knows what to expect from an NMDA-compliant server.
> 
> The WG needs to deliberately (not haphazardly) determine the
> interoperability boundaries.

Yes, but it is not this WG but the other WG I think.

/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] Questions on NMDA and "merged config and state"

2017-08-03 Thread Andy Bierman 
On Thu, Aug 3, 2017 at 9:32 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierman wrote:
> > On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Thu, Aug 03, 2017 at 06:59:58AM +, Bogaert, Bart (Nokia -
> > > BE/Antwerp) wrote:
> > > >
> > > > Just to get confirmation on my assumptions:
> > > >
> > > > In section 4.7.3 the origin metadata does not include 'running' as
> origin
> > > > but only 'intended'.  So it seems to be mandatory for a NC server to
> > > support
> > > > the intended datastore?
> > >
> > > If your server does not support templates or inactive configuration or
> > > the like, then intended is just an alias for running.
> >
> > IMO this is not correct.
> > There are no standards at all to define these things.
> > Our server supports an implementation of config templates that expands
> the
> > template when it is first created.  A different proprietary
> implementation
> > MAY choose
> > to expand templates in some other way.  Since there are no standards for
> > this purpose,
> > any proprietary implementation decision is valid.
>
> So your implementation allows a client to write something to 
> that transforms into something different at the time it is written (or
> committed I assume)? Anyway, my statement was:
>
>   If your server does not support templates or inactive configuration or
>   the like, then intended is just an alias for running.
>
> So it does not apply to your implementation.
>
>

IMO the concept of NMDA conformance is still very under-specified.
There should be a clear statement in RFC 2119 terms for the exact
datastores that are considered standard datastores.  This needs to be 100%
backward
compatible with RFC 7950 and RFC 6241 requirements for the 3 traditional
datastores.
I don't care if new datastore usage is unbounded, as long as the client
developer
knows what to expect from an NMDA-compliant server.

The WG needs to deliberately (not haphazardly) determine the
interoperability boundaries.


/js
>


Andy


>
> --
> 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] Questions on NMDA and "merged config and state"

2017-08-03 Thread Juergen Schoenwaelder 
On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierman wrote:
> On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Thu, Aug 03, 2017 at 06:59:58AM +, Bogaert, Bart (Nokia -
> > BE/Antwerp) wrote:
> > >
> > > Just to get confirmation on my assumptions:
> > >
> > > In section 4.7.3 the origin metadata does not include 'running' as origin
> > > but only 'intended'.  So it seems to be mandatory for a NC server to
> > support
> > > the intended datastore?
> >
> > If your server does not support templates or inactive configuration or
> > the like, then intended is just an alias for running.
> 
> IMO this is not correct.
> There are no standards at all to define these things.
> Our server supports an implementation of config templates that expands the
> template when it is first created.  A different proprietary implementation
> MAY choose
> to expand templates in some other way.  Since there are no standards for
> this purpose,
> any proprietary implementation decision is valid.

So your implementation allows a client to write something to 
that transforms into something different at the time it is written (or
committed I assume)? Anyway, my statement was:

  If your server does not support templates or inactive configuration or
  the like, then intended is just an alias for running.

So it does not apply to your implementation.

/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] Questions on NMDA and "merged config and state"

2017-08-03 Thread Andy Bierman 
On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Aug 03, 2017 at 06:59:58AM +, Bogaert, Bart (Nokia -
> BE/Antwerp) wrote:
> >
> > Just to get confirmation on my assumptions:
> >
> > In section 4.7.3 the origin metadata does not include 'running' as origin
> > but only 'intended'.  So it seems to be mandatory for a NC server to
> support
> > the intended datastore?
>
> If your server does not support templates or inactive configuration or
> the like, then intended is just an alias for running.



IMO this is not correct.
There are no standards at all to define these things.
Our server supports an implementation of config templates that expands the
template when it is first created.  A different proprietary implementation
MAY choose
to expand templates in some other way.  Since there are no standards for
this purpose,
any proprietary implementation decision is valid.

The contents of the "intended" datastore are purely proprietary.
The opaque nature of this datastore is by design and the WG accepts that
servers
are free to choose to implement whatever datastores they want.
The origin metadata should just reflect what the server does, not mandate
any sort of datastore conformance.


Andy




> I do not think
> you need to expose intended in this case. Still, the value of the
> origin attribute is 'intended' since in the general case, the
> configuration is coming from .
>
> > With the introduction of the operational datastore I assume it also means
> > that when someone wants to know what the client has configured on the
> device
> > a get-config on the running datastore is required while to know the
> 'in-use'
> > configuration a get(-config) on the operational datastore is required?
>
> Yes. The operation, however, is likely called get-data in NETCONF, at
> least this is what draft-dsdt-nmda-netconf-00 suggested.
>
> > The Guidelines for YANG Module Authors (NMDA) -
> draft-dsdt-nmda-guidelines
> > mentions that a derived module can be generated from the YANG models
> where
> > state and config are merged in a single branch.  In the simple example
> this
> > results in another YANG model with its own namespace.  I assume that this
> > state YANG model will then also show up in the hello message?
>
> The general idea is that we produce YANG modules that have config and
> state merged into a single branch. Out of this YANG module, people may
> generate a separate module that consists of the config false nodes
> plus any additional key nodes needed to make it work. Such a YANG
> module will be treated as any other YANG module. Note that YANG 1.1
> started to move module announcements to the ietf-yang-library to avoid
> very long module announcements during session startup.
>
> /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] Questions on NMDA and "merged config and state"

2017-08-03 Thread Juergen Schoenwaelder 
On Thu, Aug 03, 2017 at 06:59:58AM +, Bogaert, Bart (Nokia - BE/Antwerp) 
wrote:
> 
> Just to get confirmation on my assumptions:
> 
> In section 4.7.3 the origin metadata does not include 'running' as origin
> but only 'intended'.  So it seems to be mandatory for a NC server to support
> the intended datastore?

If your server does not support templates or inactive configuration or
the like, then intended is just an alias for running. I do not think
you need to expose intended in this case. Still, the value of the
origin attribute is 'intended' since in the general case, the
configuration is coming from .  
 
> With the introduction of the operational datastore I assume it also means
> that when someone wants to know what the client has configured on the device
> a get-config on the running datastore is required while to know the 'in-use'
> configuration a get(-config) on the operational datastore is required?

Yes. The operation, however, is likely called get-data in NETCONF, at
least this is what draft-dsdt-nmda-netconf-00 suggested.

> The Guidelines for YANG Module Authors (NMDA) - draft-dsdt-nmda-guidelines
> mentions that a derived module can be generated from the YANG models where
> state and config are merged in a single branch.  In the simple example this
> results in another YANG model with its own namespace.  I assume that this
> state YANG model will then also show up in the hello message?

The general idea is that we produce YANG modules that have config and
state merged into a single branch. Out of this YANG module, people may
generate a separate module that consists of the config false nodes
plus any additional key nodes needed to make it work. Such a YANG
module will be treated as any other YANG module. Note that YANG 1.1
started to move module announcements to the ietf-yang-library to avoid
very long module announcements during session startup.

/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