Subject: [netmod] Answers to "assigned-by system" questions

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

Andy Bierman writes:
>  - Do must statements apply to server-created leafs?

Yes.  leafs with the "assigned-by system" statement are
normal configuration data, so normal constraints apply.

>  - Do min-elements and max-elements constraints apply to
>    server created leafs?

Yes.  leafs with the "assigned-by system" statement are
normal configuration data, so normal constraints apply.

>  - Do unique statement constraints apply to server-created leafs?

Yes.  leafs with the "assigned-by system" statement are
normal configuration data, so normal constraints apply.

>  - Are leafrefs allowed to contain values that exist only
>    within a server-created leaf or leaf-list?

Yes.  leafs with the "assigned-by system" statement are
normal configuration data, so normal constraints apply.

I don't think we are talking about "a-by system" for
leaf-lists.

>  - Are instance-identifiers (where require-instance=true) allowed
>    to reference server-created leafs?

Yes.  leafs with the "assigned-by system" statement are
normal configuration data, so normal constraints apply.

>  - Do server-created leafs count as being a sibling node when deciding if
>    a mandatory leaf is missing?

I don't follow this question.

>  - How does a client know which case is selected (if any)
>    in an optional or mandatory choice, if only server-created
>    nodes exist?

Are you wanting "a-by system" nodes inside choices?  I
would think this would be disallowed.

>  - Does the nc:operation='create' fail if the client issues
>    such an edit-config operation on a server-created leaf?

Yes, since the leaf has a value.  Normal rules apply here.

>  - Does the nc:operation='delete' succeed if the client issues
>    such an edit-config operation on a server-created leaf?

Yes, the leaf will be deleted.  Normal rules apply here.

>  - Does an XPath expression (must/when/select) encounter a
>    missing-node or some value, if a server-created leaf is
>    referenced?

Yes.  leafs with the "assigned-by system" statement are
normal configuration data, so normal constraints apply.

>  - Does a subtree filter with a select-node or a content-match
>    node for a server-created leaf return any data, or not?

Yes.  leafs with the "assigned-by system" statement are normal
configuration data, so normal constraints apply.

IMHO the only real question for "assigned-by system" nodes is _when_
is the value assigned by the system?  Is it done at validation time
or at edit-config time?  In JUNOS, these are assigned at validation
time.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Aug 2009 11:04:33 -0700

Phil Shafer wrote:

There is no assigned-by system in YANG.
I don't think there is any consensus on the
details of this database property.

You are saying that of course all the leafs
count when validating a database -- we agree.

But the idea that an application will be
able to edit a NETCONF database without being
able to retrieve all the leafs that affect validation
is 'operationally-challenged'.

Forcing a human to look it up in YANG description and/or
vendor CLI documentation is not API-friendly, which is
a stated goal of the NETCONF protocol:

>From  4741-bis:

1.  Introduction

   The NETCONF protocol defines a simple mechanism through which a
   network device can be managed, configuration data information can be
   retrieved, and new configuration data can be uploaded and
   manipulated.  The protocol allows the device to expose a full, formal
   application programming interface (API).  Applications can use this
   straightforward API to send and receive full and partial
   configuration data sets.

>  Phil

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 26 Aug 2009 14:48:10 -0400

>details of this database property.

I thought that was part of the purpose of this discussion.

>is 'operationally-challenged'.

I disagree.

>a stated goal of the NETCONF protocol:

We make configuration data available via the API.  We do not mix
meta-data with data.  For example, we don't tell you which leafs
are mandatory, or have any of the constraints defined in YANG
(unique, key, etc).

I find it surprising that you want default values, which are less
interesting to the average client than mandatory or key, to be
intermixed with user-specific, vital and important configuration
data.

My code does't support exhibiting default values in the API at all.
No one has ever asked for them to be in the API.  I can' imagine
someone wanting to populate the configuration database with default
values.  Configuration files are too large and complex when they
contain the important parts.  Adding noise is, well, it's completely
outside my reality.

Trying to put this behaviour in NETCONF is IMHO a mistake.  If you
want to make "report-all" an optional feature that works this way,
we can leave it to the marketplace to decide the value.  But trying
to force the rest of the world to work this way is a non-starter.

Thanks,
 Phil