whiteboard.txt

This represents the lifecycle of data within a device, and I've
drawn "====" boxes as "data" with "----" boxes as the operations
that are performed on that data to move it to the next step in the
lifecycle.  Hopefully that's clear.  Notes follow.

We wanted meaningless names for the phases, so we're using phonetic
alphabet names/codes.  For example, "zulu" and "yankee" are the last
two phases.

-------------------

+==[india]==+
|           |
+===========+
       \
      +--[juliette-delta]----------------------------
      | + NETCONF/RESTCONF operations (<edit-config>)
      | - (Syntactic validation) [2]
      | + System-defined data rewrites [13]
      +------------------------------
       /
+=[juliette]+
|           |
+===========+
       \
      +--[kilo-delta]----------------------------
      | "commit" operation [4]
      | - "best effort" option might result in removal of invalid config
      +------------------------------
       /
+==[kilo]===+
|           |
+===========+
       \
      +--[lima-delta]---------------------------
      | - remove inactive
      | + expand any template/group mechanism [3]
      | + add system-controlled implicit data
      +------------------------------
       /
+==[lima]===+
|           |
+===========+
       \
      +--[mike-delta]----------------------------
      | Semantic validation
      | + commit-time system-controlled data
      | - remove invalid data
      +------------------------------
       /
+==[mike]===+
| post validation [5] [6]
+===========+
       \
      +--[november-delta----------------
      | - remove data for missing hardware ("ephemeral interfaces" [7])
      +------------------------------
       /
+==[november]=+
| system adjusted [8]
+=============+
       \
      +--[oscar-delta]----------------------------
      | merge ephemeral database
      +------------------------------
       /
+==[oscar]==+
| [9]       |
+===========+
       \
      +--[papa-delta]----------------------------
      | add data learned from other sources (DHCP, RADIUS, 802.1x, etc)
      +------------------------------
       /
+==[papa]===+
| "complete instructions" [10]
+===========+
       \
      +--[yankee-delta]----------------------------
      | replace config=true nodes with "current" values  [11]
      +------------------------------
       /
+==[yankee]=+
|           |
+===========+
       \
      +--[zulu-delta]---------------------------
      | add config=false" nodes
      +------------------------------
       /
+==[zulu]===+
| aka "opstate"
+===========+


------------------------------------------------------------

Notes:

[1] [unused]

[2] Edit-config payloads are syntactically checked during processing.
Anything that fails validation is discarded.

[3] Such mechanisms are completely outside the spec of NETCONF, but we
in dealing with the "real world", we must admit their existence and
fit them into our world view.

[4] The commit operation may be either the <commit-config> operation
if #candidate is supported, or the implicit operation at the end of
each <edit-config> operation on the running datastore.

[5] Originally labeled "intended configuration", that term remains a
bit of a "Rorschach" term, but folks seem to stick with it regardless.

[6] The "post validation" datastore represents the product of a
successful validation, where any invalid configuration has been
removed.

[7] "ephemeral interfaces" is the term we've used for these sort of
"pre-provisioned" interface configurations in the past, thought this
term becomes overloaded with the introduction of "ephemeral
datastores".

[8] This was originally labeled "applied", but again, the "applied
configuration" term is a bit fuzzy, but seems too sticky to remove.
"system adjusted" has less fuzz, but also less curb appeal.

[9] There was no real consensus on the need to distinguish data gained
from the ephemeral database from that gained from mechanisms like
DHCP, etc.  But IMHO the fact that ephemeral databases are "our's" and
the rest are not means that we need to call them out specifically.

[10] New term meant to represent that outcome of all the mechanisms
that gives "instructions" to the device.

[11] This description, while accurate, is not completely clear.  As we
write all this up, it might be better to view this as a completely
distinct datastore rather than a set of operations performed on a
single stream of data.

[13] Data may be rewritten on input, for example converting any
plaintext password values into encrypted values, discarding the
original values.

----------------------

So we need to perform the following tasks:

(a) converge on a world view
(b) agree on terminology
(c) decide which data phases need to be externally visible
(d) create a mechanism to allow devices to describe which of those
    can be accessed on this particular device
(e) write it up