The remote procedure call concept is simply an abstraction of a request-reply mechanism in a client-server communication model. A client sends a request to a (remote) server, waits for a response and upon receiving it continues execution based on information received. That is it. This is essentially what happens when you invoke a NETCONF operation.
The specification you quoted:
The ONC RPC protocol is based on the remote procedure call model,
which is similar to the local procedure call model. In the local
case, the caller places arguments to a procedure in some well-
specified location (such as a register window). It then transfers
control to the procedure, and eventually regains control. At that
point, the results of the procedure are extracted from the well-
specified location, and the caller continues execution.
The remote procedure call model is similar. One thread of control
logically winds through two processes: the caller's process and a
server's process. The caller first sends a call message to the
server process and waits (blocks) for a reply message. The call
message includes the procedure's parameters, and the reply message
includes the procedure's results. Once the reply message is
received, the results of the procedure are extracted, and the
caller's execution is resumed.
and NETCONF specification say the same thing:
The NETCONF protocol uses a remote procedure call (RPC) paradigm. A
client encodes an RPC in XML [W3C.REC-xml-20001006] and sends it to a
server using a secure, connection-oriented session. The server
responds with a reply encoded in XML. The contents of both the
request and the response are fully described in XML DTDs or XML
schemas, or both, allowing both parties to recognize the syntax
constraints imposed on the exchange.
NETCONF uses an RPC-based communication paradigm. A client sends a
series of one or more RPC request messages, which cause the server to
respond with a corresponding series of RPC reply messages.
So does the Wikipedia page on RPC:
RPC is a kind of request–response protocol. An RPC is initiated by the client, which sends a request message to a known remote server to execute a specified procedure with supplied parameters. The remote server sends a response to the client, and the application continues its process. While the server is processing the call, the client is blocked (it waits until the server has finished processing before resuming execution), unless the client sends an asynchronous request to the server, such as an XHTTP call. There are many variations and subtleties in various implementations, resulting in a variety of different (incompatible) RPC protocols.
(better late than never, right?)