Subject: [netmod] Opstate solutions discussions: update and request for WG input

From: Lou Berger <[email-masked]>
Date: Tue, 7 Jun 2016 10:19:33 -0400

All,

We want to provide an update based on the off line discussions
related to OpState Solutions that we have been having and solicit
input from the WG.

All authors of current solution drafts [1,2,3] together with those
who helped conduct the solutions analysis* were invited to the these
discussions -- with the objective of coming up with a single
consolidated proposal to bring to the WG. (I/Lou acted as facilitator
as Kent and Juergen were and are involved with the technical details.)

The discussions have yielded some results but, unfortunately,
not a single consolidated proposal as hoped, but rather two
alternate directions -- and clearly we need to choose one:

    1) Adopt the conventions for representing state/config
       based on Section 6 of [1].

       From a model definition perspective, these conventions
       impact every model and every model writer.

    2) Model OpState using a revised logical datastore definition
       as introduced in [4] and also covered in [5]. There is
       also a variant of this that we believe doesn't significantly
       impact this choice.

       With this approach, model definitions need no explicit
       changes to support applied configuration.

>From a technology/WG standpoint, we believe an approach
that doesn't impact every model written (i.e., #2) is superior.
The counterpoint to this is that the conventions based
approach (i.e., #1) is available today and being followed in
OpenConfig defined models.

We would like to hear opinions on this from the WG before
declaring one of the following as the WG direction:

    A) models that wish to support applied configuration MUST
       follow conventions based on [1] -- and the WG needs to
       formalize these conventions.
or
    B) no explicit support is required for models to support
       applied configuration -- and that the WG needs to
       formalize an opstate solution based on the approach
       discussed in [4] and [5].

We intend to close on this choice before Berlin.

Thank you,
Lou (and co-chairs)

[1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
[2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
[3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
[4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
[5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
* - Chris H. and Acee L.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Jun 2016 09:23:43 -0700

Hi,

I prefer (B).
I do not think it is realistic that vendors will rewrite their IETF
modules and vendor modules and all the associated client/server
instrumentation.
This is expensive at many levels. Stability is important for an API.

So if we do (A), there will be some modules following the convention
and the rest using proprietary RPC-based solutions.
But if we do (B), vendors can integrate the standard RPC-based solution
into their existing running code with zero disturbance.

Andy

On Tue, Jun 7, 2016 at 7:19 AM, Lou Berger <[email-masked]> wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Jun 2016 09:45:18 +0200 (CEST)

> I prefer (B).

For the record, I also prefer B.

B is a more robust solution, since it can handle not only intended and
applied, but also other existing (e.g. startup) and future
(e.g. ephemeral) datastores.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 08 Jun 2016 14:08:29 +0200

> that doesn't impact every model written (i.e., #2) is superior.

I agree.

>        discussed in [4] and [5].

I prefer B.

Lada

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

---

From: <[email-masked]>
Date: Wed, 08 Jun 2016 11:20:36 -0400

> For the record, I also prefer B.

I also prefer B.

In addition to the points below, it also "Just Works" for all
existing and future models including ones designed outside of the
purview of the IETF.

Thanks,
Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 8 Jun 2016 17:29:41 +0000

I agree that option B is the best way forward. The sooner we reach the
consensus the sooner we can discuss how this can simply models that are
waiting for the IETF OpsState direction.
Thanks,
Acee 

On 6/8/16, 11:20 AM, "netmod on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>>> > [4] 
>>>https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
>>> > [5] 
>>>https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
>>> > * - Chris H. and Acee L.
>>> >
>>> >

---

From: <[email-masked]>
Date: Thu, 9 Jun 2016 09:23:27 +0000

I'm also in favor of B.

I personally do not like the way state/config are expressed in [1] as it complexifies the way yang modules are written while a solution like [4] allows to have a more cleaner yang module while achieving the same goal.

As expressed by others, B will also be faster with existing modules.

Best Regards,

Stephane

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, June 07, 2016 16:20
To: netmod WG
Cc: [email-masked]
Subject: [netmod] Opstate solutions discussions: update and request for WG input

All,

We want to provide an update based on the off line discussions related to OpState Solutions that we have been having and solicit input from the WG.

All authors of current solution drafts [1,2,3] together with those who helped conduct the solutions analysis* were invited to the these discussions -- with the objective of coming up with a single consolidated proposal to bring to the WG. (I/Lou acted as facilitator as Kent and Juergen were and are involved with the technical details.)

The discussions have yielded some results but, unfortunately, not a single consolidated proposal as hoped, but rather two alternate directions -- and clearly we need to choose one:

that doesn't impact every model written (i.e., #2) is superior.
The counterpoint to this is that the conventions based approach (i.e., #1) is available today and being followed in OpenConfig defined models.

We would like to hear opinions on this from the WG before declaring one of the following as the WG direction:

Thank you,
Lou (and co-chairs)

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Wed, 15 Jun 2016 08:21:58 +0000

Hi Lou, chairs, 

Based on the feedback on the list, could we conclude that we go to B) or do you want to wait more ?
We would like to close work on multiple YANG models, and today ops state are blocking ... would be good to close it asap.

Best Regards,

Stephane

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, June 07, 2016 16:20
To: netmod WG
Cc: [email-masked]
Subject: [netmod] Opstate solutions discussions: update and request for WG input

All,

Thank you,
Lou (and co-chairs)

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 Jun 2016 06:37:16 -0400

Stephane,

Response has been a bit light, albeit all for (B).  I'm hoping we'd here 
from some additional WG participants - so we need a little bit more time.  
I'm still expecting for this discussion to be closed before Berlin.

Also, can we infer from you message that you are also in favor of (B)?

Thanks,
Lou

On June 15, 2016 4:22:27 AM <[email-masked]> wrote:

> We would like to close work on multiple YANG models, and today ops state 
> are blocking ... would be good to close it asap.
>
> Best Regards,
>
> Stephane
>
> We want to provide an update based on the off line discussions related to 
> OpState Solutions that we have been having and solicit input from the WG.
>
> All authors of current solution drafts [1,2,3] together with those who 
> helped conduct the solutions analysis* were invited to the these 
> discussions -- with the objective of coming up with a single consolidated 
> proposal to bring to the WG. (I/Lou acted as facilitator as Kent and 
> Juergen were and are involved with the technical details.)
>
> The discussions have yielded some results but, unfortunately, not a single 
> consolidated proposal as hoped, but rather two alternate directions -- and 
> clearly we need to choose one:
>
> The counterpoint to this is that the conventions based approach (i.e., #1) 
> is available today and being followed in OpenConfig defined models.
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;

---

From: <[email-masked]>
Date: Wed, 15 Jun 2016 12:21:58 +0000

Yes, I'm in favor of B, I already expressed it on the list.

Thanks

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, June 15, 2016 12:37
To: LITKOWSKI Stephane OBS/OINIS; netmod WG
Cc: [email-masked]
Subject: RE: [netmod] Opstate solutions discussions: update and request for WG input

Stephane,

Response has been a bit light, albeit all for (B).  I'm hoping we'd here from some additional WG participants - so we need a little bit more time.  
I'm still expecting for this discussion to be closed before Berlin.

Thanks,
Lou

On June 15, 2016 4:22:27 AM <[email-masked]> wrote:

> We would like to close work on multiple YANG models, and today ops 
> state are blocking ... would be good to close it asap.
>
> Best Regards,
>
> Stephane
>
> We want to provide an update based on the off line discussions related 
> to OpState Solutions that we have been having and solicit input from the WG.
>
> The discussions have yielded some results but, unfortunately, not a 
> single consolidated proposal as hoped, but rather two alternate 
> directions -- and clearly we need to choose one:
>
> The counterpoint to this is that the conventions based approach (i.e., 
> #1) is available today and being followed in OpenConfig defined models.
>
> We would like to hear opinions on this from the WG before declaring 
> one of the following as the WG direction:
>
> ______________________________________________________________________
> ___________________________________________________
>
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete 
> altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 Jun 2016 14:41:04 +0200

> For the record, I also prefer B.

Same here.

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

---

From: Jonathan Hansford <[email-masked]>
Date: Wed, 15 Jun 2016 14:34:52 +0100

I also prefer B.

Jonathan

From: Juergen Schoenwaelder
Sent: 15 June 2016 13:41
To: Martin Bjorklund
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] Opstate solutions discussions: update and request forWG input

Same here.

/js

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 15 Jun 2016 15:46:39 +0000

For applied configuration, I'd also prefer [B], especially [4], which clarifies datastores in a better way. [4] also paves a way for better modeling of derived state.  Once the approach for applied configuration is formalized, the derived state, as a part of OpState modeling, will need to be formalized. At that time, the modeling ideas from [1] could be applied, to re-consider the top-level branch for config-false tree. In this regard, 1) and 2) can be combined.

Thanks,

- Xufeng

> Sent: Tuesday, June 7, 2016 10:20 AM
> To: netmod WG <[email-masked]>
> All authors of current solution drafts [1,2,3] together with those who helped
> conduct the solutions analysis* were invited to the these discussions -- with the
> objective of coming up with a single consolidated proposal to bring to the WG.
> (I/Lou acted as facilitator as Kent and Juergen were and are involved with the
> technical details.)
> 
> The counterpoint to this is that the conventions based approach (i.e., #1) is
> available today and being followed in OpenConfig defined models.
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 15 Jun 2016 09:45:22 -0700

+1 (a.k.a. support option B)

> On Jun 7, 2016, at 9:23 AM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> I prefer (B).
> modules and vendor modules and all the associated client/server instrumentation.
> On Tue, Jun 7, 2016 at 7:19 AM, Lou Berger <[email-masked] <mailto:[email-masked]>> wrote:
> All,
> 
> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 <https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01>
> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 <https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02>
> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 <https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02>
> [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 <https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00>
> [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 <https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00>
> * - Chris H. and Acee L.
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 

Mahesh Jethanandani
[email-masked]

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 15 Jun 2016 13:57:55 -0400

Lou,

	Given the wide-ranging impact of this sort of decision across not just the IETF, let me suggest that it might be a good idea to get data points from a sample that is a bit larger than 4 or 5.  Forwarding this query to some other relevant WGs might be in order given the lack luster responses to-date.

	—Tom

> On Jun 15, 2016:6:37 AM, at 6:37 AM, Lou Berger <[email-masked]> wrote:
> 
> Stephane,
> 
> Response has been a bit light, albeit all for (B).  I'm hoping we'd here from some additional WG participants - so we need a little bit more time.  I'm still expecting for this discussion to be closed before Berlin.
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 Jun 2016 17:22:31 -0400

Agreed and already forwarded to the routing area yang coordination
list.  would you suggest any other lists?

Lou

---

From: Robert Wilton <[email-masked]>
Date: Thu, 16 Jun 2016 10:34:15 +0100

For the record, I also think that B is the right choice.

Rob

On 07/06/2016 15:19, Lou Berger wrote:
> .

---

From: t.petch <[email-masked]>
Date: Fri, 17 Jun 2016 16:15:37 +0100

Lou

By now, 17th June, I see solid support for one option but only see
comments from a somewhat small number of participants

The majority of the authors of the 172 YANG files I have in an
archive are probably unaware of this discussion and yet some at least
will be affected.  What concerns me is that history might be repeating
itself.  In a sense, this discussion is about the original proposals for
NETCONF and YANG not meeting current requirements which
may be because there has mostly been a limited number of
participants in netmod discussions.

I was struck by Dale's recent, brilliant review of 6020bis because it
came from a fresh angle and brought up nagging concerns that I had had
but had not been able to articulate.  With a wider audience, similar
comments might have been made much earlier to the advantage
of YANG (perhaps even about RFC6020).

In the same vein, there is NETCONF.  Juergen's I-D, which I see finding
favour, could be said to cut the ground from under NETCONF (well, I
would).  RFC6241 says
" Configuration data is the set of writable data that is required to
   transform a system from its initial default state into its current
   state.  State data is the additional data on a system that is not
   configuration data such as read-only status information and collected
   statistics.  "

The proposed 'intended' in the I-D is (ct, ro).  It is ct, configuration
true, so it is configuration data.  It is ro, read only, so it is
clearly not
configuration data.  Without changing RFC6241, I cannot reconcile this.

So I see RFC6241 being changed; can anyone reading the RFC understand it
any more?  And yet the I-D makes no mention of this change to
NETCONF nor have I seen any discussion on the netconf list.

Stimulated by posts to the I2RS list, perhaps also a trigger for
Juergen's I-D, I wrote up my own summary of the current state of
datastores but I called it draft-tp-netconf-datastore because I see
NETCONF
currently telling us almost all that we know about datastores; YANG 1.0
adds very little.  For me, NETCONF should be the starting point.

Tom Petch

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 17 Jun 2016 16:18:29 +0000

Hi Tom, 
At least most of the YANG model authors that I work with are following
this discussion. However, I would guess that many are waiting for the
outcome and how it affects model structure as opposed to having a strong
opinion on the options.
Thanks,
Acee

---

From: Lou Berger <[email-masked]>
Date: Fri, 17 Jun 2016 14:22:21 -0400

Tom,

    Thanks for the perspective.  I'm a little unsure if you're expecting
a response or just making a statement, so if you're looking for
something specific and don't see it below -- please let me know.

> comments from a somewhat small number of participants
This is true, and I've heard privately that some more may/should be
forthcoming.

> participants in netmod discussions.

So two points on this:
- Today is different in that there are a great number of players
using/looking to YANG at the moment --- so I think we have more lurkers
out there than you'd expect.

- The fact that 172 documents (and that's just in the IETF) would be
impacted by option (A) is exactly why we think it's the wrong way to go.
Think about if we came up with a solution that requires each modeler to
build their definitions a fixed way how this would be
socialized/enforced.  Now think about doing that in other SDOs.

> configuration data.  Without changing RFC6241, I cannot reconcile this.
It's just a ro version/view of the config data.  I'm not sure why this
is problematic.  Perhaps I'm just missing something.

> adds very little.  For me, NETCONF should be the starting point.
The first question is deciding on an approach (A vs B), the second
question is on the details of the selected option.  If we move forward
with B, I think which WG does the data store work is a fine topic to
consider.  But we (netmod)  first need to close on A vs B -- which will
be easy if there are no new comments in short order.

Lou

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Jun 2016 11:33:38 -0700

> socialized/enforced.  Now think about doing that in other SDOs.
Not to mention all the vendor defined YANG modules.

IMO this has always been a protocol issue.
The state of the data depends on the interaction model and that depends on
the protocol.
E.g., how does confirmed-commit factor into the state machine?
The config may be applied but also temporary, pending confirmation.

What if a YANG protocol mandated that <ok> means applied, not just intended?
That interaction model would not need separate datastores for intended vs.
applied.
(One solution approach is to update NETCONF to provide this interaction
model.)

Andy

---

From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <[email-masked]>
Date: Fri, 17 Jun 2016 18:36:01 +0000

Hi All
I'd like to support Option B below.
>>        discussed in [4] and [5].

Thanks
Kiran

>> [email-masked]<mailto:[email-masked]>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Jun 2016 21:19:09 +0200

> (One solution approach is to update NETCONF to provide this interaction

You can have configuration for an interface in <running> that does not
get applied because the interface is currently not present. I do not
think that this is a protocol semantics issue.

/js

---

From: t.petch <[email-masked]>
Date: Sun, 19 Jun 2016 10:52:00 +0100

Lou

You say below
"
> is problematic.  Perhaps I'm just missing something.
"

I see it as a fundamental change (to NETCONF).  Tracking other lists
(e.g.I2RS) I repeatedly get the sense that they have not grasped what
configuration data is (editable, potential persistent but a minute
fraction of what a box needs to operate), and by contrast what is state.
I see some, if not many, of Juergen's posts to that list as reflecting
that such as
"I have no clue what the above sentence is trying to say. Please try to
use YANG terminology. "

Every time I read 'ephemeral state' I think the same; state is
ephemeral, the phrase does not convey any meaning (except that the user
does not understand what configuration is).

And this comes mostly from RFC6241 not from RFC6020.

So, I see a strong preference for Option B which is all very logical, as
Acee points out.  But Option B I see as being a fundamental change to
RFC6241, so if the netmod WG takes that decision, then it is stamping on
the netconf WG.  Perhaps the WG should be merged, now that 6020bis is on
its way, but for the moment, I believe that changes to NETCONF need the
consensus of  the NETCONF WG.

Tom Petch

----- Original Message -----
From: "Lou Berger" <[email-masked]>
To: "t.petch" <[email-masked]>; "netmod WG" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 17, 2016 7:22 PM
Subject: Re: [netmod] Opstate solutions discussions: update and request
for WGinput

---

From: Lou Berger <[email-masked]>
Date: Sun, 19 Jun 2016 11:01:58 -0400

Hi Tom,

> consensus of  the NETCONF WG.

So feel free to look at the decision for the netmod group as to follow 
option a, or not to follow a.

Once the decision is made,  we certainly will sync up with netconf chairs.

Thanks,
Lou

---

From: Andy Bierman <[email-masked]>
Date: Sun, 19 Jun 2016 08:23:36 -0700

> consensus of  the NETCONF WG.

I disagree.
I have implemented NETCONF and RESTCONF and I do not see any problems with
adding additional (optional) datastores.

As often the case in the IETF, when a WG does not have consensus on a
particular
topic, the standard is silent on that topic.  That is what happened with
config=false in RFC 6241
and 6020.  I don't see a problem with a datastore model that evolves over
time.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 27 Jun 2016 14:44:52 +0000

[as a contributor]

I’m for ‘B’ as well, in case it wasn’t obvious from [2]  (Lou’s ref below).

Kent

From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <[email-masked]>
Date: Friday, June 17, 2016 at 2:36 PM
To: Lou Berger <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Kent Watsen <[email-masked]>, <[email-masked]>
Resent-Date: Friday, June 17, 2016 at 2:36 PM

Hi All
I’d like to support Option B below.

Thanks
Kiran

---

From: Kent Watsen <[email-masked]>
Date: Mon, 27 Jun 2016 14:53:01 +0000

[as a contributor]

I disagree.

KENT > Right, but mapping the solution to drafts is key.  For instance, would there be one draft to define the conceptual model and then two other drafts for mapping that model to NETCONF and RESTCONF?   And if so, to Tom’s point, should those drafts go through the NETCONF WG?

Tom Petch

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Jun 2016 09:47:24 -0700

On Mon, Jun 27, 2016 at 7:53 AM, Kent Watsen <[email-masked]> wrote:

> KENT > Right, but mapping the solution to drafts is key.  For instance,
> would there be one draft to define the conceptual model and then two other
> drafts for mapping that model to NETCONF and RESTCONF?   And if so, to
> Tom’s point, should those drafts go through the NETCONF WG?
>
>
>

I don't have any plans to implement this new work.
I expect it to be similar to the "candidate" datastore.
If I do not support the candidate datastore, the added cost to
my implementation is ZERO.

RFC 6241 uses an extensible design for datastores.
(Parameter is a container with a choice of N empty leafs).
Adding a new leaf that represents a datastore is almost free in NETCONF.
(a few augment statements).

The <edit-config> and <commit> operations do not specify an exact
validation procedure
for datastores. YANG defines the validation rules for datastores.
IMO YANG needs to be revised, not NETCONF.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 27 Jun 2016 18:14:07 +0000

> IMO YANG needs to be revised, not NETCONF.

No, RFC6241 defines ietf-netconf.yang that hardcodes datastore names, so it needs to be updated or maybe even replaced.

Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Jun 2016 11:21:58 -0700

On Mon, Jun 27, 2016 at 11:14 AM, Kent Watsen <[email-masked]> wrote:

> No, RFC6241 defines ietf-netconf.yang that hardcodes datastore names, so
> it needs to be updated or maybe even replaced.
>
>
>

Hard-wired to allow augments from a different module:

augment /nc:get-config/nc:input/nc:source/nc:config-choice {
    case operational {
      leaf operational {
         type empty;
         if-feature operational;
      }
   }
}

Kent

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 27 Jun 2016 18:41:43 +0000

Right, that would be “updating” it, and RESTCONF would need a similar thing.  My point, and I think Tom’s too, is that it makes sense that the NETCONF (not NETMOD) WG do the protocol mapping work.  Do you disagree?

K.

From: Andy Bierman <[email-masked]>
Date: Monday, June 27, 2016 at 2:21 PM
To: Kent Watsen <[email-masked]>
Cc: "t.petch" <[email-masked]>, "[email-masked]" <[email-masked]>, Lou Berger <[email-masked]>
Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput

Kent

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Jun 2016 12:03:43 -0700

On Mon, Jun 27, 2016 at 11:41 AM, Kent Watsen <[email-masked]> wrote:

>
>
> Right, that would be “updating” it, and RESTCONF would need a similar
> thing.  My point, and I think Tom’s too, is that it makes sense that the
> NETCONF (not NETMOD) WG do the protocol mapping work.  Do you disagree?
>
>
>

Actually, YANG is designed such that the original document does not
need to be aware of any augmentations.

I agree that protocol operations are not in scope for NETMOD WG.
This is not clear to anybody who reads RFC6020bis, where NETCONF
definitions are clearly intermixed with the data modeling language.

Andy

>
>
> *From: *Andy Bierman <[email-masked]>
> *Date: *Monday, June 27, 2016 at 2:21 PM
> *To: *Kent Watsen <[email-masked]>
> *Cc: *"t.petch" <[email-masked]>, "[email-masked]" <[email-masked]>,
> Lou Berger <[email-masked]>
> *Subject: *Re: [netmod] Opstate solutions discussions: update and request
> for WGinput
>
>
>
>
>
>
>