Subject: [Netconf] Fw: [netmod] datastore persistence was Re: Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt>

From: t.petch <[email-masked]>
Date: Thu, 16 May 2013 13:53:40 +0100

FYI

This was triggered by the IETF Last Call on
draft-ietf-netmod-interfaces-cfg-10.txt
hence its appearance on the netmod list.

Not sure where the discussion should be. Sometimes the split between
Netconf and Netmod does not seem very technical.

Tom Petch

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: "t.petch" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 16, 2013 1:43 PM
Subject: Re: [netmod] datastore persistence was Re: Last Call:
<draft-ietf-netmod-interfaces-cfg-10.txt>

On May 16, 2013, at 2:18 PM, Juergen Schoenwaelder
<[email-masked]> wrote:

> On Thu, May 16, 2013 at 02:08:23PM +0200, Ladislav Lhotka wrote:
>>
>> On May 16, 2013, at 1:00 PM, t.petch <[email-masked]> wrote:
>>
>>> I see this as important to clarify but fear it will fade away only
to be
>>> resurrected some months later, not the first such occurrence on this
>>> list:-(
>>>
>>> I see Martin's position as very reasonable,
>>>
>>>> I would say:
>>>>
>>>> The startup datastore MUST be persistent.
>>>>
>>>> If startup is implemented, running MUST NOT be persistent.
>>>> If startup is not implemented, running MUST be persitent.
>>>>
>>>> The candidate datastore MUST be persitent.
>>>>
>>>> /martin
>>>
>>> just that it is not what the RFC say.  Rather, I see
>>>
>>> :running not writable
>>> not very interesting
>>>
>>> :running :writable-running
>>> edits can be made to :running [8.2.1]
>>> how the rest of it got there is undefined
>>> what happens when the device shuts down is undefined
>>>
>>> :startup :running :writable-running
>>> edits can be made to :running these will be lost on shutdown [8.7.1]
>>> the initial state of :running is taken from :startup [8.7.1]
>>> :startup cannot be edited but can be replaced by a copy from
>>> :running[8.7.1]
>>>
>>> :candidate :startup :running :writable-running
>>> edits can be made to :running these will be lost on shutdown [8.7.1]
>>> the initial state of :running is taken from :startup [8.7.1]
>>> :startup cannot be edited but can be replaced by a copy from
>>> :running[8.7.1]
>>> edits can be made to :candidate [8.3.5.1]
>>> :candidate can be committed to :running [8.3.4.1]
>>> :candidate can be copied to :startup [8.3.5.1]
>>> :startup can be copied to :candidate [8.7.5.1]
>>> :candidate persistence across shutdowns is undefined
>>>
>>> I believe that this should be resolved, agreed and documented, as it
>>> affects interoperability.
>>
>> I agree.
>>
>> Also, the idea of sharing some persistent data between NETCONF and
SNMP leads to the question whether the server is allowed to write to any
config datastore and, if yes, under what circumstances and rules. It
should certainly observe locks, but there can be other problems. For
instance, if the server modifies candidate on its own, it could happen
that a low-privileged client won't be able to perform a commit.
>>
>
> With 'server' you mean 'SNMP agent'? If so, I would assume that the

I mean general rules for changes in any configuration datastore that
take place outside a client's session.

> SNMP agent simply acts like any other NETCONF client. Implementations
> may use short-cuts as long as they lead to the same behaviour.

Sure, if this was the rule and no other changes were allowed, then it
would be fine. It could still expose the known problems with shared
candidate though.

>
> That said, I think this whole discussion belongs to the NETCONF
> working group more than the NETMOD working group.

Oh yes, I didn't notice it was in NETCONF.

Lada

>
> /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/>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 May 2013 15:11:04 +0200

> Netconf and Netmod does not seem very technical.

The persistence of NETCONF data stores is a NETCONF protocol issue and
not a YANG or a data model specific issue. Yes, the issue got raised
in the context of NETMOD but any clarification (if it is needed)
concerning NETCONF datastore persistens is related to the NETCONF
specification, hence I think this discussion technically belongs to
the NETCONF working group.

/js