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

[Benoit Claise <[e-mail]>]

On 4/25/2017 8:45 PM, Kent Watsen wrote:
> 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, ...
That makes sense.

Alia, fine with you?

Regards, B.
>
> 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
>