Hi, Jason, Thanks for getting back to me. Please see my reply inline...
I think there are a couple of important fundamental issues raised below: Only auto-copy things missing to make <running> valid vs auto-copy the entire contents of a referenced list entry from system->running. [Qiufang] Please see more of my comments below, I am not sure the latter choice makes sense to me. When to auto-copy: at edit time or at validation time. [Qiufang] Maybe another issue: interplay between <system> and default value. Jason #1 Running MAY become invalid Section 4.2, which discusses software upgrades etc., has some wording that is new in -05: If system configuration changes (e.g., due to device upgrade), <running> MAY become invalid. The server behaviors of migrating updated system data into <running> is beyond the scope of this document. That said, the following gives a list of examples of server implementations that might be possible: I think this is unacceptable and a direct violation of RFC 7950 section 8.1. Prior to this document, I am not aware of any RFC that allows running to become invalid under any circumstances. I think the always valid running is a very important part of the contract between servers and clients. [>>JTS:] I can see Jan's concern here. Perhaps we should could replace the "If system configuration changes..." paragraph with the following: The behavior of the server when system configuration changes (e.g. due to device upgrade) is outside the scope of this document. That said, , the following gives a list of examples of server implementations that might be possible: [Qiufang] Thank you Jason for the proposed text, regarding the first sentence (starting with "The behavior of the server..."), I am thinking whether we need to document it more specific to software upgrade scenario given the statement in sec5.3 that If the "resolve-system" parameter is not given by the client, the server should not modify <running> in any way otherwise not specified by the client. OLD: The behavior of the server when system configuration changes (e.g. due to device upgrade) is outside the scope of this document. NEW: The behavior of the server when software is upgraded is not specific to system configuration and outside the scope of this document. Better? [>>JTS:] I don't think we should restrict the statement to only being about the software upgrade scenario. This section 4.2 is about changes to <system> no matter how they happen (upgrade, but also other reasons mentioned in the draft). The server behavior when those changes occur can vary whether system changed because of upgrade or those other reasons. I also think 5.3 is a somewhat different issue. That 5.3 statement you quote is more general (and not specifically related to changes to <system> that could trigger changes to <running>, e.g. during an upgrade). [Qiufang] What I am thinking is, if we don't restrict this statement to software upgrade only, combined with the examples of possible behaviors listed, it seems to imply that any system configuration update (e.g., interface config being cleared from <system> due to removal of an interface card) would need the server to do something to ensure validity of <running>. Is this true (and acceptable)? IMO if interface is removed physically, and related config disappears from <system>, <running>/<intended> would become invalid only if the interface is referenced but not copied in <running>. Or maybe add back about the choice that server does nothing and client decides whether some fix needs to be done in <running>? #3 Defaults vs system config [>>JTS:] I suppose we have two options here: 1) Say that the system values override defaults in the running, or 2) Say that any leaf with a non-default value in system also needs to be copied into running? Of course then this no longer becomes purely about *validity* anymore... [Qiufang] I think Jan is raising a good point, the WG should not miss the interplay between defaults and system config. I am not sure I like option 1) . If it is the client's intention to enable interface "lo0" and explicitly write a default value (true) into <running>, it should override the value in <system>. [>>JTS:] You mention "explicitly write". I'm not positive what you meant here, but I was talking about the case where the operator creates lo0 in running but does *not* explicitly configure the 'enable' leaf in running. So in option #1: - reading the 'enable' leaf from running will return nothing [Qiufang] My understanding is it would return "true" or nothing, depending on the with-defaults basic-mode or retrieval parameter being used. - the client may assume that the value being used by the router for 'enable' is 'true' (default in the YANG) [Qiufang] maybe and maybe not, depending on if the client has also read <system> or <operational>. - actual value being used by the router is 'false' [Qiufang] In your option1, system values override defaults in <running>, I have concern that this goes against with our definition that <running> takes precedence over <system>. But this issue isn't really specific to just defaults. It is an issue for *any* instance data in <system> that isn't auto-copied into <running>. For example, imagine a leaf that doesn't have any default value at all, but that leaf is configured to a specific value in <system>. Any data missing from running will result in the client having the wrong view/information. [Qiufang] I am not sure that is even an issue, <running> contains what is explicitly sent by the operator, that is the view/information <running> represents according to its definition. If the client wants the full view/information, it should read <intended> or <operational>(if it wants to understand what is actually in use). If we want to also solve that problem in this draft, then every single leaf that has an explicit value in <system> would have to be copied as part of the resolve-system auto copy (not just the leafs that are required for validity). That's option #2. Interesting question for the WG. That may be simpler than trying to determine exactly which subset of those leafs are actually needed for validity of running (i.e. "just copy everything"). [Qiufang] Consider why would the client care what is a specific value of a leaf in <system> if it is not explicitly referenced/depended? I am not sure we want to clutter <running> with a lot of system configuration which might not even be cared by the client. Besides, clients can always read <system>, as well as <intended> where <system> is populated into. Option 2) may seem to work for me. If the server sets the value for a node that is different from the schema default value, it must be copied into <running> if its parent node is copied explicitly or automatically by "resolve-system" parameter, and any updates of this value (unless it's updated to its schema default value) needs to be reflected into <running> automatically. And I think this is independent of the topic about the validity of <running> alone. Thoughts? [>>JTS:] I'm not sure what you mean about "and any updates". Are you referring back to section 4.2? [Qiufang]Yes, suppose a leaf has a schema default value 3, and what the server set is 4, in your option 2), 4 should be copied into <running>, but later this value might be updated to 5 by the server, should the server update <running> with value 5 then? Or leave this as undefined? #4 Resolve-system only for filling in blanks The second paragraph in 5.3 states that The "resolve-system" parameter is optional and has no value. If it is present, and the server supports this capability, the server MUST copy referenced system nodes into the target datastore (e.g., <running>) without the client doing the copy/paste explicitly, to resolve any references not resolved by the client. One possible interpretation here is that the server must copy the referenced items from running when resolve-system is in use. I don't think that is the authors' intent. I believe the intent is that the configuration should only be copied if it is *missing* in running, i.e. never overwrite anything in running. If this is correct, I think the wording should be improved to reflect this. [>>JTS:] Agree we should say this copy only occurs for schema elements that aren't already explicitly configured in running. [Qiufang]Yes, also agree that only the missing part needs to be copied. Would the following proposed update work for both of you: OLD: If it is present, and the server supports this capability, the server MUST copy referenced system nodes into the target datastore (e.g., <running>) without the client doing the copy/paste explicitly... NEW: If it is present, and the server supports this capability, the server MUST copy referenced system configuration into the target datastore (e.g., <running>) where it is missing from without the client doing the copy/paste explicitly... [>>JTS:] That new sentence isn't quite right IMO, and this may need further rework depending on Jan's "#3 Defaults vs system config" (since we may need to copy more than just the referenced configuration - it may need to include all explicitly configured descendant nodes as well). Perhaps this instead: If it is present, and the server supports this capability, the server MUST copy referenced system nodes and all explictly configured descendant nodes in <system> that are missing from <running> into <running> without the client doing the copy/paste explicitly. The copy operation MUST NOT overwrite any explicit configuration in <running>. [Qiufang] Yes, maybe defaults should be copied, but I am unsure about other unreferenced descendant nodes in <system>. #5 Non-grammatical sentence The third paragraph of section 5.3 reads The server's copy referenced nodes from <system> to the target datastore MUST be enforced at the end of the <edit-config>/<edit- data> or <copy-config> operations during the validation processing, regardless of which target datastore it is. I am not able to parse or guess the intended meaning here. There is something non-grammatical about this sentence. Please rephrase. [>>JTS:] I believe this is trying to address when the auto copy happens. In theory it could happen as part of the application of the edit-config but the paragraph implies it just needs to happen before a validation. I was generally thinking this would happen as part of the edit, but I can also see that in theory an implementation could deal with all the auto-copying during a validation operation instead (it may be easier to identify all the things that need to be copied to make it valid at that point). [Qiufang] Thanks Jason for helping clarify the intent. I assume this is the easier way for the server to copy the missing parts during the leafref/when/must/mandatory true/min-element constraints enforcement process. But if we say this only has to happen before validation, then a client won't necessarily be able to see the auto-copied data if they do a get-data right after an edit-data. [Qiufang] Yes, another reason I think the timing of auto-copy enforcement should be specified instead of leaving it as implementation specific is, things might become different if auto-copy happens at different process. I.e., if it happens during validation, it implies that if <candidate> doesn't need to be validated, then auto-copy won't happen even though the "resolve-system" parameter is present. But in the end I'm not positive we want to force implementations to do this auto-copy as part of the edit. A candidate datastore doesn't have to be valid (until a validate or commit). [Qiufang] Another thought in mind: Should the validate and commit RPC operation also support this parameter? [>>JTS:] Interesting question. If we aren't going to auto-copy until validate-time, then perhaps the resolve-system should indeed be a parameter of <validate> or <config>. The downside is that I think it may be more intuitive to users if the auto-copy happens as part of an edit. On the other hand, maybe a subsequent edit was going to add some configuration that was going to resolve the missing leafref. If we don't auto-copy at edit time, then the client won't be able to see a complete view of what is about to be committed when they do a get-data before the commit. But if we do auto-copy at edit time, that may be a pretty expensive operation for the server (I'm worried it may effectively have to do some something almost as expensive as a validation to find the missing pieces). [Qiufang] It seems that both have its pros and cons, I don't have strong feelings either way, but I am thinking can we leave it as implementation specific? And we also need to augment <validate> and <commit> RPC operations, I think, for servers do auto-copy at validation time. Client will decide by its own whether to use "resolve-system" to edit candidate ds (we can assume the client understand the consequence of this parameter before it uses it). As long as this parameter is carried, the server always does the auto-copy. Does this make sense? Best Regards, Qiufang
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
