When the router responds with error path to RPC request, it shows a CLI configuration path instead of a valid element path.
For example, the following NETCONF RPC request:
<rpc message-id="m-2" 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">
<interfaces xmlns="http://yang.juniper.net/junos/conf/interfaces">
<interface>
<name>et-0/0/0</name>
<unit>
<name>20</name>
<family>
<inet>
<filter>
<input-chain xmlns:op="urn:ietf:params:xml:ns:netconf:base:1.0" op:operation="remove">filter1</input-chain>
</filter>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>
</config>
</edit-config>
</rpc>
The device responds with the following error:
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/21.2R0/junos" message-id="m-2">
<nc:rpc-error>
<nc:error-type>application</nc:error-type>
<nc:error-tag>data-missing</nc:error-tag>
<nc:error-severity>error</nc:error-severity>
<nc:error-path>[edit interfaces et-0/0/0 unit 20 family inet filter]</nc:error-path> <<<<<<
<nc:error-message>statement not found: input-chain filter1</nc:error-message>
</nc:rpc-error>
</nc:rpc-reply>
This seems to show a CLI configuration path but not a valid element path.
RFC 6241 Section 4.3 <rpc-error> Element
error-path: Contains the absolute XPath [W3C.REC-xpath-19991116]
expression identifying the element path to the node that is
associated with the error being reported in a particular
<rpc-error> element. This element will not be present if no
appropriate payload element or datastore node can be associated
with a particular error condition.
Engineering suggested this is a feature enhancement effort, and will add the enhancement in 24.4R1 release.