Hi,
This is regarding the question as to whether it should be allowed for a
system to manipulate <running>:
This issue isn't really specific to the NMDA architecture, and there is
no consensus on whether this should be allowed.
Hence, the proposal is that the NMDA architecture draft be completely
silent on this, neither endorsing this behaviour, not restricting it.
Hence no changes to the NMDA architecture draft are required for this issue.
However, I have added an FAQ entry to clarify that this being is not
prevented, but pointing out some of the potential downsides to a device
doing this. The FAQ entry is
https://github.com/netmod-wg/FAQ/wiki/FAQ-related-to-NMDA-implementations#Q9
Unless I hear otherwise, I propose closing this issue
(https://github.com/netmod-wg/datastore-dt/issues/8). Comments/review of
the FAQ text is also welcome.
Thanks,
Rob
On 14/09/2017 18:08, Robert Wilton wrote:
On 14/09/2017 16:35, Balazs Lengyel wrote:
See below!
On 2017-09-14 16:32, Martin Bjorklund wrote:
Hi Balazs,
Thanks for your review. Comments inline.
Balazs Lengyel<[email protected]> wrote:
Hello,
Reading the draft-ietf-netmod-revised-datastores-04 some comments:
General) The system often adds data to the <running> or <intended>
datastore already not just to <operational>: e.g.
UC1: I have a server configured in running. I need to bind it to an
ip-address. The ip-address might be the local loopback address,
however if that is only added to <operational>, validation will
fail indicating that the server is bound to a non-existent
address. How to handle this?
UC2: I have a set of capabilities set by the system
e.g. supported-reporting-intervals. I need to configure a job that
MUST use one of these intervals. If the supported-reporting-intervals
are only added to <operational> I can not validate the
selected-interval in my configured job.
My proposal is to allow the system to add data to running as
well. Actually I think that is a more relevant case then adding
configuration just to <operation>.
I think the consensus is that in general it is a bad idea if servers
(spontaneously) add data to <running>. However, there is nothing in
the new or old architectures that prohibits this.
BALAZS: I strongly disagree. I know others are also adding stuff to
running as well.
IMHO the above use cases are real and used and actually important for
us.
I would like to see them included in some way.
I basically agree with Martin here.
The architecture is cleaner if <running> is only written by the
client. This avoid requiring clients tracking unexpected changes to
running, and opens up the possibility of validating configuration off
the box. Ideally extra stuff should be added into <intended> and then
become visible in <operational>.
I understand that some systems add data to <running>, and this is
fine. But I think that it is better for an architecture document to
be silent on this point.
Thanks,
Rob
regards Balazs
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email:[email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
