Re: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)

[Juergen Schoenwaelder <[e-mail]>]

RFC 8342 says:

   However,
   <running> MUST always be a valid configuration data tree, as defined
   in Section 8.1 of [RFC7950].

   <intended> is tightly coupled to <running>.  Whenever data is written
   to <running>, the server MUST also immediately update and validate
   <intended>.

   <intended> MAY also be updated independently of <running> if the
   effect of a configuration transformation changes, but <intended> MUST
   always be a valid configuration data tree, as defined in Section 8.1
   of [RFC7950].

   For simple implementations, <running> and <intended> are identical.

/js

On Wed, Nov 07, 2018 at 03:37:57PM +0000, Qin Wu wrote:
> 发件人: netmod [mailto:[e-mail]] 代表 Sterne, Jason (Nokia - CA/Ottawa)
> 发送时间: 2018年11月6日 10:56
> 收件人: [e-mail]
> 主题: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)
> 
> Hello,
> 
> The draft mentions that "It is possible that some configuration could not be applied to <operational> due to either validation issues, or missing resource etc."
> 
> But wouldn't validation errors cause an error response to the commit RPC? I'm not clear why there would be validation later in the commit/apply process that wasn't part of the decision to reply OK/NOK to the commit.
> 
> 
> [Qin]:The configuration is written into running via commit operation, but commit operation doesn’t equal to validate operation. Validate operation is defined in RFC6241 to validate, e.g., candidate datastore or the <config> element containing the complete configuration in the edit config. But RFC6241 doesn’t discuss how validate operation can be applied to intended or other NMDA datastore since NMDA is introduced after RFC6241 gets published.
> 
> 
> 
> As described in RFC8342 and figure 2 of RFC8342
> 
> “Whenever data is written
> 
>    to <running>, the server MUST also immediately update and validate
> 
>    <intended>.
> 
> “
> 
> So validate <intended> takes place after commit operation. It involves in configuration transformations to <running> before intended validation operation.
> 
> The draft also implies that the process of moving config from running -> intended -> operational is decoupled from the application of a candidate -> running.
> - Do systems reply OK/NOK to a commit before config is moved from running->intended->operational ?
> [Qin]: reply OK/NOK indicates whether configuration is written into running but doesn’t tell us whether validation performed on intended is success or failure, validate operation defined in RFC6241 on candidate datastore may be different from Validation operation on intended since it clearly happens at different stage, sure validate operation can be applied to intended, but no standards explicitly specify whether validate operation can be applied to intended.
> This is something we can update in this document.
> 
> - If so, then maybe it isn't correct to have a username in the notifications. A specific user/session did the commit, but then if the commit process ends after candidate->running (i.e. the reply happens at that point), then isn't it really the system moving the config from running->intended->operational?
> [Qin]: See above.
> Jason

> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>