In an attempt to try and close on some of the proposed requirement text
before Thursday's interim meeting.
Does anyone have any outstanding objections on using this proposed text
for Requirement 1.D, or is it sufficiently clear to update the draft,
and resolve issue 1?
OLD text for Requirement 1:
1. Ability to interact with both intended and applied configuration
A. The ability to ask the operational components of a system
(e.g., line cards) for the configuration that they are
currently using. This is the "applied configuration".
B. Applied configuration is read-only
C. The data model for the applied configuration is the same as
the data model for the intended configuration (same leaves)
D. For asynchronous systems, when fully synchronized, the data
in the applied configuration is the same as the data in the
intended configuration.
NEW text (as above, changing 1.D only):
1. Ability to interact with both intended and applied configuration
A. The ability to ask the operational components of a system
(e.g., line cards) for the configuration that they are
currently using. This is the "applied configuration".
B. Applied configuration is read-only
C. The data model for the applied configuration is the same as
the data model for the intended configuration (same leaves)
D. When the configuration change for any intended configuration
node has been successfully applied to the system (e.g. not
failed, nor deferred due to absent hardware) then the
existence and value of the corresponding applied
configuration node must match the intended configuration
node.
Thanks,
Rob
On 06/10/2015 21:54, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote:
Hi Juergen,
On 06/10/2015 17:01, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:
Hi Kent,
On 06/10/2015 01:40, Kent Watsen wrote:
This issue appears to have become more like issue #5 – should we mark
this one a duplicate of the other?
I suggest that we can just finalize on the text being discussed to
replace 1.D and then resolve issue #1.
Jason had proposed this text:
When the configuration change for any intended configuration node has
been successfully applied to the system (e.g. not failed, nor deferred
due to absent hardware) then the existence and value of the applied
equivalent of the node (whether that be a corresponding node in the data
model, an attribute associated with the intended config node, the
configuration node read from a different datastore or context, etc) must
match the intended configuration node.
I have no clue what "an attribute associated with the intended config
node" or "the configuration node read from a different datastore or
context" or "etc". means. What exactly is an "applied equivalent of
the node"?
Or perhaps this slightly briefer alternative is better?:
D. When the configuration change for any intended
configuration node has been successfully applied to the
system (e.g. not failed, nor deferred due to absent hardware)
then the existence and value of the corresponding, possibly
notional, applied configuration node must match the intended
configuration node.
What is the purpose of the phrase "possibly notional"?
There was a concern that my previous text, i.e. as above but without
"possibly notional", implied that applied configuration had to be
actually represented as real data nodes in a YANG schema, which would
disallow the solutions presented in draft-kwatsen-netmod-opstate-00 and
draft-wilton-netmod-intf-ext-yang-00.
On balance, my preference is to exclude the "possibly notional" phrase
if the text is sufficiently clear without it.
My understanding is that draft-kwatsen-netmod-opstate-00 proposes to
represent applied config as nodes in a different datastore, so there
is no need for 'possibly notational'. I do not understand why
draft-wilton-netmod-intf-ext-yang-00 is relevant here. Do you mean
draft-wilton-netmod-opstate-yang-00? I do have major concerns about
this particular proposal since it changes the YANG data encoding
fundamentally. There was another proposal to use attributes, which is
also not without problems but it is likely a bit less painful. But
again, it all depends on the final definition of what applied config
really is. So where is the latest version and how far are we with
agreeing on it?
Yet another way to look at this is to expose not the applied config in
addition to the intended config (I have been told configs can be
really large) but instead expose lets say a yang patch that says how
the applied config differs form the running config. Having to retrieve
two large configs just to diff them locally seems to a potentially
expensive exercise, in particular if the difference is often small. I
think Randy mentioned something like this before and no there is no
I-D. But even with this approach, the definition without "possibly
notational' would hold; you would just not expose the applied config
entirely but instead a patch that allows to calculate it.
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
