Hi,
I do not agree that a new datastore is needed to supposedly retrieve the system created nodes that exist (already supported by get-data) or the nodes that could be created by the server but do not currently exist. The <config> element is way too simplistic to represent all the real-world possibilities. Current XPath procedures define several contexts for evaluating expressions. None of these procedures support an additional <system> datastore that is somehow merged with the other datastores for XPath purposes. YANG 1.1 does not support this proposal at all. Andy On Tue, Aug 3, 2021 at 8:34 PM maqiufang (A) <[email protected]> wrote: > Hi, Andy, > > > > Apologize for my chiming in. Please see my reply inline. > > > > *From:* netmod [mailto:[email protected]] *On Behalf Of *Andy > Bierman > *Sent:* Wednesday, August 4, 2021 1:11 AM > *To:* Fengchong (frank) <[email protected]> > *Cc:* Balázs Lengyel <[email protected]>; > [email protected] > *Subject:* Re: [netmod] 答复: system configuration sync mechanism > > > > > > > > On Tue, Aug 3, 2021 at 12:34 AM Fengchong (frank) < > [email protected]> wrote: > > Hi juergen, > Please see my comments inline. > > /frank > > -----邮件原件----- > 发件人: Jürgen Schönwälder [mailto:[email protected]] > 发送时间: 2021年8月3日 12:15 > 收件人: Fengchong (frank) <[email protected]> > 抄送: Andy Bierman <[email protected]>; Kent Watsen <[email protected]>; > Balázs Lengyel <[email protected]>; > [email protected] > 主题: Re: [netmod] 答复: system configuration sync mechanism > > On Tue, Aug 03, 2021 at 01:45:40AM +0000, Fengchong (frank) wrote: > > Hi andy and all. > > > > I don’t think get-data with origin can solve the issues below: > > > > > > 1. Some leafs like interface type CAN NOT be modified by user, but > can be referenced by other config nodes(e.g. using leafref or occur in > when/must). The validation will be fail if these leafs are not be > configured by user now explicitly (we assume these leafs are optional and > no default value). > > The interface type in the RFC 8343 module is config true. YANG does not > allow you to refer to config false nodes in constraints that apply to > config true nodes. A core principle is that the content of a configuration > datastore can be validated without knowing the actual state of the system. > > Frank: yes, interface type is a config node, but it isn't allow to be > modified. If a config node reference if-type, in order to validate data > successfully ,user must have to config if-type with determined value again. > For example, user must config if-type with 'ethernet' for ethernet0/0/1. I > don't think it makes sense. The if-type has been created by system, when > running config is merged to <operational>, it can work and the validation > is successful. If you think running datastore is self-contained, I will > think the system configuration should be imported to running datastore > automatically to ensure successful validation > > > > > > I doubt another rewrite of ietf-interfaces would gain much support. > > > > There are many objects that have user access restrictions that are not > standardized > > with machine-readable statements. I am interested in the 2 use cases that > Balazs described. > > The system does its own access control (not NACM) wrt/ these objects. The > server just > > rejects the edit requests, even though the standard YANG indicates it > should be writable. > > Some standard extensions to tag the data would help applications better > predict server behavior. > > > > There is no way in YANG 1.1 to have a config=true node reference > config=false in the XPath. > > (Well, we implement it but the developer has to enable it). > > > > I do not see the point of the system datastore if it contains config=true > nodes, > > just so that XPath can reference it. I do not agree that it is useful or > easy to implement, > > especially since the contents of <system> are visible in <intended>. > Representing the possible > > instances is non-trivial (e.g. pattern allowed, not a fixed name, > resulting in 6 million possible values). > > *[Qiufang Ma] I don’ t see any system configuration handling behavior > standards in non-NMDA; NMDA defines that system configuration should only > be included in <operational>. I think it necessary to distinguish between > system configuration and operational state.* > > *Since there may be some requirements to reference the system > configuration, it doesn’t seem sensible to treat system configuration as > operational state. I don’t think retrieval from <operational> should be the > only way to get system configurations, given the definition of operational > datastore.* > > *That is to say, <operational> contains all applied configurations which > go through configuration combination and template expansion. Only the > system configurations which take effect are included and will be tagged as > “origin=intended” once being referenced in <running>. I believe there would > be a need to get the pure system configurations regardless of whether being > applied or not.* > > > > If the system datastore contains config=false nodes, then you are talking > about a rewrite > > of the YANG validation architecture and a new version of YANG. IMO there > is no need for that. > > *[Qiufang Ma] I don’t think <system> would contain config=false nodes. A > rewrite of the YANG validation architecture and a new version of YANG are > not our > intention. > * > > > > Best Regards, > > Qiufang Ma > > > > > > Andy > > > > > > > 2. Some instances are generated by system, but these instances can > be referenced by other config nodes. The validation must be fail if these > instances are not be recreated by user explicitly now. > > Yes, a configuration datastore is self-contained. If a client wants to > configure the interface x, it has to define the interface x in the > configuration. Note that this should not be confused with a system > generating an interface x after probing the hardware. Note the difference > between operational state, applied config, and running config. > > Frank: for example , predefined policies are provided by system, user > configuration can reference these predefined policy directly. but because > predefined policies are not configured by user explicitly, the validation > will be fail. If you want to get a successful validation , user MUST have > to redefined the system predefined policies. > So, system predefined data are useless. I think it is unreasonable. > > > > Let me add that the underlying model is that the client(s) have control > over the configuration. A system making ad-hoc changes to the config (even > with the best intentions) will be surprising. In this model, the only way > to inject config into running on system boot is to have a client making > changes to running following the normal procedures - at least conceptually. > This means that conceptually the other clients need to be aware that there > is a system client injecting configuration. > > If you follow this logic, it seems wrong to define a system datastore that > is somehow magically merged into running - and it is not needed. > > Frank: system configuration not only includes some instances generated on > reboot time, but also includes the configuration when hardware is plugged > in, or a function is enabled (for example, in huawei's implementation, when > QOS function is enabled, many qos predefined policies are created by > system) or a user-created list instance is created, some leafs' value will > be created by system. So , we need a system datastore to hold these > configuration. > > > 3. User may need know what the original system configuration is, > if we get data from <operational>, you may get the modified system > configuration.(for example, user modify or template is expanded, or only > active instances) > > If you have multiple clients managing shared configuration, then yes it is > good if they are aware of what is going on. I am not sure yet that exposing > other clients intentions via additional datastores and defining merge > mechanisms and semantics is the way to go. > > > I don’t care about whether system datastore is imported to running or > intended datastores. But I think if a config node reference a system node, > the validation (running or intended datastores) will be successful even if > the system node is not configured by user explicitly. > > I am concerned about having to define what "is imported" means precisely > and whether moving to a model multiple datastores have to be merged before > validation is the way to go. We already acknowledged that there are > template expansions in some implementations without working out how they > work. > > > Especially on the client side, if a client need validate all data > retrieved from server, the validation SHOULD be successful. If system > configuration are not imported to running, at a minimum, the client needs > to know what the original system configuration is. Another way is adding > with-system-used parameter to get-config operation to retrieved all user > configuration and system configuration referenced by user configuration. > > Let me repeat, in the original model, the running configuration datastore > is self-contained and can be validated without knowing additional > datastores. > > /js > > -- > 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
