Subject: [netmod] defaults

From: Phil Shafer <[email-masked]>
Date: Wed, 10 Mar 2010 14:15:32 -0500

Not that I want to touch the "third rail" of YANG, but...

The YANG draft says:

   A NETCONF server that replies to a <get> or <get-config> request MAY
   choose not to send the leaf element if its value is the default
   value.  Thus, a client that receives an <rpc-reply> for a <get> or
   <get-config> request, MUST be prepared to handle the case that a leaf
   node with a default value is not present in the XML.  In this case,
   the value used by the server is known to be the default value.

Do we expect new RPCs to have this same behavior WRT defaults?  I
would expect this is what we want.

So should we s/ <get> or <get-config>//?

This should also be the behavior for notifications.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Mar 2010 20:40:53 +0100 (CET)

> This should also be the behavior for notifications.

It also says, in the text on notification (same for rpc output):

  If a leaf in the notification tree has a default value, the NETCONF
  client MUST use this value in the same cases as described in
  ^leaf-default-value^.  In these cases, the client MUST operationally
  behave as if the leaf was present in the NETCONF notification with
  the default value as its value.

So I think it is covered.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 10 Mar 2010 14:50:12 -0500

>So I think it is covered.

Okay, but if the rules are relaxed elsewhere, why make the rule
so specific in the first place?  Would you object to having the
real rule more fully described in ^leaf-default-value^?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Mar 2010 13:00:12 -0800

> real rule more fully described in ^leaf-default-value^?

I changed the with-defaults draft to align with YANG.
Please check the latest draft to see if I got it right.

Are you suggesting that the defaults behavior of the server
MAY affect other RPC operations?  And we do not want
to spin the YANG RFC later if we decide defaultst apply to more
than the 3 specific operations mentioned?

I think the with-defaults draft should say how specific
NETCONF operations deal with defaults.  The YANG draft should
be more future-proof.  (Sometimes just the addition of 'e.g.,'
can be the difference.

<another-issue>

I don't think Lada ever got a clear answer to his original question
about the nc:operation='create' or 'delete' for a default leaf.
This needs to be the same on every server, no matter what
notion of defaults the server uses.

  1) Does a create operation on a YANG default leaf succeed or fail
     with a 'data-exists' error?
  2) Does a delete operation succeed (and then the server creates the
     leaf again) or does it fail with a 'data-missing' error?
  3) Is the 'explicit' notion of a default affect the create/delete
     operations at all?

</another-issue>

>  Phil

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 10 Mar 2010 17:07:46 -0500

Andy Bierman writes:
>MAY affect other RPC operations?

Yes, it affect rpc input, output, and notifications.

>NETCONF operations deal with defaults.

with-defaults is not the place to address this, since it's
optional.

>     with a 'data-exists' error?

succeed; otherwise success must be defined as (not(error) || error/tag == 'data-exists')

>     leaf again) or does it fail with a 'data-missing' error?

fail; otherwise similar issue (where success is not trivial to discover)

>  3) Is the 'explicit' notion of a default affect the create/delete

yes.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Mar 2010 08:10:36 +0100

> be more future-proof.  (Sometimes just the addition of 'e.g.,'

I like the e.g. solution, that is mention <get> and <get-config> as
examples to future proof this definition.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Mar 2010 00:13:20 -0800

>>  3) Is the 'explicit' notion of a default affect the create/delete

This is why the client needs to know how the server treats defaults.
This is why implementing with0defaults is a SHOULD, not an optional MAY.

  leaf foo {
     type int32;
     default 42;
  }

  <rpc>
    <get-config .../>
  </rpc>

  <rpc-reply>
    <data>
     <foo>42</foo>
    </data>
  </rpc-reply>

Is the server returning 'report-all' or 'explicit'?  Yes.
Will a create operation succeed or not?  Who knows?

The client has no idea.  If another client set
the value to '42', then the create will fail,
but if the server set it to '42', then it will succeed.
Weak.

Andy