Symptom:
POST & PUT to certain top-level lists in a mounted device's model returns a 500 error via Restconf, although in some cases (device-dependent) the config appears to have committed. This problem first appeared in Boron-SR3, and continues in Carbon SR-1.

What's actually happening:
Two edit-config RPCs appear on the wire / in TRACE logs. The first edit-config's body includes a single empty parent node, such as <configuration> or <interfaces>, but then no actual contents within that. Different vendors' devices handle this in different ways, sometimes with a ~graceful rpc-error-reply on that incorrect edit-config but accepting the correct one that follows. Others enter a half-configured state and then fail the correct edit-config state (such as a POST where the resource was created without useful payload).

Solution: If the target is a mounted network element, don't create the empty subtree at all. Regardless of whether or not the standard allows it, most vendor netconf implementations reject this behavior. See MakePut in BrokerFacade for the root cause, and also see corresponding post method..

One example of the failure:
2017-10-05 16:26:40,416 | WARN | oupCloseable-3-2 | NetconfDeviceCommunicator | 299 - org.opendaylight.netconf.sal-netconf-connector - 1.5.1.Carbon | RemoteDevice

: Error reply from remote device, request: <rpc message-id="m-7538" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config>
<configuration xmlns="http://yang.juniper.net/junos/conf/root"/>
</config>
</edit-config>
</rpc>
, response: <nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/17.4X48/junos" message-id="m-7538">
<nc:rpc-error>
<nc:error-type>protocol</nc:error-type>
<nc:error-tag>operation-failed</nc:error-tag>
<nc:error-severity>error</nc:error-severity>
<nc:error-message>syntax error, expecting <configuration></nc:error-message>
<nc:error-info>
<nc:bad-element>configuration</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
</nc:rpc-reply>