Hi , Kent:
Apologies for the delay. I missed your reply and never saw it in my
inbox(bugs?) :(.
Thanks for the detailed examples and explanation, and now I have a better
understanding about your proposal.
Please see my reply inline.
[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 untrust {
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?
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 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.
> 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.:)
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.
<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)?
> * 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.
Best Regards,
Qiufang Ma
>
> Best Regards,
> Qiufang Ma
Cheers,
Kent // contributor
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
