Re: [netmod] Opstate solutions discussions: update and request for WGinput

[Andy Bierman]

On Mon, Jun 27, 2016 at 11:41 AM, Kent Watsen <kwat...@juniper.net> 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.




> K.
>

Andy


>
>
> *From: *Andy Bierman <a...@yumaworks.com>
> *Date: *Monday, June 27, 2016 at 2:21 PM
> *To: *Kent Watsen <kwat...@juniper.net>
> *Cc: *"t.petch" <ie...@btconnect.com>, "netmod@ietf.org" <netmod@ietf.org>,
> Lou Berger <lber...@labn.net>
> *Subject: *Re: [netmod] Opstate solutions discussions: update and request
> for WGinput
>
>
>
>
>
>
>
> On Mon, Jun 27, 2016 at 11:14 AM, Kent Watsen <kwat...@juniper.net> wrote:
>
> > 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.
>
>
>
>
>
>
>
> 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
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Opstate solutions discussions: update and request for WGinput

[Andy Bierman]

On Mon, Jun 27, 2016 at 7:53 AM, Kent Watsen  wrote:

> [as a contributor]
>
>
>
> 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.
>
>
>
> I disagree.
>
> I have implemented NETCONF and RESTCONF and I do not see any problems with
>
> adding additional (optional) datastores.
>
>
>
>
>
> 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  and  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.




>
>
>
> Tom Petch
>
>
>
> Andy
>
>
>
>
>

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

Re: [netmod] Opstate solutions discussions: update and request for WGinput

[Kent Watsen]

[as a contributor]

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.

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


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


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

Re: [netmod] Opstate solutions discussions: update and request for WGinput

[Kent Watsen]

[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)" <kkous...@cisco.com>
Date: Friday, June 17, 2016 at 2:36 PM
To: Lou Berger <lber...@labn.net>
Cc: "netmod-cha...@ietf.org" <netmod-cha...@ietf.org>, "netmod@ietf.org" 
<netmod@ietf.org>
Subject: Re: [netmod] Opstate solutions discussions: update and request for 
WGinput
Resent-From: <alias-boun...@ietf.org>
Resent-To: <j.schoenwael...@jacobs-university.de>, <lber...@labn.net>, Kent 
Watsen <kwat...@juniper.net>, <mishra.ash...@outlook.com>
Resent-Date: Friday, June 17, 2016 at 2:36 PM

Hi All
I’d like to support Option B below.
>> 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].

Thanks
Kiran


>> 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.
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org<mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>


___
netmod mailing list
netmod@ietf.org<mailto: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] Opstate solutions discussions: update and request for WGinput

[t . petch]

Lou

You say below
"
> 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.
"

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" <lber...@labn.net>
To: "t.petch" <ie...@btconnect.com>; "netmod WG" <netmod@ietf.org>
Cc: <netmod-cha...@ietf.org>
Sent: Friday, June 17, 2016 7:22 PM
Subject: Re: [netmod] Opstate solutions discussions: update and request
for WGinput


> 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.
>
> On 6/17/2016 11:15 AM, t.petch wrote:
> > Lou
> >
> > By now, 17th June, I see solid support for one option but only see
> > comments from a somewhat small number of participants
> This is true, and I've heard privately that some more may/should be
> forthcoming.
>
> > 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.
>
> 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.
>
> > 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.
> 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.
>
> > 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 draf

Re: [netmod] Opstate solutions discussions: update and request for WGinput

[Kiran Koushik Agrahara Sreenivasa (kkoushik)]

Hi All
I'd like to support Option B below.
>> 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].

Thanks
Kiran


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

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

Re: [netmod] Opstate solutions discussions: update and request for WGinput

[Andy Bierman]

On Fri, Jun 17, 2016 at 11:22 AM, Lou Berger  wrote:

> 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.
>
> On 6/17/2016 11:15 AM, t.petch wrote:
> > Lou
> >
> > By now, 17th June, I see solid support for one option but only see
> > comments from a somewhat small number of participants
> This is true, and I've heard privately that some more may/should be
> forthcoming.
>
> > 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.
>
> 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.
>
>
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  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


> 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.
> 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.
>
> > 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.
> 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
> > Tom Petch
> >
> > - Original Message -
> > From: "Lou Berger" 
> > To: "netmod WG" 
> > Cc: 
> > Sent: Tuesday, June 07, 2016 3:19 PM
> >
> >> 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 

Re: [netmod] Opstate solutions discussions: update and request for WGinput

[Lou Berger]

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.

On 6/17/2016 11:15 AM, t.petch wrote:
> Lou
>
> By now, 17th June, I see solid support for one option but only see
> comments from a somewhat small number of participants
This is true, and I've heard privately that some more may/should be
forthcoming.

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

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.

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

> 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.
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
> Tom Petch
>
> - Original Message -
> From: "Lou Berger" 
> To: "netmod WG" 
> Cc: 
> Sent: Tuesday, June 07, 2016 3:19 PM
>
>> 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 

Re: [netmod] Opstate solutions discussions: update and request for WGinput

[t . petch]

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

- Original Message -
From: "Lou Berger" 
To: "netmod WG" 
Cc: 
Sent: Tuesday, June 07, 2016 3:19 PM

> 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.
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod