Subject: [Netconf] YANG Patch Issue #3: :distinct-startup

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Jun 2015 10:29:36 -0700

Hi,

A new issue has been raised for the YANG Patch draft.

https://github.com/netconf-wg/yang-patch/issues/3

There is no support for the client to control
when running is saved to startup.  If this is a concern,
it needs to be addressed.  If not (i.e., just use
NETCONF for this level of client control) then
it does not need to be addressed.

Please review the latest draft and the issue list and
send comments to the mailing list.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Jun 2015 10:20:05 +0200 (CEST)

> it does not need to be addressed.

Isn't this a RESTCONF issue, rather than YANG PATCH issue?  YANG
PATCH defines a format for applying to patches to a YANG data store.
Which data store to apply the patches to is handled by the protocol
(RESTCONF).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 02:31:56 -0700

Hi,

Perhaps this is a RESTCONF issue.
It has not been accepted as an open issue.
IMO this can be left out.
RESTCONF has a unified datastore.
For access to individual datastores, use NETCONF.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 11:47:09 +0200

> For access to individual datastores, use NETCONF.

Looking at section 1.3 of draft-ietf-netconf-restconf-05, should the
text be more explicit about the details? I mean, if the candidate is
used, is it cleared first or do any pending edits in candidate become
part of the commit? Is a server supporting both NETCONF and RESTCONF
going to use locks on <running/> or <candidate/> during the processing
of a RESTCONF edit or is that left up to the implementor to decide?

Is the copy to startup something that happens after each edit? This
may be pretty expensive if a RESTCONF client is pushing many small
edits in a loop (not unlikely that we see such clients I would say).

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 07:18:28 -0700

> of a RESTCONF edit or is that left up to the implementor to decide?

It works justlike like NETCONF.
If the candidate is unlocked and dirty, the pending edits get
committed.

> edits in a loop (not unlikely that we see such clients I would say).

There were multiple proposals suggested to the WG to add a query
parameter to control nv-save.  The WG was not interested
in any of them.  Use NETCONF to access the individual datastores.
RESTCONF has no direct access to any NETCONF datastores.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 16:31:02 +0200

> If the candidate is unlocked and dirty, the pending edits get

I think this should be mentioned to avoid surprises.
 
> RESTCONF has no direct access to any NETCONF datastores.

I am interested in what I can expect from a RESTCONF server. If every
RESTCONF edit causes an NV write (and this is how I read the current
text), then my performance expectations are likely a down to NV write
speed. On some of my boxes, this is really slow. Hence, my expectation
is that implementors will cheat a bit and do delayed writes (but then
I never know when something really got written).

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 07:57:42 -0700

> I never know when something really got written).

Then it might be better to use NETCONF without :distinct-startup,
so there is no requirement to ever save the running datastore
to non-volatile storage.

If startup can be different than running, then the client
needs to retrieve running and startup and compare them.
Individual datastore access could be added in another RFC
and include startup.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 17:11:02 +0200

> so there is no requirement to ever save the running datastore

I do want to safe to non-volatile storage and I am concerned about the
performance if every RESTCONF edit goes to NV storage on its own.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 08:27:13 -0700

> performance if every RESTCONF edit goes to NV storage on its own.

This is what NETCONF servers actually do if there is no startup config.

I agree this can be slow.
I made a proposal to address the NV-storage  (nv-save=true|false)
but not retrieval of the startup datastore.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 19:57:55 -0700

...
> performance if every RESTCONF edit goes to NV storage on its own.

I haven't seen much interest in this problem.
The problem needs to be clearly scoped.
Problem: NV-storage is expensive so if the server supports
the :startup capability then control of NV-storage should be provided
in RESTCONF.

   Query parameter "nv-save"

   leaf nv-save {
     if-feature nc:startup;
     type boolean;
     default true;
     description
       "If 'true' then save the edits to non-volatile storage.
        If 'false' then do not save the edits to non-volatile
        storage. Only applies to configuration edits.";
   }

POST/restconf/data/some/data1?nv-save=false
POST /restconf/data/some/data2?nv-save=false
POST /restconf/data/some/data3

The edits for data1 and data2 are not saved to startup.
The edit 'data3' saves all of running to startup.
Another client can do 'nv-save' before this one.
This client will save any edits to running, not just its own.
(Shared running datastore!)

There is no read or write access directly to the NETCONF 'startup'
datastore. Access to datastores is a different topic.
This solution simply provides control over NV-storage
if the server supports it.

Do you think this solution will work?
If not, do you have a different one?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 20:12:42 -0700

Hi,

I forgot about the other solution we already discussed,
that does not require any new query parameters

  POST /restconf/operations/ietf-netconf:copy-config

  {"ietf-netconf:input":{
     "source":{
       "running":null
     },
     "target":{
       "startup":null
     }
   }
  }

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Jun 2015 07:47:51 +0200

This is fine except how do I decide whether I have to use this
copy-config? If a server does not support :startup, then each edit
still leads to an NV write?

I am OK with using this approach if the specification provides enough
clarity that application developers know how to do this right. (I
actually like this approach more than magic query parameters.)

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Jun 2015 23:08:36 -0700

> still leads to an NV write?

I guess a RESTCONF capability for startup is needed.
We already have one for with-defaults.

> actually like this approach more than magic query parameters.)

The <get-config> operation can be accessed the same
way to read the startup datastore.

But this would mean the server never automatically
does an NV-save (just like NETCONF) if :startup
is advertised.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Jun 2015 08:14:57 +0200 (CEST)

> the :startup capability then control of NV-storage should be provided

I would state this a bit differently: In a traditional implementation
of a distinct startup configuration, saving running to startup is
expensive, so if the server supports the :startup capability then
control of when to save to startup should be provided in RESTCONF.

Copy to startup doesn't *have* to be expensive (it is
implementation dependent), and a system that implements writable
running only has probably made sure that each edit is pretty cheap.

My point is that it is not the NV-storage per se that is expensive.

>    Query parameter "nv-save"

Should the leaf be called 'copy-to-startup'?  Or 'save-to-startup'?

'nv-save' is correct, but maybe a bit misleading.

>        "If 'true' then save the edits to non-volatile storage.
                                  ^^^^^

Actually, it will do more - it will also copy any other unsaved edits
to nv-storage.

That's why I would prefer to call it 'copy-to-startup', and explain
this in the text.

> Do you think this solution will work?

Is there a way to first do the equivalent of copy-running-to-startup,
i.e., do this POST w/o any additional parameters?

> If not, do you have a different one?

POST /restconf/.../copy-to-startup  (with no body)

But you idea is better, since it avoids a round-trip in some cases.

/martin

---

From: t.petch <[email-masked]>
Date: Tue, 9 Jun 2015 10:41:47 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Tuesday, June 09, 2015 6:47 AM

> actually like this approach more than magic query parameters.)

I agree that the specification should provide clarity.

This issue did surface with vanilla Netconf, I think as a result of
I2RS, with the supposition that what had been implemented was a NV write
for each edit when there was no startup:; but I think that it should be
specified.

(There may also have been a supposition that no :startup was rare but
IOT and other low capacity devices might change that).

Tom Petch

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Jun 2015 18:51:10 +0000

>if the server supports it.

How can a client save all of running to startup outside of an edit
operation?  E.g., make some changes, do some tests, persist running only
if tests pass.  Assuming the URL points to a data node (e.g.,
/restconf/data/), none of POST/PUT/DELETE seem to work.  PATCH with an
empty patch-set might work, but PATCH is optional, so not a good choice.

The ietf-netconf:copy-config operation approach resolves the above concern
but, since it doesn't support Etag, the client would have to do something
like:

  1. POST /restconf/operations/ietf-netconf:lock
  2. HEAD /restconf/data  (verify Etag is as expected)
  3. POST /restconf/operations/ietf-netconf:copy-config
  4. POST /restconf/operations/ietf-netconf:unlock

Which looks dreadfully verbose

>If not, do you have a different one?

How about an "action" statement called "save" on the /restconf/data?

   POST /restconf/data/save HTTP/1.1
   If-Match: c3a3e673bc2c

...or, as discussed off list before (see below), embrace NETCONF
datastores in a RESTful manner, which would give:

   POST /restconf/running/save HTTP/1.1
   If-Match: c3a3e673bc2c

===== FROM BEFORE =====

RESTCONF/NETCONF datastore gaps (in priority order):

  1) no support for confirmed-commit, without which a NMS
     cannot safely push updates - i.e. w/o risking severing
     its connection to a networking device (router)

  2) no support for 2-phase commit, which complicates (but
     not prevent) the ability to do an atomic update on a
     plurality of devices

  3) no ability to explicitly save to persistent storage,
     which might drive devices to persist every update,
     which isn't necessarily what is wanted all the time.

  4) no ability to ask device to validate contents of a
     candidate datastore, which is only useful in that
     on-box validations are some times more thorough than
     what might be captured in the YANG schema.

Following is my RESTful proposal addressing all of the above.
It includes support for confirmed-commit, 2-phase commit,
explicit persistence, and validation.

High-level sketch of solution:

1. let there be URL entry points (datastores) like:
       {+restconf}/running
       {+restconf}/startup
       {+restconf}/candidate

2. let each datastore have its own Last-Modified / ETag headers

3. let the "candidate" datastore, if one exists, have "validate"
    and "commit" actions/methods

4. let the "running" datastore have a "confirmed" action, only
    if a "candidate" datastore exists.

5. let the "running" datastore have a "save" action, only if a
    "startup" datastore exists.

Concrete example below (validation, confirmed-commit, save to startup):

1) Update the candidate datastore:

   Request:

       PATCH /restconf/candidate/example-jukebox:jukebox/
          library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
       Host: example.com
       If-Match: a8389233a4a
       Content-Type: application/yang.data+json
       {
         "example-jukebox:album" : {
           "genre" : "example-jukebox:rock",
           "year" : 2011
         }
       }

   Response:

       HTTP/1.1 204 No Content
       Date: Mon, 23 Apr 2012 17:49:30 GMT
       Server: example-server
       Last-Modified: Mon, 23 Apr 2012 17:49:30 GMT
       ETag: b2788923da4b

2) Request device to validate contents of candidate datastore
     - note use of If-Match

   Request:

       POST /restconf/candidate/validate HTTP/1.1
       Host: example.com
       If-Match: b2788923da4b

   Response:

       HTTP/1.1 204 No Content   <------ No errors
       Date: Mon, 23 Apr 2012 17:50:00 GMT
       Server: example-server
       ETag: b2788923da4b     <------ SAME ETAG AS BEFORE SINCE
                                      DATASTORE UNCHANGED

3) Commit with a 2-minute confirmation timeout
      - note again the use of If-Match

   Request:

       POST /restconf/candidate/commit HTTP/1.1
       Host: example.com
       If-Match: b2788923da4b     <------ SAME ETAG AS BEFORE
       Content-Type: application/yang.operation+json
       {
         "confirm-timeout" : "120"
       }

   Response:

       HTTP/1.1 201 Created
       Date: Mon, 23 Apr 2012 17:01:00 GMT
       Server: example-server
       ETag: c3a3e673bc2c     <------- THIS IS THE ETAG FOR THE
                                       UPDATED RUNNING DATASTORE

4) Confirm the commit   (note use of If-Match)

   Request:

       POST /restconf/running/confirm HTTP/1.1
       Host: example.com
       If-Match: c3a3e673bc2c  <------ SAME AS BEFORE

   Response:

       HTTP/1.1 204 No Content    <------  SUCCESS
       Date: Mon, 23 Apr 2012 17:50:00 GMT
       Server: example-server
       ETag: c3a3e673bc2c   <------ SAME ETAG AS BEFORE
                                    SINCE DATASTORE UNCHANGED

5) Persist to startup datastore  (note use of If-Match)

   Request:

       POST /restconf/running/save HTTP/1.1
       Host: example.com
       If-Match: c3a3e673bc2c  <------ SAME AS BEFORE

   Response:

       HTTP/1.1 204 No Content  <!------ SUCCCESS
       Date: Mon, 23 Apr 2012 17:50:00 GMT
       Server: example-server

That's it, but if you disapprove of my use of ETag in step 3,
we could do this instead:

3.2) Commit with a 2-minute confirmation timeout

   Request:

       POST /restconf/candidate/commit HTTP/1.1
       Host: example.com
       If-Match: b2788923da4b
       Content-Type: application/yang.operation+json
       {
         "confirm-timeout" : "120"
       }

   Response:

       HTTP/1.1 201 Created
       Date: Mon, 23 Apr 2012 17:01:00 GMT
       Server: example-server
       Location: http://example.com/restconf/etags/c3a3e673bc2c
                               ^---- LOCATION ID RETURNED

4.2) Confirm the commit

   Request:

       POST /restconf/etags/c3a3e673bc2c/confirm HTTP/1.1
       Host: example.com       ^---- POST ON LOCATION ID

   Response:

       HTTP/1.1 204 No Content
       Date: Mon, 23 Apr 2012 17:50:00 GMT
       Server: example-server

---

From: Andy Bierman <[email-masked]>
Date: Tue, 9 Jun 2015 12:16:06 -0700

Hi,

I would say that NETCONF should be used
to get the features of NETCONF.

Locking does not work. Period.
There is no such thing as  a RESTCONF session.
NETCONF says drop the lock when the session goes away.
What does this mean in RESTCONF?  Nothing,
because there is no such thing as a RESTCONF session.

IMO, statefull, multi-step procedures that need intermediate
checking and course correction are only supported by NETCONF.

RESTCONF has a way to invoke operations.
It does not need to define new operations to reproduce the
functionality of NETCONF.

IMO this issue should move to DEAD because there is no
agreement on the scope of the problem and no agreement
on any solution.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 08:48:45 +0200

> agreement on the scope of the problem and no agreement

I do not think declaring issues DEAD can be a default solution
for the (sometimes painful process) of finding rough consensus.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jun 2015 00:44:14 -0700

> for the (sometimes painful process) of finding rough consensus.

The default is to not make a change if
there is no agreement on the change.
The draft has never had a "save-to-NV" button.
The default will be to keep it that way.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 11:06:42 +0200

> The default will be to keep it that way.

The I-D must document WG consensus.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jun 2015 13:42:56 +0200

> The I-D must document WG consensus.

FWIW, I am with Andy on this one.

RESTCONF servers needn't use NETCONF as their backend, and XML as their
native encoding.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 13:54:50 +0200

> RESTCONF servers needn't use NETCONF as their backend, and XML as their

It neeeds to be clear when changes persist or what the persistence
properties are of using RESTCONF - otherwise I can't build something
robust on top of it.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jun 2015 14:14:53 +0200

> On 10 Jun 2015, at 13:54, Juergen Schoenwaelder <[email-masked]> wrote:
> 

If persistence means that config data survive a clean shutdown, then my understanding is that the unified datastore is persistent. It doesn’t necessarily mean synchronous writes of every edit though.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 14:48:29 +0200

On Wed, Jun 10, 2015 at 02:14:53PM +0200, Ladislav Lhotka wrote:
> 
> If persistence means that config data survive a clean shutdown, then
> my understanding is that the unified datastore is persistent. It
> doesn’t necessarily mean synchronous writes of every edit though.

Again, all I am saying it needs to be crystal clear what the to be
expected behaviour is. You are bringing up another option - fine. What
I do not want is that every implementation can pick its own choice.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jun 2015 07:36:26 -0700

> I do not want is that every implementation can pick its own choice.

The draft is clear -- the server saves to NV-store after every edit.
NETCONF is the one that is not very clear because it says nothing
about NV-storage except for some very specific text about
the startup datastore.  If :startup is not supported, there is no
NV storage requirement at all.

In RESTCONF there is an NV storage requirement, which is compatible
with NETCONF.  RESTCONF does the edit procedure in 1 step.
This goes for candidate or startup.  Even if the server supports
:candidate, the client does not do a 2-step edit+commit like NETCONF.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Jun 2015 20:32:38 +0200 (CEST)

> The draft is clear -- the server saves to NV-store after every edit.

Right.  It says:

  Each RESTCONF edit of a datastore resource is saved to non-volatile
  storage in an implementation-specific matter by the server.

Shouldn't we just write:

  Each RESTCONF edit of a datastore resource is saved to non-volatile
  storage by the server.

*how* the server performs just about everything is implementation
 specific...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jun 2015 11:32:30 -0700

> *how* the server performs just about everything is implementation

OK

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 10 Jun 2015 12:23:18 -0700

> On Jun 9, 2015, at 11:48 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

+1

And I thought we had just got started on discussing the problem statement and possibly some solutions. It is too soon to declare it DEAD.

I think performance issues with writing to NV is prejudicing us into not finding a solution. Another way to ask the question is, if one was to take the performance issue of writing to NV taken out of the picture, would folks support the notion of having :distinct-startup in RESTCONF?

> /js

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jun 2015 13:08:33 -0700

>> for the (sometimes painful process) of finding rough consensus.

Note the text "IMO this issue should"...
I was stating my opinion, not declaring the issue dead.

OK

> I think performance issues with writing to NV is prejudicing us into not finding a solution. Another way to ask the question is, if one was to take the performance issue of writing to NV taken out…

The other use of user-controlled NV-store is that in case the device reboots,
it will come back with a known good configuration.  If every edit is NV-saved,
then there is no chance for the operator to test the changes before
changing the startup config.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jun 2015 22:09:00 +0200

> On 10 Jun 2015, at 16:36, Andy Bierman <[email-masked]> wrote:
> 

Yes, but how it is done is an “implementation-specific matter”. This may also mean it is a delayed write. I think the protocol specification shouldn’t be too specific here, it should suffice to say that it is expected the configuration won’t disappear with a device reboot.

These days, with all the virtualization options, cloud storage etc., it is hard to define what non-volatile storage is.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jun 2015 13:13:46 -0700

> These days, with all the virtualization options, cloud storage etc., it is hard to define what non-volatile storage is.

Maybe RESTCONF should not mention anything about NV-storage.
Or maybe the "nv-store" flag should be a hint, but the server can ignore it.

NETCONF has no NV-storage requirement at all and that has not
prevented servers from booting with the previous configuration.
The market can decide how fast is fast enough. The market can
decide that a configuration management system that only works
until the next reboot is not OK.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jun 2015 22:17:29 +0200

> On 10 Jun 2015, at 22:13, Andy Bierman <[email-masked]> wrote:
> 

I agree.

Lada

---

From: Kent Watsen <[email-masked]>
Date: Wed, 10 Jun 2015 22:35:22 +0000

>changing the startup config.

Both are important, but I think that this is the primary use case, with
performance being a close second.

Case in point, Junos CLI has auto-commit on by default (i.e. performance
isn't an issue), but offers what is called Manual Commit mode (service
manual-commit).  I'm trying to collect numbers, but I heard that it's
still widely used.

Thanks,
Kent

---

From: Rodney Cummings <[email-masked]>
Date: Thu, 11 Jun 2015 13:57:30 -0500

Personally, I really like the fact that RESTCONF specifies the NV storage 
requirement.

Some applications require NV storage as a baseline assumption. If we leave 
NV storage unspecified in RESTCONF, that brings the risk that different 
applications must specify their own NV requirements outside of RESTCONF. 
The market may pull this issue in different directions.

I tend to think of the RESTCONF section 3.4 as clear, in that it implies 
that the save to NV storage occurs prior to the response to PATCH. If some 
are concerned that this is not sufficiently clear, we could possibly 
change the text to state this explicitly.

If a given implementation does not want to save to NV storage on each 
edit, I would argue that NETCONF is the best alternative. I don't think we 
should add every feature from NETCONF into RESTCONF.

From:   Andy Bierman <[email-masked]>
To:     Ladislav Lhotka <[email-masked]>, 
Cc:     Netconf <[email-masked]>
Date:   06/10/2015 03:13 PM
Subject:        Re: [Netconf] YANG Patch Issue #3: :distinct-startup
Sent by:        "Netconf" <[email-masked]>

On Wed, Jun 10, 2015 at 1:09 PM, Ladislav Lhotka <[email-masked]> wrote:
> Yes, but how it is done is an “implementation-specific matter”. This may 
also mean it is a delayed write. I think the protocol specification 
shouldn’t be too specific here, it should suffice to say that it is 
expected the configuration won’t disappear with a device reboot.
>
> These days, with all the virtualization options, cloud storage etc., it 
is hard to define what non-volatile storage is.

Maybe RESTCONF should not mention anything about NV-storage.
Or maybe the "nv-store" flag should be a hint, but the server can ignore 
it.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 16 Jun 2015 23:36:04 +0000

Following up on this, it turns out that our NMS always persists its
updates to the server's NV store, and there are no customer requests to
provide a knob to control that behavior.   Even more surprising, JUNOS
does not even support the :distinct-startup (unlike JUNOSe and IOS).

Possible explanations include: 1) Junos commits are already long, such
that the persistence overhead isn't a big deal, 2) NETCONF clients
typically push a single large <edit-config>, unlike CLI interactions,
hence why operators are not concerned by persistence overhead, and 3) the
desire for operators to test changes before persisting to NVS isn't as
important as I had originally thought.

As there are no customer requests to change this behavior, I have to take
back my thinking a RESTCONF equivalent to the distinct-startup capability
is important feature.    It will be interesting to here from operators on
this, or even other vendors that have collected operator input.

Kent

On 6/10/15, 6:35 PM, "Kent Watsen" <[email-masked]> wrote:

>Case in point, Junos (update: I meant JUNOSe here) CLI has auto-commit on
>by default (i.e. performance

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Jun 2015 16:51:26 -0700

> this, or even other vendors that have collected operator input.
I suspect that REST developers that use ORM/SQL APIs expect the same
behavior
in RESTCONF -- editing an object is saved in SQL right away.
It isn't very REST-like to come back later a push the magic "save" button.
This could easily be added as a vendor extension if needed.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 20 Jun 2015 08:46:43 -0700

Hi,

There does not seem to be any consensus that this needs to
be added to RESTCONF.

Are there any objections to moving this issue status to 'DEAD',
which would mean the NETCONF :startup capability will not
be exposed in RESTCONF.

Andy