We want to close on some of the NMDA document comments. I'll send a
separate summary for all the issues later, possible tomorrow.
In the absence of seeing any comments to the contrary, and with the
change supported by the other authors, I will apply the proposed update
to the <intended> description below.
This should resolve two issues:
https://github.com/netmod-wg/datastore-dt/issues/9
- Title: "Make it clear that validation of intended includes default
values"
https://github.com/netmod-wg/datastore-dt/issues/3
- Title: "Enhance description of intended datastore"
Thanks,
Rob
3) I think that it would be useful to further refine my previous
proposed text for intended, particularly rewriting the text on
validation. This should hopefully also address Balazs' concern about
default values be included in validation.
<Old>
4.4. The Intended Configuration Datastore (<intended>)
The intended configuration datastore (<intended>) is a read-only
configuration datastore. It is tightly coupled to <running>. When
data is written to <running>, the data that is to be validated is
also conceptually written to <intended>. Validation is performed on
the contents of <intended>.
For simple implementations, <running> and <intended> are identical.
<intended> does not persist across reboots; its relationship with
<running> makes that unnecessary.
Currently there are no standard mechanisms defined that affect
<intended> so that it would have different contents than <running>,
but this architecture allows for such mechanisms to be defined.
One example of such a mechanism is support for marking nodes as
inactive in <running>. Inactive nodes are not copied to <intended>,
and are thus not taken into account when validating the
configuration.
Another example is support for templates. Templates are expanded
when copied into <intended>, and the expanded result is validated.
</Old>
<Proposed>
4.1.4. The Intended Configuration Datastore (<intended>)
The intended configuration datastore (<intended>) is a read-only
configuration datastore. It represents the configuration after all
configuration transformations to <running> are performed (e.g.
template expansion, removal of inactive configuration), and is the
configuration that the system attempts to apply.
<intended> is tightly coupled to <running>. Whenever data is written
to <running>, then <intended> is also immediately updated by
performing all necessary transformations to the contents of <running>
and then <intended> is validated.
<intended> may also be updated independently of <running> (e.g., if
one of the configuration transformations is changed), but <intended>
must always be a 'valid configuration data tree' as defined in
Section 8.1 of [RFC7950].
For simple implementations, <running> and <intended> are identical.
The contents of <intended> is also related to the 'config true'
subset of <operational>, and hence a client can determine to what
extent the intended configuration is currently in use by checking
whether the contents of <intended> also appears in <operational>.
<intended> does not persist across reboots; its relationship with
<running> makes that unnecessary.
Currently there are no standard mechanisms defined that affect
<intended> so that it would have different contents than <running>,
but this architecture allows for such mechanisms to be defined.
One example of such a mechanism is support for marking nodes as
inactive in <running>. Inactive nodes are not copied to <intended>.
A second example is support for templates, which can perform
transformations on the configuration from <running> to the
configuration written to <intended>.
</Proposed>
Thanks,
Rob
/martin
.
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
