Hi, Jason,
Thanks for getting back to me. Please also find my response below inline... -----Original Message----- From: Jason Sterne (Nokia) [mailto:[email protected]] Sent: Tuesday, May 14, 2024 2:57 AM To: maqiufang (A) <[email protected]>; Rob Wilton (rwilton) <[email protected]>; [email protected]; NETMOD Group <[email protected]>; [email protected] Subject: RE: [netmod] Re: WGLC on system-config-05 Thx Qiufang. Please see inline. Jason From: maqiufang (A) <[email protected]><mailto:<[email protected]>> Sent: Monday, May 13, 2024 3:47 AM To: Jason Sterne (Nokia) <[email protected]><mailto:<[email protected]>>; Rob Wilton (rwilton) <[email protected]><mailto:<[email protected]>>; [email protected]<mailto:[email protected]>; NETMOD Group <[email protected]><mailto:<[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: [netmod] Re: WGLC on system-config-05 Hi, Jason and Rob, Thanks you both for your valuable comments, all good points, much appreciated. Please also find my reply below inline... -----Original Message----- From: Jason Sterne (Nokia) [mailto:[email protected]] Sent: Saturday, May 11, 2024 12:29 AM To: Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>>; Kent Watsen <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [netmod] Re: WGLC on system-config-05 Please see inline for comments on the "moderate level comments". I'll try to reply later with more feedback on further items below. Jason From: Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> Sent: Thursday, May 9, 2024 9:55 AM To: Kent Watsen <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [netmod] Re: WGLC on system-config-05 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. [Resending due to mailer issues.] [Qiufang] Thanks, I see it's been accurately archived now. Hi authors, chairs, WG, I'm generally supportive of this work, but I think that there are still some potential corner cases that are not covered, or it isn't entirely obvious how they are handled. Comments below. Moderate level comments: (1) p 7, sec 2.3. Inactive-Until-Referenced There are some system configuration predefined (e.g., application ids, anti-x signatures, trust anchor certs, etc.) as a convenience for the clients, which must be referenced to be active. The clients can also define their own configurations for their unique requirements. Inactive-until-referenced system configuration is generated in <system> immediately when the device is powered on, but it is not active until being referenced. I'm not sure whether Inactive-Until-Referenced actually needs to be defined, or to put it another way, I'm not sure whether this type of configuration is special to system datastores at all. If a configuration (either explicitly in <running> or implicitly from <system>) defines a QoS policy that is not referenced from anywhere, (e.g., not applied to any interfaces) then I think that it up to the server to decide whether that unreferenced QoS policy is reported in operational or not, depending on server implementation. [>>JTS:] I agree. I think section 2 may be mixing up two concepts: 1. Data dynamically being populated/removed from the system datastore, and 2. For data that is in the system datastore, whether it is "active" and present in the operational datastore [Qiufang] Yes, it's actually from 2 dimensions to differentiate different kinds of system config: 1. Time of being generated; 2. Time of being applied. For #2 I don't think there should be anything special. We could say something like: As with the running datastore, data present in the system datastore may or may not be present in the operational datastore depending on whether it is considered as active configuration or not by the server. [Qiufang] I am personally okay to remove the third kind of definition to keep the definition dimension consistent, and maybe for system configuration being generated at both different times (immediately vs. conditional), they may be either applied by the server immediately or only after being referenced. I also think it's worth adding some text as Jason suggested, the client would benefit from the knowledge that there might be some system configuration that is defined there but not actually in use. [>>JTS:] I think it is more than just removing the 3rd type defined in section 2. We probably need to rework to just have two types (for the one dimension): 1. Immediately-present 2. Conditionally-present They would both related purely to presence of config in <system> (and not say anything about whether they are applied or active). [Qiufang] Noted. For #1 there is a bit of repeat with section 4.2. We should probably just talk about system config coming and going (and changing) in one place. [Qiufang] I think you are referring to the QoS examples in the first paragraph of sec.4.2, right? We will move this to sec.2 in the new revision. [>>JTS:] I wasn't just referring to the QoS example. It was the entire concept that the contents of the <system> datastore can change. But maybe it is OK if that concept is mentioned in the 2 places. Perhaps we should just refer back to section 2 from 4.2 when we mention things dynamically showing up in <system>. I would not necessarily move your QoS example out of 4.2 - it seems useful there (as well as useful in section 2). [Qiufang] I see your point now, Thanks for clarification. I agree to refer to section 2 (and maybe section 3 as well) in section 4.2, but then wouldn't that make the QoS example in Section 4.2 redundant? We'd have to update other parts of the doc (e.g. 5.1) where these 3 types of data are mentioned. [Qiufang]Yes, I agree. (2) p 9, sec 5.1. Conceptual Model of Datastores When the device is powered on, immediately-active system configuration is generated in <system> and active immediately, but inactive-until-referenced system configuration only becomes active if referenced by client-defined configuration. However, conditionally- active system configuration will only be created and active when specific conditions on system resources are met. I think that it should be "merged with system" not "merged into system" since the running configuration never ends up in the system datastore. [>>JTS:] Yes. Jan mentioned the same. [Qiufang] This will be fixed in the new revision, thanks! (3) p 9, sec 5.1. Conceptual Model of Datastores additional nodes to a list entry or new list/leaf- list entries appearing in <running> extends the list entry or the whole list/leaf-list defined in <system> if the server allows the list/leaf-list to be updated. How is this achieved? This appears to suggest that there are two different merging behaviours (one choice is to be additive, the other is to replace), and it seems to be down to the server to choose what to do on a case-by-case basis. I think that it would be cleaner to define a single merge behaviour if that is feasible (even if it is slightly less flexible). Also, potentially it is appropriate for the merge behaviour to be different for list vs leaf-list (e.g., always merge list entries, but do a simple replace on leaf-lists). [>>JTS:] I think part of the complication is that we want to allow the possibility that there is a list that contains entries in <system>, and it is a completely non-modifiable list (no new entries allowed). I think maybe that's what the "if the server allows" part is about. I agree though that it should be a merge for lists (and the server can just error if that merge makes the list invalid, i.e. no additional entries allowed on top of what's in system). For leaf-lists that a tough one (merge vs replace). I'm not sure what to do there (and can imagine use cases for both merge and replace). [Qiufang] I think for both leaf-list and list cases, additive should be the right answer when merging(note that client has no way to remove system config, its lifecycle is beyond client control). But then ordering is another question if it is "ordered-by user". I am not sure this draft is right place to define how the merge should happen, merge operation is there as early as 6241. Is there any difference when it comes to <running> being merged with <system>, no? I expect the merge behavior in this document be consistent with what's defined elsewhere. Just noticed that Kent has already raised a netconf-next issue for this: https://github.com/netconf-wg/netconf-next/issues/19.Maybe the right thing to do is to remove any text related to the merge behavior which also related to this sentence? [>>JTS:] You raise a good point about ordered-by user. That's going to make the merge problematic. I don't think currently existing definitions really address it for this draft. I'm doubtful we should actually define how merge of ordered-by-user lists should work for system->running. We may need to leave that undefined (system specific) or disallow it (error, or make it a replace). I'd lean towards leaving it undefined. [Qiufang] I would also agree to leave it undefined. Having that said, should the last paragraph or the entire sec.5.4 (https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-05#section-5.4) be removed? I think sec.5.4 should be independent of the merge behavior, i.e., whether it is replacement or addition behavior for list/leaf-list, and no matter what is the ordering of the merge result would be, sec.5.4 always makes sense. (4) p 9, sec 5.1. Conceptual Model of Datastores If a server implements <intended>, <system> MUST be merged into <intended>. This sentence is just repetition and can be deleted. The text above is still normative without the RFC 2119 MUST. [Qiufang] Yes! It is always the case that <system> is merged into <intended>. Even though the server doesn't implement an explicit <intended>, there could also be a conceptual one. Will remove it in the new revision. (5) p 13, sec 5.4. Modifying (Overriding) System Configuration For instance, descendant nodes in a system-defined list entry may be modifiable or not, even if some system configuration has been copied into <running> earlier. If a system node is non-modifiable, then writing a different value for that node MUST return an error. The immutability of system configuration is defined in [I-D.ma-netmod-immutable-flag]. I think that some care is needed here. E.g., if the modification was being done to <candidate>, then it isn't writing a different value to <candidate> that would return an error, but instead the <validate> or <commit> operation that would fail. [>>JTS:] Agree. Maybe we can just add this? If a system node is non-modifiable, then writing a different value for that node MUST return an error during a validate or commit operation. [Qiufang]"A validate operation" is easy to be confused with the <validate> RPC operation, I think you're referring to the server's validation process, not just <validate> RPC operation, right? Or we can just state writing a different value into <running> MUST return an error. I am okay with either. [>>JTS:] I was talking about the <validate> operation. We should probably clarify this in the text and not just keep the current sentence. [Qiufang]But if it is for <running> (with the writable-running capability), the error response should be returned during the <edit-config> operation. See if the following text is better: If a system node is non-modifiable, then writing a different value for that node MUST return an error during a <edit-config>, <validate> or <commit> operation, depending on the target datastore. Best Regards, Qiufang
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
