Subject: Re: [Netconf] 4741bis - data stores

From: WashamFan <[email-masked]>
Date: Mon, 04 May 2009 10:36:01 +0800

> Hi,
>  
>  There has been some discussion whether different combinations of
>  capabilities are allowed or not.  A clarification could be that we
>  explicitly state that any combination is allowed unless otherwise
>  stated.
>  
>  One such combination is :confimed-commit and :startup.  The text on
>  :confimed-commit says:
>  
>     If the device reboots for any reason before the confirm timeout
>     expires, the server MUST restore the configuration to its state
>     before the confirmed commit was issued.
>  
>  But this seems to contradict the fact that the startup configuration
>  is used when the device boots.

I don't see the contradictory. If the device reboots unexpectedly in that
case, <startup>(even <running>) has not reflected the changes yet, and 
the server should be in the state before the confirmed commit was issued 
after <startup> has been loaded.

But the point is which datastore the configuration here refers to? candidate?

>  Proposal:
>  
>    Describe that the startup configuration is used also in this case.
>  
>    This means that if the client wants to make a config change
>    persistent when using the candidate and confirmed commit on a device
>    which also has startup, it needs to:
>  
>         commit confirmed
>         <verify the change>
>         commit
>         copy running to startup
>  
Yes, I think so. But what if there is an error or accident encontered when syncing
startup to running? what would it look like when it reboots in that case? (Maybe it
is another issue)

washam

>  Comments?
>  
>          
>  /martin
>  _______________________________________________
>  Netconf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 May 2009 09:35:11 +0200 (CEST)

Hi,

> But the point is which datastore the configuration here refers to? candidate?

It refers to 'running', which makes the contradiction.

If startup is not present, the confimred commit modifies running.  If
the box reboots before the confirming commit is given, running is
reverted to its state before the confirmed commit.

If startup is present, and the box reboots, running will be
initialized from startup, and it will (may) not be equal to what it
was before the confirmed commit.

/martin