Subject: [Netconf] nmda-restconf operations (was: netconf-binary-encoding comments)

From: Kent Watsen <[email-masked]>
Date: Mon, 9 Jul 2018 17:21:26 +0000

[changing the subject line]

>> nmda-restconf preserves the /data resource from RFC 8040.  My comment
>> is more about the lack of information for when the client chooses to use
>> <running> or <candidate> instead.  Maybe it's obvious, not sure, hence the
>> comment.
>
> If my understanding is correct, when :writable-running capability is
> supported, the client will chose to use <running>,only when <candidate>
> capability is supported, the client will choose to use <candidate>.

This isn't what I meant.  To be more specific, I'm wondering if the nmda-restconf
draft would benefit from having a sentence like:

   A RESTCONF server supporting NMDA datastores MAY implement the
   "ietf-netconf" [RFC6241] and "ietf-netconf-nmda" [I-D. ietf-netconf-nmda-
   netconf] modules to enable the NETCONF operations defined in those
   drafts to appear {+restconf}/operations resource.

Note: I put "MAY" as RESTCONF may someday have a more native way to do this.

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Jul 2018 19:30:41 +0200

> Note: I put "MAY" as RESTCONF may someday have a more native way to do this.

Well, "ietf-netconf" does not really support NMDA well and this is why
we have "ietf-netconf-nmda". Does not make much sense to point to
"ietf-netconf" in an NMDA document.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 9 Jul 2018 17:48:57 +0000

> "ietf-netconf" in an NMDA document.

But we'd still need lock, unlock, commit, commit-confirmed, etc., right?

Maybe it's a moot point, since ietf-netconf-nmda requires that ietf-netconf
is implemented too, but I thought being explicit would be helpful here. 

So, adding something like this to nmda-restconf would be good?

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Jul 2018 20:13:38 +0200

> But we'd still need lock, unlock, commit, commit-confirmed, etc., right?

Yep.
 
> is implemented too, but I thought being explicit would be helpful here.

As long as readers get the idea that implementing lets say edit-config
is perhaps not the best idea...
 
> So, adding something like this to nmda-restconf would be good?

It likely does not hurt to be clear that this option of using NETCONF
operations in RESTCONF exists.

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 10 Jul 2018 11:43:08 +0100

>> But we'd still need lock, unlock, commit, commit-confirmed, etc., right?
OK.  Just to check - the client can determine which of these operations 
are supported via the feature statements in ietf-netconf.yang and the 
corresponding module entry in YANG library bis?

I was wondering whether a GET request on {+restconf}/operations would 
also list all of the supported operations, but as far as I can see RFC 
8040 doesn't specify this.

> is perhaps not the best idea...
It might be a good idea to explicitly list the NETCONF operations that 
are not well defined and hence SHOULD NOT be implemented.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jul 2018 13:37:38 +0200

On Tue, Jul 10, 2018 at 11:43:08AM +0100, Robert Wilton wrote:
> OK.  Just to check - the client can determine which of these operations are
> supported via the feature statements in ietf-netconf.yang and the

The YANG module ietf-netconf is at the end nothing special. So clients
should treat it like any other module. If the yang-library says this
module is implemented, then it is implemented and features will work
exactly like they work for any other module.

> It might be a good idea to explicitly list the NETCONF operations that are
> not well defined and hence SHOULD NOT be implemented.

It is risky to repeat what other documents already discuss since doing
so raises the risks of producing inconsistencies and it may create
additional headaches when document updates are made later on.

Note that draft-ietf-netconf-nmda-netconf-06 also extends <lock> and
<unlock> to handle NMDA datastores. I think a pointer to this I-D is
relevant, I am less sure about ietf-netconf. Someone implementing
<candidate> likely figures out that without implement <commit>, this
<candidate> datastore is not very usable.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Jul 2018 13:22:56 +0200

> But we'd still need lock, unlock, commit, commit-confirmed, etc.,

These would make RESTCONF server stateful, thus violating REST principles. My
draft

https://datatracker.ietf.org/doc/draft-lhotka-netconf-restconf-transactions/

tries to achieve similar effects in a RESTful way.

Lada

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Jul 2018 08:40:30 -0700

> tries to achieve similar effects in a RESTful way.

I like the idea of "private candidate" datastores you call "staging".
I would keep the term candidate.

This idea was discussed during RESTCONF draft development, but
as the client creating a "transaction" resource. I think your draft is on
the right track, and datastores are protocol-independent so NETCONF
can use the same datastores with RPC operations.

You ignore the problem of concurrent edits, which is why this idea was not
pursued
at the time. What happens when the altered data overlaps across private
candidates?
What are the procedures equivalent to git pull, push, merge?
How are collisions handled? What exactly is a collision?
Not trivial standards issues to solve.

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Jul 2018 19:16:25 +0200

> I would keep the term candidate.

The problem with this is that <candidate> in NETCONF has a looser semantics (it
can also be shared).

> can use the same datastores with RPC operations.

Yes, it can certainly be improved. I already have some pending updates, but I
wanted to keep it simple for start.

> at the time. What happens when the altered data overlaps across private

I don't ignore it, the text says that the user's staging datastore has to be
atomically merged into <intended>, I just didn't want to specify the procedure.
In any case, the result has to be a valid <intended>. But I am open to a
discussion.

> Not trivial standards issues to solve.

I think it can be left open, I even suspect there is no universal solution
suitable for all use cases. Our implementation (JetConf) does the following:

- each user's edit operation is applied to the staging datastore and also
recorded in a journal

- at commit, if <intended> hasn't been changed in the mean time, then the
staging datastore simply becomes <intended>

- otherwise, the edit operations from the journal are applied sequentially on
the actual contents of <intended>.

(Actually, we are not NMDA-compatible yet and don't have <intended> but it works
this way).

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jul 2018 07:43:48 -0700

On Wed, Jul 11, 2018 at 10:16 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > >>>    "ietf-netconf" [RFC6241] and "ietf-netconf-nmda" [I-D.
> ietf-netconf-
> > > nmda-
> > > >>> Note: I put "MAY" as RESTCONF may someday have a more native way
> to do
> > > this.
> > > >>>
> > > >>
> > > These would make RESTCONF server stateful, thus violating REST
> principles.
> > > My
> > > draft
> > >

Leaving it as an implementation detail is the IETF's way of ignoring
problems.

> the actual contents of <intended>.

This is "last one wins".
You will find this sort of works for create and merge but no so much for
replace and delete.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 16 Jul 2018 14:57:11 +0200

> Leaving it as an implementation detail is the IETF's way of ignoring

Here, the situation may be further complicated by factors that are not
present in git, such as NACM or validation issues. But in fact, the
particular procedure is not so important from the protocol viewpoint:
by issuing the commit operation, the client says: "Dear server, here is
my intention how the configuration should look like, do whatever you can
to merge it with the existing config."

>> the actual contents of <intended>.

No, as I wrote, if an operation writes data that were changed in the
mean time, the commit fails.

Lada