Subject: [NGO] max-access summary points

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Dec 2006 08:35:15 -0800

Hi,

This is not WG consensus or anything official, but if it was,
I think this is where we ended up:

  max-access summary points:

    - semantics: The maximum possible access that makes 'protocol sense'.

    - conceptual model: list of individual access privileges; if the
      name of the access enumeration is present in the list, then
      access is granted.

    - syntax: Empty element encoding for each access privilege enumeration.
      If a sequence is used, then the order is fixed.  If a 
substitutionGroup
      is used, then the order is not fixed, and neither is the value set.

    - enumeration value set: 'read', 'write'  (consensus not that clear,
      and this may not even work.  Agent-created containers may need
      some more consideration.)

I suspect that the group is split about 50-50 wrt/ abandoning the SMIv2 
max-access
and creating a new one.  There is significant support for not having this
clause at all, especially if the only values are 'read' and 'write'.
The practical application of this clause might be minimal at best.

It may be better to simply define an <appinfo> convention to indicate
the boolean classification: 'config' or 'state'.

Andy

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Dec 2006 20:57:58 +0100

> the boolean classification: 'config' or 'state'.

The IP address assigned to an interface might be config or state. The
distinction is made at runtime and not at model design time.

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Dec 2006 13:29:45 -0800

> distinction is made at runtime and not at model design time.

Or you could look at this corner-case as 'agent supplied config'.
It isn't 'state' just because the agent does not let the value
be written.  It is 'state' data if nobody could ever 'configure' it,
including the agent.  Conceptually, a counter or ifOperStatus is
never configured. (Initialized and incremented/updated are different.)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Dec 2006 22:46:24 +0100

> never configured. (Initialized and incremented/updated are different.)

RFC 4741 says:

   The information that can be retrieved from a running system is
   separated into two classes, configuration data and state data.
   Configuration data is the set of writable data that is required to
   transform a system from its initial default state into its current
   state.  State data is the additional data on a system that is not
   configuration data such as read-only status information and collected
   statistics.

I am not really shure how to interpret this text. 

Does <get-config> return forwarding table entries that were learned
via routing protocols or other mechanisms?

- If yes, is it assumed that data models provide additional
  information to distinguish between "configured" and "learned"
  forwarding table entries?

- If yes, if I have an interface configured via DHCP and I do an
  <edit-config> to change the IP address, is it expected that
  implementations properly return the lease to the DHCP server as a
  side effect of this change?

Do operators really want a <get-config> that returns everything that
can potentially be written or just what they actually have configured
on the device?

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Dec 2006 16:11:13 -0800

>   side effect of this change?

No -- learned entries are not config.
The switch that says "use learned entries" is config.
There is a big difference.

> can potentially be written or just what they actually have configured

Usually both.
Default suppression is fine unless the default is not
exactly the same across all implementations or versions.
Then leaving out a default value is a silent config change.
Maybe the new value is appropriate, maybe not.  IMO,
this is one of the fragile aspects of CLI that needs to be
replaced with a programmatic interface.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Dec 2006 09:28:12 -0800

> I am not really shure how to interpret this text. 

This text is almost correct.
It turns out that there is a practical definition of config data
that covers everything, including corner-cases like read-only
config data (e.g., persistent ifIndex values) and containers.

If it is saved in the non-volatile configuration datastore,
then it is config data.

I know this is a circular definition.
That's why the data model designer has to make it clear
in the schema if a read-only data object is meant to be
stored in the NV configuration.  (Back to the appinfo 'config' flag).

>   side effect of this change?

No - the config data controls how learning is done.
The data that has been learned since the last reboot is not config.

> can potentially be written or just what they actually have configured

Both perhaps?
It would be prudent to archive a full config before a SW update,
and compare it with another full config after the update, to see if
any defaults changed which would otherwise go undetected.

However, we have no standard parameter to return the config
without defaults, which is the 'everyday' mode.
How about a simple fix for now, which does not require any edits
to the standard?

    <rpc message-id="101" with-defaults="false">
      <get-config>
        ...
      </get-config>
    </rpc>

    <attribute name="with-defaults" type="boolean"/>

Andy