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:[email protected]] 代表 Sterne, Jason (Nokia - > CA/Ottawa) > 发送时间: 2018年11月6日 10:56 > 收件人: [email protected] > 主题: [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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
