Re: [Netconf] Review of draft-lhotka-netconf-restconf-transactions-00

[Ladislav Lhotka <[e-mail]>]

Hi Qin,

please see my responses inline.

Qin Wu <[e-mail]> writes:

> Hi, Lada:

> I like this idea in draft-lhotka-netconf-restconf-transactions-00 and
> add transaction support for RESTCONF.  use transactions to support
> robust configuration change involving a number of devices.
>
> I am wondering, how do you write content from client staging 
> datastore into readonly intended datastore? Usually if we want

<intended> is read-only as before, the client cannot directly write
it. 

> to see the content in client staging datastore be part of 
> intended datastore, we should first run commit operation 
> defined in RFC6241, make content in client staging datastore

Exactly, and we have the "rct:commit" operation for this purpose.

> be part of running datastore, Any then after validation

The text also mentions that <intended> can be considered identical to
<running> (NMDA supports this shortcut). We don't use <running>
explicitly though.

> process, the client staging datastore content can be part of intended.

Yes, validation has to be a part of the commit/merge procedure, as NMDA
requires <intended> to be always valid.

> Right?
>
> Second question is do we support rollback operation and allow rollback to some restore checkpoint
> Or roll back to factory default setting?

This may of course be a useful addition in some (but not all)
situations. My aim with this draft was to enable support for
transactions and multi-client access with as little extra complexity as
possible.

Thanks, Lada

>
> -Qin
> -----邮件原件-----
> 发件人: Ladislav Lhotka [mailto:[e-mail]] 
> 发送时间: 2018年6月28日 16:30
> 收件人: Qin Wu
> 主题: Re: draft-lhotka-netconf-restconf-transactions-00
>
> On Thu, 2018-06-28 at 02:58 +0000, Qin Wu wrote:
>> Hi, Lada:
>> Would you like to provide a few comments on 
>> draft-wu-netconf-restconf-factory-
>> restore-00, chairs want to see some discussion on the list before the meeting.
>> I can help provide review on draft-lhotka-netconf-restconf-transactions-00.
>
> Hi Qin,
>
> this mutual review is a good idea, I will do it.
>
> Thanks, Lada
>
>> 
>> -Qin
>> -----邮件原件-----
>> 发件人: Ladislav Lhotka [mailto:[e-mail]]
>> 发送时间: 2018年6月27日 18:04
>> 收件人: Qin Wu
>> 主题: Re: draft-lhotka-netconf-restconf-transactions-00
>> 
>> Hi Qin,
>> 
>> sorry I didn't respond sooner, I am currently out of office. Regarding 
>> my coauthoriship, I made no real contribution - just publish it as the 
>> only author.
>> We'll see what's going to happen, one option might be to combine our 
>> drafts later, but it is up to the WG.
>> 
>> Lada
>> 
>>  
>> On Wed, 2018-06-27 at 04:11 +0000, Qin Wu wrote:
>> > Ping your feedback, thanks.
>> > 
>> > -Qin
>> > -----邮件原件-----
>> > 发件人: Qin Wu
>> > 发送时间: 2018年6月26日 9:52
>> > 收件人: 'Ladislav Lhotka'
>> > 主题: RE: draft-lhotka-netconf-restconf-transactions-00
>> > 
>> > Agree with your suggestion, Lada, here is update based on your comments.
>> > I add you as coauthor, let me know if you approve to publish this version.
>> > 
>> > -Qin
>> > -----邮件原件-----
>> > 发件人: Ladislav Lhotka [mailto:[e-mail]]
>> > 发送时间: 2018年6月25日 22:38
>> > 收件人: Qin Wu
>> > 主题: RE: draft-lhotka-netconf-restconf-transactions-00
>> > 
>> > Hi Qin,
>> > 
>> > I would like to keep it as simple as possible for the initial 
>> > presentation to the working group (which I hope will take place in 
>> > Montreal). If there is enough interest, and perhaps the draft 
>> > becomes a WG item, I am open to discuss additional features.
>> > 
>> > Cheers, Lada
>> > 
>> > Qin Wu <[e-mail]> writes:
>> > 
>> > > Lada:
>> > > One more idea is to add capability to support restoring the 
>> > > configuration to any configuration checkpoint.
>> > > e.g., we can roll back the system configuration to a specified 
>> > > checkpoint by user label.
>> > > Or we can roll back the system configuration to a specified 
>> > > checkpoint by checkpoint number.
>> > > 
>> > > -Qin
>> > > -----邮件原件-----
>> > > 发件人: Qin Wu
>> > > 发送时间: 2018年6月21日 15:22
>> > > 收件人: 'Ladislav Lhotka'
>> > > 主题: RE: draft-lhotka-netconf-restconf-transactions-00
>> > > 
>> > > Hi, Lada:
>> > > Sorry for late reply.
>> > > Here is the strawman proposal on factory default setting.
>> > > I come up with two use cases in section 3.2 and section 3.3.
>> > > Let me know if the problem space and solution make sense to you.
>> > > Any interests to cosign if make sense.
>> > > 
>> > > -Qin
>> > > -----邮件原件-----
>> > > 发件人: Ladislav Lhotka [mailto:[e-mail]]
>> > > 发送时间: 2018年6月18日 18:38
>> > > 收件人: Qin Wu
>> > > 主题: Re: draft-lhotka-netconf-restconf-transactions-00
>> > > 
>> > > On Mon, 2018-06-18 at 09:57 +0000, Qin Wu wrote:
>> > > > -----邮件原件-----
>> > > > 发件人: Ladislav Lhotka [mailto:[e-mail]]
>> > > > 发送时间: 2018年6月18日 16:01
>> > > > 收件人: Qin Wu
>> > > > 主题: Re: draft-lhotka-netconf-restconf-transactions-00
>> > > > 
>> > > > Hi Qin,
>> > > > 
>> > > > Qin Wu <[e-mail]> writes:
>> > > > 
>> > > > > Hi, Lada:
>> > > > > Interesting draft, it looks client staging datastore you 
>> > > > > proposed is a special case of candidate datastore,
>> > > > 
>> > > > Correct, it is basically a non-shared <candidate>.
>> > > > 
>> > > > > I am wondering, how do you write content from client staging 
>> > > > > datastore into readonly intended datastore? Usually if we want 
>> > > > > to see the content in client staging datastore be part of 
>> > > > > intended datastore, we should First run commit operation 
>> > > > > defined in RFC6241, make content in client staging datastore 
>> > > > > be part of running datastore, Any then after validation 
>> > > > > process, the client staging datastore content can be part of intended after validation.
>> > > > 
>> > > > In our implementation (JetConf [*]), we don't have NETCONF 
>> > > > underneath, so we want to make the workflow simple and explicit.
>> > > > 
>> > > > > 
>> > > > > Now you propose commit operation and reset operation specific 
>> > > > > to RESTCONF, I am wondering how do you write data directly 
>> > > > > into intended by merging operation? I am wondering the 
>> > > > > operation you proposed take place from <running> to intended 
>> > > > > or from <candidate> to <intended>
>> > > > 
>> > > > Our implementation does the following:
>> > > > 
>> > > > - edit operations of every user are applied in the staging datastore but
>> > > >   also kept in a journal
>> > > > 
>> > > > - at commit, if <intended> hasn't been modified in the mean time, the
>> > > >   users's staging datastore simply becomes the new <intended>
>> > > > 
>> > > > - if <intended> has been modified, we replay the edit operations from
>> > > >   the journal
>> > > > [Qin]: Thank for clarification, can you explain what the 'journal' is?
>> > > 
>> > > It is a record of all operations performed by the user since the 
>> > > last reset so that they can be replayed later.
>> > > 
>> > > >  
>> > > > > 
>> > > > > Another thought, do you think factory reset operation is needed?
>> > > > > In some case, we may need to make running datdstore and 
>> > > > > startup datastore to return to factory defaults.
>> > > > > Based on RFC6241, we only can use delete-config to return 
>> > > > > startup datastore to factory default, however We can not 
>> > > > > directly use delete-config to return running datastore into 
>> > > > > factory default.
>> > > > > Do you think new operation such as factory reset should be 
>> > > > > defined for this?
>> > > > 
>> > > > Possibly, but I think it is a different problem that may be 
>> > > > relevant for standard RESTCONF, too.
>> > > > 
>> > > > [Qin]: Yes, you are right, are you interested in this problem space?
>> > > > Let me know if there is a value to document a solution for this.
>> > > 
>> > > We currently don't have a use case for this but it can certainly 
>> > > be useful.
>> > > Another related topic is the use of <startup> in RESTCONF.
>> > > 
>> > > Lada
>> > > 
>> > > > 
>> > > > Thanks, Lada
>> > > > 
>> > > > [*] https://pypi.org/project/jetconf/
>> > > > 
>> > > > > Look forward to your reply.
>> > > > > 
>> > > > > -Qin
>> > > > 
>> > > > --
>> > > > Ladislav Lhotka
>> > > > Head, CZ.NIC Labs
>> > > > PGP Key ID: 0xB8F92B08A9F76C67
>> > > 
>> > > --
>> > > Ladislav Lhotka
>> > > Head, CZ.NIC Labs
>> > > PGP Key ID: 0xB8F92B08A9F76C67
>> > 
>> > --
>> > Ladislav Lhotka
>> > Head, CZ.NIC Labs
>> > PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67

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