Hi Carl,
On 15/10/2015 14:05, Carl Moberg (camoberg) wrote:
Maybe we’re coming down to a definition of “requirement” here. But the issue
I raised can be summarized as follows:
“””
The assumption of a 1:1 mapping ignores situations where a change to an
intended configuration leaf value may result in several instances of applied
configuration leaf values (operational state) to be updated in the backend
framework across several subsystems.
“”"
My issue is that the requirement seems to ignore the situations and my
suggestion is to relax the requirement.
I think that the operator requirement is stating that the multiple
actual applied configuration leaves across multiple subsystems need to
be mapped back to a single logical leaf for the purposes of the applied
config leaf that is exposed to the operators.
If no such mapping is possible then this would imply that there is no
way that the operator can determine whether a particular item of
configuration is actually in effect on a system. Is this reasonable
behaviour for a system?
If such a mapping is possible, then I can see benefit in performing such
a mapping on the device itself rather than requiring each and every
operator to know and program the mapping. Is the main concern here that
the cost of implementing this mapping in the system may be prohibitively
expensive?
Thanks,
Rob
I don’t believe 1.C addresses the actual concern with the requirement.
On Oct 14, 2015, at 8:14 PM, Kent Watsen <kwat...@juniper.net> wrote:
I believe that you are correct, it seems that we've doubled-down on 1C and so
#5 should now be marked as DEAD.
This action will be taken if no objection is made before tomorrow's interim.
Thanks,
Kent
From: Robert Wilton <rwil...@cisco.com>
Date: Tuesday, October 13, 2015 at 9:29 AM
To: Kent Watsen <kwat...@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of
intended configuration is not the same as applied
From the interim meeting two weeks ago, it was clarified that the schema of
the intended configuration nodes are expected to be the same as the schema of
the applied configuration nodes so that clients can easily relate between the
two.
I think that the requirement text for 1.C and the proposed updated text for 1.D
makes this reasonable clear.
Hence, is issue 5 now at the state where is can be closed as not being a
requirement? Or is there something further that needs to be discussed first?
Thanks,
Rob
On 30/09/2015 16:44, Kent Watsen wrote:
It's time to tackle another issue, just before tomorrow's meeting, and this
time I'm picking a hard one:
https://github.com/netmod-wg/opstate-reqs/issues/5
Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the GitHub
issue tracker. Please first read the comments posted there and then continue
the discussion here on the mailing list (not on the GitHub issue tracker).
Note that this issue is closely tied to the definition of "applied
configuration", which is exactly what issue #4 regards
(https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh and Einar have
posted comments on already. As these two issues (#4 and #5) are so highly related, I'm
going to simultaneously open the other issue for discussion now as well.
Thanks,
Kent
_______________________________________________
netmod mailing list
netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
