Subject: [netmod] server supplied leafs and protocol operations

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Aug 2009 08:25:39 -0700

Hi,

Juergen said these server-supplied leafs, which the
server is allowed to choose if they exist or not,
have no affect on the protocol.  IMO they have a
negative impact on the protocol, if the client is
unaware of these phantom leafs.

  list A {
    key x;
    unique y;

    leaf x { type string; }
    leaf y { type int32; }
  }

If either the client or the server creates /A,
it will be visible because /A/x is a key and must
be present.

But the server may create as many instances as it wants
of /A/y and /A/z.  Not every list entry need have the
same server-created leafs or values.  If these server-created
leafs are hidden from the client, then what happens?

Start with 2 list entries:

  <A>
    <x>first</a>
    //  hidden server value <y>19</x>
  </A>
  <A>
    <x>second</a>
    //  hidden server value <y>21</x>
  </A>

What happens if the client decides to merge in a value for /A/y?

  <edit-config>
    ...
    <config>
       <A>
         <x>first</x>
         <y>21</y>
       </A>
    </config>
  </edit-config>

Q) Do we agree that the server MUST send a data-not-unique error
   because y=21 in the 2nd list entry, so y=21 in the first entry
   is rejected?

 * If no, then hiding server-created /A/y has a definite impact on
   the protocol.  Is the server forced to change the y=21 in
   the 2nd list entry to another value, or does the unique-stmt
   violation get ignored?

 * If yes, then it proves these phantom leafs really do exist, and hiding
   them only makes it harder for a client to use NETCONF/YANG.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 26 Aug 2009 12:52:38 -0400

>unaware of these phantom leafs.

I think you have a misunderstanding about "assigned-by system"
leafs.  When a parent hierarchy is created without the leaf, the
system assigns a value to that leaf.  At that point, the leaf becomes
part of the configuration database.  Such a leaf is not "hidden
from the client".  The value is fetch with normal NETCONF operations.

Only the creation of the leaf has any amount of mystery to it.
Other than that, it is normal configuration data.   Most importantly,
if the client includes a value for the leaf in an operation that
creates the parent hierarchy, the system does not assign its own
value, but honors the one given by the client.  If the client assigns
a value for the leaf in an operation that affects an existing
instance of the parent hierarchy, the server will use the new value
given, replacing the previous value, whether it was assigned by the
system or a previous client.

In other words, it behaves exactly like other configuration data.

>What happens if the client decides to merge in a value for /A/y?

This would be an error, since it violates the uniqueness constraint.

>   them only makes it harder for a client to use NETCONF/YANG.

There are no phantom leafs and no one is hiding them.  There's
nothing in Area 51 either.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Aug 2009 10:31:03 -0700

> nothing in Area 51 either.

I don't believe either.
There are pictures of a massive complex at Groom Lake, but we digress...

If what you say is true, then what exactly is basic=explicit behavior
for handling defaults?

The :with-defaults capability is optional-to-implement.
We can't make it mandatory without changing the protocol version,
or all existing 4741 implementations will be non-compliant.

Unless the server supports :with-defaults, and it refuses to ever show the
client any leaf that was set by the server (the definition
of basic=explicit), then these are effectively hidden leafs.
The client has to edit the database without knowing if any
conflicts are being created with these hidden leafs.

So you are saying that we don't have any server behavior (ever)
that would prevent a leaf set by the server to a value other
than the YANG default from being retrieved by the client?

If that is the case, then we don't need 'explicit' in the
with-defaults draft.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 26 Aug 2009 13:46:03 -0400

>of basic=explicit), then these are effectively hidden leafs.

The definition of "basic=explicit" in the w-d draft needs repaired.

   o  Explicitly set default data: Data that is explicitly set by the
      NETCONF client to its default value.  Some servers MAY treat
      explicitly set default data as simple default data, as they may
      not be able to differentiate between them.

Your current definition is way too narrow, blocking SNMP, humans,
etc.  I suggest "Data that is explicitly set to its default value."

Leafs that are "a-by system" and are assigned values by the value
are normal configuration data.  They should always be included in
the data returned by get-config without regard for with-defaults.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Aug 2009 21:51:35 +0200 (CEST)

> or all existing 4741 implementations will be non-compliant.

But if we decide e.g. that we want to support dynamic defaults, and
:with-defaults is the way to read the value, we could require
:with-defaults for servers that implement any YANG module.

> than the YANG default from being retrieved by the client?

Is this the same as dynamic defaults?

> If that is the case, then we don't need 'explicit' in the

If we make dynamic defaults illegal we don't need :with-defaults at
all, except for convenience.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Aug 2009 21:57:33 +0200 (CEST)

> etc.  I suggest "Data that is explicitly set to its default value."

While I agree with the suggested change, note that the term 'explicit'
has nothing to do with the term 'explicitly set default data'.  A
server that cares about 'explicitly set default data' implements the
basic mode 'trim'.  This is confusing, and should probably be fixed.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 26 Aug 2009 16:06:53 -0400

>basic mode 'trim'.  This is confusing, and should probably be fixed.

"trim" means that if I set a leaf to the default value, it
disappears, since the server will not report it.

"explicit" means that if a user explicitly set it, it will
be reported even if the value is equal to the default value.

So I disagree that "the term 'explicit' has nothing to do with the
term 'explicitly set default data'", since my behavior is to save
configuration data that is explicitly set, regardless of value.

I'm appended some examples below.

Obviously I'm a fan of the "explicit" model, since that's how
my code works, but I don't believe in forcing this model on the
rest of the world, especially since I believe that will harm the
ability of major vendors to adopt NETCONF.  We should be able to
express what the device is able to do and allow clients to deal
with the differences.

It's not a "one ring to rule them all" approach, but I believe it
is valid, useful, and will help our work to be adopted and used by
the largest number of devices.

Thanks,
 Phil

-----

In this example, the value for "multiplier" is set to the default (3)
and it remains part of the configuration:

        [edit protocols bgp]
        phil@dent# show bfd-liveness-detection multiplier | display detail 
        ##
        ## bfd-liveness-detection: Bidirectional Forwarding Detection (BFD) options
        ##
        ## multiplier: Detection time multiplier
        ## range: 1 .. 255
        ## default: 3
        ##
        multiplier 5;
        
        [edit protocols bgp]
        phil@dent# set bfd-liveness-detection multiplier 3 
        
        [edit protocols bgp]
        phil@dent# show bfd-liveness-detection                    
        minimum-interval 100;
        multiplier 3;
        
        [edit protocols bgp]
        phil@dent# show bfd-liveness-detection multiplier | display detail 
        ##
        ## bfd-liveness-detection: Bidirectional Forwarding Detection (BFD) options
        ## multiplier: Detection time multiplier
        ## range: 1 .. 255
        ## default: 3
        ##
        multiplier 3;
        
        [edit protocols bgp]
        phil@dent# 

But other network vendors don't work this way.  In this example,
the "no exec" statement disappears when I set "exec" (the default)
and the "width" statement appears and disappears when it is or isn't
set to 80 (the default):
    
    terminal-server#show conf 
    Using 1294 out of 32762 bytes
    !
    version 11.3
    ...
    line 16
     no exec
     timeout login response 0
     transport input telnet
    ...
    !
    end
    
    terminal-server#conf t 
    Enter configuration commands, one per line.  End with CNTL/Z.
    terminal-server(config)#line 16
    terminal-server(config-line)#exec
    terminal-server(config-line)#width 80
    terminal-server(config-line)#^Z
    terminal-server#show running-config 
    Building configuration...
    
    Current configuration:
    !
    version 11.3
    ...
    line 16
     timeout login response 0
     transport input telnet
    ...
    !
    end
    
    terminal-server#conf t              
    Enter configuration commands, one per line.  End with CNTL/Z.
    terminal-server(config)#line 16
    terminal-server(config-line)#width 75
    terminal-server(config-line)#^Z
    terminal-server#show running-config 
    Building configuration...
    
    Current configuration:
    !
    version 11.3
    ...
    line 16
     timeout login response 0
     width 75
     transport input telnet
    ...
    !
    end
    
    terminal-server#conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    terminal-server(config)#line 16
    terminal-server(config-line)#width 80
    terminal-server(config-line)#^Z
    terminal-server#show running-config 
    Building configuration...
    
    Current configuration:
    !
    version 11.3
    ...
    line 16
     timeout login response 0
     transport input telnet
    ...
    !
    end
    
    terminal-server#

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Aug 2009 23:38:55 +0200 (CEST)

> configuration data that is explicitly set, regardless of value.

We agree here; what I meant was that if your mode is 'explicit', you
treat any data set by the client the same way - you probably don't
even check if it matches the default or not.  So you don't care if it
happens to match the term "explicitly set default data".  But if your
mode is 'trim', you have to care.

> express what the device is able to do and allow clients to deal

Agreed, and I still think that's what we're doing with the "default"
statement in YANG and :with-defaults capability.  

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 26 Aug 2009 20:40:36 -0400

>mode is 'trim', you have to care.

Ah, cool.  We are in complete agreement.

Thanks,
 Phil