Re: [Netconf] Comments on draft-lhotka-netconf-restconf-transactions-00

Mahesh Jethanandani <mjethanandani@gmail.com> writes:

> WG,
>
> This draft now is on the agenda for the meeting on Monday, afternoon session #I from 13:30-15:30.
>
> Lada, you do have your 15 min.

Thanks a lot, Lada

>
> Mahesh & Kent.
>
>> On Jul 11, 2018, at 9:36 AM, Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org> wrote:
>> 
>> Hi Lada,
>> 
>> I've had a read of this draft, and have provided some comments below.
>> 
>> So, my top level comment is that I don't know whether or not RESTCONF needs this functionality or not.  I've heard some operators state that they think that clients can just construct an "atomic" change, and hence don't have the need for a server side staging area.  Perhaps a good question to ask in Montreal?
>> 
>> The rest of my comments below, apply to the proposed technical solution, and obviously only apply if this is a needed enhancement. :-)
>> 
>> 1) Generally, I definitely prefer the idea of per session staging areas (aka private candidates) described in this draft over a shared lockable candidate datastore.  This follows my belief that loosely coupled concurrent systems are more robust than tightly coupled ones (e.g. with shared locking).
>> 
>> 2) I don't think that this draft needs to mention <intended> at all.  Instead, everywhere you mention <intended> then you should be saying <running>.  I.e. your staging datastores should update <running> on a commit operation, just like a commit of <candidate> updates <running>.  <intended> is always just updated as a side effect of a write to <running>, and as such is a tangential consideration.
>> 
>> 3) Rather than having clients interact via {+restconf}/data, I think that it would be much better to require NMDA and then have clients interact via {+restconf}/ds/ietf-restconf-transactions:staging, as per draft-ietf-netconf-nmda-restconf-04 section 3.1.  The new staging datastore identity should also be defined in your module to inherit from ietf-datastores:datastore identity.  I think that this probably also more closely aligns to restful principals.
>> 
>> 4) So, I think that the <staging> datastore itself only contains the proposed changes (additions, modifications, and deletes) to <running> when they are committed.  I think that clients may also want to see the combined configuration of the current contents of <running> with the delta held in <staging> applied.  This could be exposed either as (i) a new RPC, (ii) as an extra query parameter or (iii) As another read-only datastore.  A new RPC has the disadvantage that it probably wouldn't support all the query parameters, so my instinctive preference would be to one of the other two latter options.
>> 
>> 5) If private candidate datastores are being added to RESTCONF, then should they also be added to NETCONF?  If they are added to both then I think that they should be added in the same way, as much as possible, perhaps both could be updated in a single draft to save repetitive text?  In general, I like (Kent's?) idea of NETCONF WG writing a RFC that describes all the common parts of NETCONF and RESTCONF that the individual protocol docs can then reference rather than writing similar or equivalent text in two places.
>> 
>> But otherwise, I think that it is an interesting idea, and certainly warrants some WG discussion.
>> 
>> Thanks,
>> Rob
>> 
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67