Thanks Kent. About the presence of template data in the ‘intended’ -> I can see your point about it being redundant but Juergen’s initial gut feel was to have it present. I guess this is something that we’ll need to decide and describe somewhere as it may not be obvious. I’m not sure if that is for the datastores draft or for some potential future ‘templates’ draft).
You mentioned “Assuming the deleted leaf has a default value”. Do you make a distinction between a default value that is present in the schema (i.e. a ‘default’ statement in the YANG) vs an internal default value that the system may use but isn’t exposed in the YANG ? Another way of saying this -> is ‘report-all’ required to only return values that are in the ‘default’ statements of the YANG schema ? One example -> an incomplete YANG schema that is missing the default value statement for some leaf abc. But the system knows the default and can return it in a ‘report-all’ query. Another example -> what about a leaf that has a dynamic default value ? For example -> an interface mtu that can be explicitly configured by the user, but if that leaf is deleted then the system selects different values X or Y depending on whether the interface is using dot1q encap vs null ethernet. That dynamic type of default can’t really be expressed in YANG. But the system could report the value X or Y in a ‘report-all’ query. Would we really need ‘report-inheritance’ if we add the ability to read the ‘intended’ datastore ? Jason From: Kent Watsen [mailto:[email protected]] Sent: Thursday, February 16, 2017 17:30 To: Sterne, Jason (Nokia - CA) <[email protected]>; [email protected] Subject: Re: [netmod] netmod-revised-datastores: templates, interactions with RFC6243 'report-all' Hi Jason, > draft-nmdsdt-netmod-revised-datastores-00 mentions that “Templates > are expanded when copied into <intended>”. > > That means the non-expanded template (i.e. the single copy of template data > itself) > is in the running. Yes. > Is that original non-expanded template data (which is presumably part of the > schema) > also present in the <intended> DS (along with the expanded copies of the > data) ? Yes, the YANG would have to define schema for both the template and expanded forms. No, having both data values in 'intended' that would be redundant and confusing. > What would an RFC6243 <get-config> response from the <running> DS with > ‘report-all’ > be expected to return for a leaf that is deleted in the ‘main’ part of the > config but has > been overridden by a value for that leaf in a template ? RFC6243 'report-all' doesn't have any template awareness, it only relates to default values. Assuming the deleted leaf has a default value, then that default value would be reported and, when using 'report-all-tagged', it would be tagged as such. > Example -> some leaf-a with a default value of 50, that is not present in the > config, but > is present in a template that sets leaf-a to 55. A ‘report-all’ response > could show a > value for leaf-a in the template and in the main part of the config. What > value would > be returned for leaf-a in the main part of the config ? 50 (since ‘running’ > doesn’t have > expanded templates) or 55 (i.e. the result of the value of leaf-a due to the > template > expansion) ? 50. > The spirit of report-all seems to be to reflect what values the router is > using, even when > they aren’t explicitly configured. So 55 is the actual value being used in > the system. But > returning 55 would mean we are returning the ‘expanded’ view (which the > running isn’t > supposed to have). What is needed is a <get-config> flag like 'report-inheritance' that does some combination of template-expansion and returning metadata for where values came from. However, this is only going to be defined when someone writes a "template" draft. Kent (as a contributor)
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
