Subject: more fun with the operation attribute

From: Andy Bierman <[email-masked]>
Date: Fri, 26 May 2006 12:28:15 -0700

Hi,

The processing model (and sequence) within a netconf PDU is not
actually defined.  I believe our term for it is 'data-model specific'.
The problem is that our data modeling language(s) don't really
provide any help here.

Consider this PDU, where the <users> table is allowed to have one entry
per each value of the key (name).  In the target data model, the <users>
container exists, but is empty.

<rpc message-id="101">
<edit-config>
  ...
  <config>
    <users>
      <user operation="create">
        <name>fred</name>
        <type>admin</admin>
      </user>
      <user operation="create">
        <name>fred</name>
        <type>admin</admin>
      </user>
      <user operation="create">
        <name>fred</name>
        <type>guest</admin>
      </user>
      <user operation="merge">
        <name>fred</name>
        <type>admin</admin>
      </user>
      <user operation="replace">
        <name>fred</name>
        <type>staff</admin>
      </user>
    </users>
  </config>
</edit-config>
</rpc>

Remember that we have no "as-if-simultaneous" rules in netconf
like in snmp.  AFAIK, we don't have any rules that explicitly
permit or prohibit this.  Nor do we have any clue what the
standard result of the operation would be after this RPC,
if it did succeed.  That is also data-model specific.

Don't you love corner-cases?
So what should the proper standard response to this PDU be, if any?

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Phil Shafer <[email-masked]>
Date: Fri, 26 May 2006 17:20:47 -0400

>So what should the proper standard response to this PDU be, if any?

IMHO, create, merge, and replace should all succeed if the target
doesn't exist.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 May 2006 15:09:03 -0700

> IMHO, create, merge, and replace should all succeed if the target

Yes, but that is clear if the create, merge, of replace operation
is by itself and the target does not exist.

In this case, they are all part of one request.
The data modeling languages describe what a valid
datastore (PDU result) on the agent should look like.
In this case, it just says the key to the <user> 'table'
is the <name> child element.

A sequential CLI model would allow this PDU, (w/o
the cut-and-paste end-tag errors that is) and the
final result would be "last one wins". In this case,
that means the 'replace' node would be the one that
actually sets the user entry for 'fred'.

Are there use cases where a different result makes operational sense?
If not, can we try to standardize this behavior to
mean "last one wins" (when multiple valid operations for the same
data element are attempted).

Andy