Re: [YANG] mandatory & default

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>>> Or, if you, for a moment, try to view thing from the other side, you
>>> need an extension with-defaults=true to actually get the default
>>> values, since they are not stored in the configuration data store.
>>>
>> I disagree.
>>
>> If I invoke an <edit-config> and set the leaf to this
>> default value, it is still not there?
> 
> Yes it's there.
> 
>> If I invoke an <edit-config> and set the leaf to a
>> non-default value, it is clearly there.
> 
> Yes it's there.
> 

Therefore this approach is broken.

   container interfaces {
     list interface {
       key name;

       leaf name { type InterfaceName; }

       leaf mtu {
         type uint32;
         default 1500;
       }
     }
   }

I start out with a get-config, and mtu is not there:

  <interfaces>
    <interface>
      <name>eth0</name>
      <mtu>1600</mtu>
    </interface>
    <interface>
      <name>eth1</name>
    </interface>
  </interfaces>

Does /interfaces/interface[name=eth1]/mtu exist or not?

If not, then I can do an edit-config to create it:

   <config>
     <interfaces>
       <interface>
         <name>eth1</eth1>
         <mtu nc:operation='create'>1500</mtu>
       </interface>
     </interfaces>
   </config>

Does this succeed?  NETCONF says it should, because the
leaf did not get returned in the previous <get-config>.

Now I do a get-config again and get back:

  <interfaces>
    <interface>
      <name>eth0</name>
      <mtu>1600</mtu>
    </interface>
    <interface>
      <name>eth1</name>
      <mtu>1500</mtu>
    </interface>
  </interfaces>

The leaf never really changed value, but you would never know
that from the NETCONF PDU responses.

After a system reboot, does the agent 'remember' that mtu
was set to 1500 by the manager, so the initial <running/>
config from NV-storage after the next reboot has an mtu leaf
for eth1?

Andy

>> Whether the manager or the agent sets the leaf to the default,
>> it is there from a NETCONF protocol PoV.
> 
> The crucial point is that - in this way of seeing things - the agent
> does not set the leaf to the default.  Again, I do understand that
> there are other ways to define how defaults work.  I'm just trying to
> explain the rationale for this one.
> 
> 
>>>> Phil seems to be arguing that nodes that contain the agent-specified
>>>> default value are not really there.
>>> Right, since they are not there in his implementation.  Why would you
>>> store stuff that's not even needed to store?  That's just a waste of
>>> resources.
>>
>> Nobody said anything about storing the value.
> 
> I just tried to explain why "nodes that contain the agent-specified
> default value are not really there". 
> 
>> It is an implementation-specific matter as to how
>> an agent generates a reply to a <get-config> request.
>> The defaults do not have to be stored -- they can
>> be generated on the fly.
> 
> Agreed.
> 
> 
> /martin
> 
> 

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang