Yang mandatory true not enforced


I’m using confd-basic 5.4 and using XML with netconf-console-tcp to test.

container ports {
list port {
key inputID;

    leaf inputID    { type uint32; }
    leaf outputID { type uint32; mandatory true;}


After I populate this list with say { (1,1) (2,2) (3,3) etc }, I’m surprised that I’m able to delete/remove a list entry by only specifying the key “inputID” - It seems the XML RPC was not rejected by ConfD for enforcing the structural constraint noted by the keyword “mandatory”.

Is this observation a bug or I’m not setting something in confd.conf?

<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
      <test xmlns="http://www.test.com/test/test-yang"
        <port nc:operation="remove">


For leaf elements of a list entry, the mandatory keyword requires the leaf to be in existence by specifying a value for it during a <edit-config> request. If you leave out the specification of a value for outputID during a <edit-config> request, you will get an error. However, you are free to remove the entire instance of a list even when one or more of the columns in the list instance are specified as mandatory. This is working as expected.

Hi Wai, well my XML request, as you see, is an edit-config without specifying “outputID” and I’m NOT getting any error!

I have missed the qualification in my statement to indicate that <edit-config> for a create operation, meaning my previous statement only applies when a list instance is being created. When a list instance is being removed or deleted with the <edit-config> request, only the key of the list instance needs to be specified.

Thanks Wai,

So any quick suggestion on how I can “require” that a non-key leaf of a list, is on the XML request to remove/delete an entry or somehow can I check for this non-key leaf to be present on a remove or delete operation and if not, I want to reject the request.

Hi Salman,

A simple solution could be that you make them both keys and then set inputID as “unique”. This way you ensure that inputID is always unique, and that outputID is always required/mandatory since it is needed to identify the list entry.

  container ports {
    list port {
      key "inputID outputID";
      unique "inputID";
      leaf inputID { type uint32; }
      leaf outputID { type uint32; }