One question about the must check

NETCONF
1

Hi,
I have one question about the must check, use the below example:

  1. The three YANG files
# cat root.yang 
module root {
    namespace
        "http://nokia.com/nokia-tas/root";
    prefix root;
    container root {
          container child1;
   }
}

# cat default.yang 
module default{
  namespace "http://complex/default";
  prefix "default";
  import root {prefix "root";}

  augment /root:root/root:child1 {
  container default {
     list test1{
        key id1;
        leaf id1{
          type uint8 {
              range "1..80";
          }
        }
     }
   }
 }
}

# cat check.yang 
module check{
  namespace "http://complex/check";
  prefix "check";
  import root {prefix "root";}
  import default {prefix "default";}

 augment /root:root/root:child1 {
  container test3 {
     must "(../default:default/default:test1/default:id1=1)"{error-message "/default/test1/id1 should be 1.";}
     list test4{
        key id;
        leaf id{
          type uint8 {
            range "1..80";
          }
        }
      }
    }
  }
}
  1. The XML is:
# cat check.xml 
<root xmlns="http://nokia.com/nokia-tas/root">
<child1>
  <default xmlns="http://complex/default">
   <test1>
    <id1>3</id1>
   </test1>
  </default>
</child1>
</root>

3, My question is:
The check.xml only focus on the default.yang, but the check.yang has the must check about the default module. so when edit-config the check.xml, whether the must check in check.yang should be triggered?

2

On one hand - yes, with the RFC as it is written, I think it says that the must expression should be validated.

On the other hand - when you read the passages about augmenting modules, quite some care is dedicated to that clients that do not know about the augmenting module do not break. You are violating this principle here: a configuration that is valid without the augmenting module suddenly becomes invalid just by adding that new module. I’m not sure what confd should do about this in an ideal world - maybe it should outright refuse such module, maybe it should ignore the must statement; but in any case you, as the author of the augmenting module, are responsible for this violation.

3

Hi @mvf,
Thanks very much for the response.

  1. You mean the RFC has written? Could you help to point out the chapter as I didn’t find it, thanks.

You are violating this principle here: a configuration that is valid without the augmenting module suddenly becomes invalid just by adding that new module.

You mean the YANG module I defined isn’t valid which violate the above rule.

If I changed the above check.yang must check into the below format, the must check are both related with the default.yang and check.yang, whether the check.yang is valid?

# cat check.yang 
module check{
  namespace "http://complex/presence";
  prefix "presence";
  import root {prefix "root";}
  import default {prefix "default";}

augment /root:root/root:child1 {
  container test3 {
     must "not(../default:default/default:test1[not(default:id1=current()/test4/id) or not(default:id=current()/test4/body-id)])"{
        error-message "The container test3 must be existed.";
        }
     list test4{
        key id;
        leaf id{
            type uint8 {
                        range "1..80";
                    }
        }
        leaf body-id {
                type uint8 {
                        range "1..80";
                    }
        }
       }
     }
  }
}
4

Read the YANG RFC, the chapter dedicated to the augment statement - I believe the message is clear: the client using your server should be able to use it with or without the augmenting module check.

When you add the module check to your system, you are changing (in particular, restricting) the set of valid configurations even for clients that are not aware of the new namespace. This is the violation I had in mind. The same principle, i.e. that your change should not make a valid configuration invalid, is supposed to be used also when you update an existing (published) module.

5

Hi @mvf,
Thanks very much for the response.
I got it.