Re: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK)

[Kent Watsen <[e-mail]>]

My take is that, once we update NC/RC to support the intended, dynamic, and operational datastores, that will go a long way towards achieving what I2RS needs, maybe even all the way.  That said, I don’t know how generic some of the things discussed in the following can be made:

  draft-hares-netmod-i2rs-yang
  draft-hares-netconf-i2rs-netconf
  draft-hares-netconf-i2rs-restconf

For instance, the secondary priority concept seems very unique to I2RS and thus may entail an I2RS-specific parameter passed in <edit-data>.  For extensions such as this, I would think they'd be done in I2RS.

To answer Benoit's question, I agree that #7 seems out of place.  If we remove it, then #6 might be better written:

OLD
  Based on the revised datastore concept work in NETMOD, ...
NEW
  Based on the revised datastore concept work in NETMOD, and
  protocol requirements provided by I2RS, ...


Thoughts?

Kent


On Tue, Apr 25, 2017 at 10:52:02AM +0200, Benoit Claise wrote:
> Dear all,
> 
> In order to progress this charter, I would like to clarify one point with
> the revised datastore concept authors. See below.

[...]
 
> The last question is: what is the right place for this  "I2RS datastore
> semantic, persistence, guidelines, along with the notion of priorities"
> document?

Here is my take:

a) Once we have NMDA extensions in place, the protocols (NETCONF and
   RESTCONF) should not need any additional protocol work to support
   I2RS. If the NETCONF WG, for whatever reason, fails to reach this
   goal, then I think it should be the NETCONF WG's task to fix this.

b) Once we have NMDA extensions in place, the definition of an I2RS
   datastore with its specific semantics should be done in the I2RS
   working group. None of this should require _changes_ to the NMDA
   enabled NETCONF/RESTCONF protocols or the YANG language. If the
   NETCONF WG and the NETMOD WG, for whatever reason, fails to reach
   this goal, then I think it should be the NETCONF or NETMOD WG's
   task to fix this.

In other words, my hope is that the NMDA solution provides a workable
separation of concerns.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf