Subject: [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)

From: Andy Bierman <[email-masked]>
Date: Wed, 28 May 2014 09:12:28 -0700

Hi Tom,

On Wed, May 28, 2014 at 2:30 AM, t.petch <[email-masked]> wrote:

> ----- Original Message -----
> From: "Hirochika Asai" <[email-masked]>
> To: "joel jaeggli" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, May 28, 2014 12:57 AM
>
> > Dear Joel and Benoit,
> >
> > Since Joel has invited Benoit, another AD of OPS AREA, to this
> discussion,
> > I summarize my question for clarity as follows:
> >
> > The IESG statement (*1) encourages to remove read-write access to
> objects
> > related to configuration from MIB modules.  However, the scope of the
> > nomenclature "configuration" is not clear to me.  In my understanding,
> > "configuration" does not contain non-persistent (volatile) changes to
> objects,
> > such as virtual machine administrative state (vmAdminState) in our I-D
> (*2).
> > They does not affect the configuration but changes state of the target
> system.
> > Therefore, I think they are not under "SNMP MIB modules creating and
> > modifying configuration state" stated in the IESG statement.
> >
> > Is my understanding correct or not?
>
> Note that the statement refers to NETCONF/YANG which has introduced a
> new definition of configuration, namely
>
> "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."
>
> Other references make it clearer that configuration is what you might
> put in through a CLI to get a box off the ground, while anything learnt
> later via a protocol, such as BGP, NTP, DHCP, is (operational) state
> (and read-only in NETCONF but not so limited in SNMP).  Persistence is
> orthogonal, and ill-defined, in NETCONF/YANG.  If you key it in via CLI,
> or do the equivalent via something other than Telnet, then it is
> configuration, even if it is discarded at reboot; NETCONF optionally
> allows for persistent and non-persistent configuration.  SNMP has never
> said much about persistence (table row status being the exception).
>
>

I don't agree NETCONF/YANG persistence is ill-defined.
It is not uniform. There are a few variants, identified by
capability URIs.

The XMLCONF design team (pre-4741) tried very hard to
get the router vendors to agree on a single transaction model
but it was way too big a change, and (of course) each vendor
thought their way was better, so the standard should use that.
We ended up with 3 configuration datastores (candidate, running, startup).
The transaction models that can be used with these datastores
are compatible with specific router CLI architectures.

Two particular vendors do not agree on how to recover
from the "unreachable" problem.  If the operator makes
config changes that break the connectivity to the device,
then the device has to recover somehow.

  M1: do not persist the changes until they are proven to
        be correct.  Force the device to reboot with the saved
        (known good) config if things go bad.

  M2: persist the changes right away.  Pick some timeout
        and if the client does not follow up with a confirmation
        before the timeout, automatically revert to the version
        that was running before the transaction started.

RFC 6241 could be more clear on the motivation for the
capabilities and operations that support various transaction models.
Maybe that is what you meant by 'ill-defined'.

Andy

So the two objects controlling Notifications seem clearly configuration,
> whether or not the setting of them persists or is lost on reboot.  You
> could create a YANG module which controls the setting of these two
> objects for SNMP usage but I think that even the IESG might see that
> that is an unusual approach, as opposed to making them read-write in
> SMI!
>
> When I first read the draft IESG statement, it was unclear to me whether
> or not the authors fully understood what they had written.
>
> Tom Petch
>
> > (*1) http://www.ietf.org/iesg/statement/writable-mib-module.html
> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> >
> > Hirochika
> >
> >
> > On May 27, 2014, at 3:55 AM, joel jaeggli <[email-masked]> wrote:
> >
> > > yeah if you want to discuss it with the ops/management ADs and the
> > > chairs that's fine.
> > >
> > > I don't think there's a reason to involve the whole iesg.
> > >
> > > Thanks
> > > joel
> > >
> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> > >> js and Joel,
> > >>
> > >> Thank you for your comments.
> > >>
> > >> I agree that the IESG statement seems to be talking about
> configuration,
> > >> but I cannot definitely say that the objects I listed in my
> previous E-mail
> > >> are out of the IESG statement's scope.
> > >>
> > >> I think it would be better to move this issue to the IESG, but I
> don't keep
> > >> up the procedure.  May I, as an author of the draft, send an E-mail
> > >> stating this issue to [email-masked], CCing WG? Or ask WG chairs to
> > >> handle it?
> > >>
> > >> Thank you.
> > >> Hirochika
> > >>
> > >>
> > >> On May 27, 2014, at 1:24 AM, joel jaeggli <[email-masked]> wrote:
> > >>
> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli wrote:
> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> > >>>>>> Asai,
> > >>>>>>
> > >>>>>> the IESG statement is here:
> > >>>>>>
> > >>>>>> http://www.ietf.org/iesg/statement/writable-mib-module.html
> > >>>>>>
> > >>>>>> My reading is that it specifically talks about configuration.
> While
> > >>>>>> the discussion started with "lets ban all write access", it may
> be
> > >>>>>> important to note that the final statement does not say this.
> Hence,
> > >>>>>> I am not sure we have to remove the MAX-ACCESS read-write.
> > >>>>>
> > >>>>> some of the vm options do cause me existential peril. The
> remaining
> > >>>>> one's however do not. so I think Juergen's assessment  is a
> correct one.
> > >>>>> The statement seems to be serving it's purpose!
> >>>>
> > >>>> Joel, can you please decrypt your message so that it becomes
> perhaps
> > >>>> actionable?
> > >>>
> > >>> I'm agreeing with you.
> > >>>
> > >>>> /js
> > --
> > Hirochika Asai <[email-masked]>, The University of Tokyo
> >
> > _______________________________________________
> > OPSAWG mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/opsawg
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>