Re: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)
RFC 8342 says: However, MUST always be a valid configuration data tree, as defined in Section 8.1 of [RFC7950]. is tightly coupled to . Whenever data is written to , the server MUST also immediately update and validate . MAY also be updated independently of if the effect of a configuration transformation changes, but MUST always be a valid configuration data tree, as defined in Section 8.1 of [RFC7950]. For simple implementations, and are identical. /js On Wed, Nov 07, 2018 at 03:37:57PM +, Qin Wu wrote: > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Sterne, Jason (Nokia - > CA/Ottawa) > 发送时间: 2018年11月6日 10:56 > 收件人: netmod@ietf.org > 主题: [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 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 > 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 , the server MUST also immediately update and validate > >. > > “ > > So validate takes place after commit operation. It involves in > configuration transformations to 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 > netmod@ietf.org > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Sterne, Jason (Nokia - CA/Ottawa) 发送时间: 2018年11月6日 10:56 收件人: netmod@ietf.org 主题: [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 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 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 , the server MUST also immediately update and validate . “ So validate takes place after commit operation. It involves in configuration transformations to 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[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 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. 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 ? - 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? Jason ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
