Hi Qiufang,
> Hi , Kent:
> Apologies for the delay. I missed your reply and never saw it in my
> inbox(bugs?) L.
> Thanks for the detailed examples and explanation, and now I have a better
> understanding about your proposal.
> Please see my reply inline.
No worries about the delay. I didn’t miss it at all ;)
> [likewise snip…]
> For the second category, imagine <system> containing some predefined objects.
> These objects follow the standard data-model allowed by the YANG. Operators
> could have defined these objects as well but, because there may be hundreds
> of these objects, and the objects are the same for everyone, the vendor
> decides to pre-define them as a convenience for their customers. This way,
> operators only have to define custom objects for what is unique in their
> environments. By example, imagine this in <system>:
>
> system-defined-defaults {
> applications {
> application ftp {
> protocol tcp;
> destination-port 21;
> }
> application tftp {
> protocol udp;
> destination-port 69;
> }
> application smtp {
> protocol tcp;
> destination-port 25;
> }
> ...
> }
> }
>
> And this in <running>
>
> # custom objects
> applications {
> application my-app-1 {
> protocol tcp;
> destination-port 2345;
> }
> application my-app-2 {
> protocol udp;
> destination-port 69;
> }
> }
>
> // an ACL policy referencing both sys-defined and custom
> objects
> policy from-zone untrust to-zone trust {
> policy allow-external-access-to-foobar-app {
> match {
> source-address any;
> destination-address any;
> application [ ftp tftp, my-app-1,
> my-app-2 ];
> }
> then {
> permit;
> }
> }
> }
>
> [Qiufang Ma] I can understand that the vendors would like to predefine some
> common objects for their users’ convenience so that the users only have to
> define their own objects for what is unique in their environments.
> What I don't really understand is why these configurations are not applied
> immediately but only after they are referenced?
The question is if the server implementation prunes dangling/unused objects
when <intended> is applied, updating <operational>. My assumption is that the
server will discard any object that doesn’t actually impact the running
configuration of the system (i.e., values are consumed by the underlying
operating system, drivers, etc.). Thusly, it is my opinion that only the
referenced objects are applied. Hence why, to answer your last question, I
wrote that these configurations (manufacturer-defined objects) are not applied
immediately but only after they are referenced. Makes sense?
Keep in mind that what is described above is just one aspect of what can be in
<system>. In addition to defining reference-able objects, <system> can also
define/apply configuration immediately (e.g., the loopback interface). That
is, configuration not does not have to be referenced in order to become
activated.
>
> Note that, <running> by itself would not pass validation, due to missing
> leafrefs. Thankfully, NMDA never says that validation runs on <running>.
> But once <running> and <system> have been merged, to become <intended>, the
> result does pass validation.
> [Qiufang Ma] The referenced instance must also exist for the data to be
> valid since the require-instance defaults to true if not present. Is this
> what you had in your mind? Yes, NMDA says that it is <intended> which is
> subject to validation. But I also notice that In section 5.1.3 of the
> NMDA:”<running> MUST always be a valid configuration data tree, as defined
> in Section 8.1 of [RFC7950]. ” So my thought here is that <running> should
> also conform to the YANG model constraints and that’s to say, a referenced
> system-defined data item should also exists in <running>.
> Therefore, if system configurations do not exist in <running>, they still
> need to be configured in <running> manually in order for being referenced.
> In this case, the original purpose of predefining some system configurations
> for user convenience is lost. This is the reason why we would like to define
> some mechanism here to synchronize <system> into <running>.
I see in RFC 8342 "<running> MUST always be a valid configuration data tree, as
defined in Section 8.1 of [RFC7950]”.
But the question remains if it is possible for the system is able to validate
<running> without, e.g., expanding templates. There may be a 'leafref' or
‘must’ expression somewhere that will fail because the evaluation occurs
without expanding a template that supplies the missing parts.
If this draft “updates” RFC 8342 (NMDA), then it can supply a clarifying
statement about what it means that "<running> MUST always be a valid
configuration data tree”. Either that, or an Errata if it’s determined that
the statement isn’t correct.
You make a good technical point, but I think that we should *want* to avoid
having to copy <system> (or <operational>) configuration into <running> if we
can avoid it. Agreed?
FWIW, also in RFC 8342, Section 5.1.4.:
<intended> is tightly coupled to <running>. Whenever data is written
to <running>, the server MUST also immediately update and validate
<intended>.
<intended> MAY also be updated independently of <running> if the
effect of a configuration transformation changes, but <intended> MUST
always be a valid configuration data tree, as defined in Section 8.1
of [RFC7950] <https://datatracker.ietf.org/doc/html/rfc7950#section-8.1>.
>
> > I am wondering if these configuration will present in the <operational>
> > (which contains all the configuration actually used by the device) before
> > they’re referenced.
>
> I think that it would depend in the specific server’s behavior, regarding if
> *unused* predefine objects are present in <operational>. Certainly the
> unused objects would not have to be present in <operational>. If I were
> implementing the server, the unused objects would NOT be present in
> <operational>.
> [Qiufang Ma] Yes, if the predefined system configurations is unused, then I
> also tend to agree that they would not be present in <operational> but may
> also depend on the vendor implementation.
Yup, this is the same conclusion is in my response above.
> > It would be good if we could determine if there are any other
> > "resource-independent” configuration categories here.
> > [Qiufang Ma] Do you think there exists conditional system configuration (if
> > the preceding configurations you mentioned above is not)? For example, if
> > SSH is enabled on a device, SSH-related keys are automatically generated.
> > Such configurations are generated at the moment when a special
> > functionality is enabled.
>
> I’m unsure what you mean in general by "conditional configuration”, but I can
> speak to your specific example. Though I must preface my comments that I
> imagine there are a number of ways servers might go about enabling `sshd`.
> What follows is my personal view, forged by being around systems for awhile
> ;)
>
> In general:
>
> - `sshd` is NOT enabled by default.
> - `sshd` is enabled via a configuration knob.
> - the SSH host key is dynamically generated the first time `sshd` is
> enabled.
> - the SSH host key itself is in <operational> (not <running>)
>
> This view is consistent with the first paragraph in Section 3 of the
> “keystore” draft (reproduced below):
>
> 3. Support for Built-in Keys
>
> In some implementations, a server may support built-in keys.
> Built-
> in keys MAY be set during the manufacturing process or be
> dynamically
> generated the first time the server is booted or a particular
> service
> (e.g., SSH) is enabled.
>
> As a closing thought, this model (which I stated upfront may not be
> universal) would have no presence-in or interaction-with <system>…though,
> perhaps, there may be some predefined values for what key-algorithms and/or
> key-lengths to use when generating the SSH host key...
> [Qiufang Ma] By “conditional system configuration”, I was meaning some of the
> system configurations are not generated immediately after the device is
> powered on. Instead, they are generated when a specific condition is
> satisfied during the device running(e.g., a functionality is enabled due to
> some client configurations). I am not sure if it really exists, maybe not,
> just try to explore the possibilities of various resource-independent system
> configurations.:)
To this point I agree..as does RFC 8342 (NMDA), Section 5.3.3.:
Sometimes, resources are controlled by the device and the
corresponding system-controlled data appears in (and disappears from)
<operational> dynamically. If a system-controlled resource has
matching configuration in <intended> when it appears, the system will
try to apply the configuration; this causes the configuration to
appear in <operational> eventually (if application of the
configuration was successful).
>
>
> Firstly, I again have to preface my comment that there are likely many ways
> that templating mechanisms can be defined. But, in general, once a
> templating mechanism has been defined, then it stands to reason that
> templates could be defined either in <running> (by operators) or in <system>
> (by the manufacturer). In one implementation I’m familiar with, the
> templates are objects that are referenced/parameterized by other parts of the
> configuration. (Same as with the predefined objects discussion above.)
>
> To answer your questions:
>
> 1) Yes, it is my opinion that *activated* templates in <system> will be
> expanded and present in <intended>.
>
> 2) I would never suggest that the system-defined templates are present in
> <running>, though they may be referenced/parameterized by config in <running>.
>
> 3) if a config-template is configured in <running> (i.e., it is
> operator-defined) then, yes, the expanded configuration in <intended> is
> "client configuration” (note, "client configuration” is not a formal term).
> That said, it seems fair to say that a template defined in <system> and then
> referenced by "client configuration” in <running> is also expanded as "client
> configuration” in <intended>.
>
> 4) I don’t not understand your last sentence, that the expansion of <system>
> templates are only present in <operational>. Maybe you’re saying something
> subtle, e.g., that servers currently don’t support GET on <intended>. But,
> in theory, the expansion of <system> templates should (IMO) be present in
> <intended>, so that they may be subject to validation. Of course, all the
> <intended> configuration (whether originating in <running> or <system>) that
> is successfully “applied” will also be present in <operational>.
> [Qiufang Ma] Assume that there is no <system> and this work, the expansion of
> system templates are only present in <operational>. Because this is
> compatible with system configuration definition in NMDA.
> But if system configurations are only present in <operational>, the
> predefined system configurations still need to be retrieved and created into
> <running> explicitly when being referenced. I think we’ve reached an
> agreement on the need for <system> to exist, and our main point of
> disagreement is whether <system> should be copied into <running>. Your point
> is that being merged into <intended> is enough to make sure a success
> validation. But my understanding is that the referenced system configuration
> data item must also exist in the <running> to obey the model constraints.
Yes, I believe that you provided an accurate description of the difference in
our opinions. Per my earlier response, you make a valid technical point, my
goal is to waive that interpretation to the side so that a simpler solution can
emerge. It would be good to get other opinions on list, otherwise we’ll take
it into the meeting.
[BTW, in keeping with this thread moving from the NETCONF to the NETMOD mailing
lists, would it make sense to move the IETF 111 presentation slot from NETCONF
to NETMOD too? I think it does and, further, it would help with scheduling
(NETCONF is over, NETMOD is under). Would you be okay with this? AD Rob and
the NETCONF chairs discussed this morning, and think it's okay, but would still
need to confirm with the NETMOD chairs.]
> <big snip>
> > I’m beginning to think that:
> > · auto-copying into <running> is likely never a good idea, because
> > it violates the definition of <running>
> > [Qiufang Ma] I am quite aware that different datastores in NMDA represents
> > different views of data nodes. And <running> represents a configuration
> > datastore holding the current configuration of the device.
> > Should we consider system configuration also be part of current
> > configuration of the device? From my perspective, the difference between
> > system configuration and client-configuration lies only in who provides it.
>
> <running> holds the current *operator-specified* configuration of the device.
> System-provided configuration is NOT specified by operators (though
> system-defined objects may be referenced by operator-specified config in
> <running>). I believe that this arrangement is consistent with the
> definition of <running>. Agreed?
> [Qiufang Ma] Yes. Actually we are not trying to violate the principles of
> NMDA and the definition of <running>. The issue we try to resolve here is
> that system configurations cannot be used(referenced or overwritten) by the
> operators directly and need to be created into <running> explicitly. This
> actually loses the meaning of “predefining and bringing convenience”. If
> auto-copying is not a good idea, what do you think about defining an RPC
> operation for the operators to do the copy(which is also what Rob suggests at
> the meeting)?
If we have to copy into <running>, then I think that I agree an RPC
(<edit-config>?) would be better.
You mention “overwritten” by the operators? Why wouldn’t the operators just
define their own? For instance, if they don’t like the vendor’s
“vendor-foobar” object, they could copy/paste/edit their own “my-foobar” object
with the values needed, yes?
>
>
> > · having in <operational> doesn’t make sense, since the tweaks
> > wouldn’t go thru <running> --> <intended> validation.
> >
> > I’m wondering if a model like below would work for everyone - thoughts?
> > [Qiufang Ma] <intended> represents the configuration after all
> > configuration transformations to <running> have been performed, so I think
> > it is only coupled to <running>.
> > Anyway, the <system> should also interacts with <operational>. Agreed?
>
> I don’t agree that <intended> must only be coupled to <running>.
> Specifically, I think that it is okay (compatible with NMDA) to define a
> <system> that also impacts <intended>. This is the only (IMO) sane
> approach, as it enables the combination <running> + <system> to be validated.
> [Qiufang Ma] Please see above. If <running> is OK to miss referenced system
> configuration, your proposal makes sense to me.
Ack.
> Best Regards,
> Qiufang Ma
Kent // contributor_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
