Comment 2
And this:
Jeff:
Do you consider the question from Ken's original post below to be answered?
<snip>
<Ken's text>
"In contrast, although multiple I2RS clients may need to
supply data into the same list (e.g. a prefix or filter
list), this is not considered an error and must be
correctly handled. The nuances so that writers do not
normally collide should be handled in the information
models."
Do you mean data model? Can you provide an example for how
this can be handled in an info/data model? - are lists
expected to be sorted-by-system to prevent shadowing
This a logical description and not a model description.
</ken text>
</snip>
----------
Sue
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Jeffrey Haas
Sent: Friday, May 02, 2014 11:41 AM
To: Andy Bierman
Cc: Jeffrey Haas; [email protected]; t.petch
Subject: Re: [i2rs] edit-data substatement Re: Operational State
On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
> I picture the operational state as the mixing bowl for the 2 config
> sources and data learned from protocols and system events. It seems
> both NETCONF and I2RS would be able to pick the data is cares about
> out of that.
I think this is what I'd like to see personally.
> This is a weakness in YANG that may get improved in YANG 1.1.
> Since it is officially just for NETCONF, there are no mechanisms
> (other than vendor extensions) to tag the data as specific to some
> subset of protocols.
As I mentioned elsewhere, I'm hoping we don't go down the path of "editable
operational state", instead configuration semantics for our purposes.
> > I think that we will, that is the set of YANG leafs etc that I2RS
> > will want to edit and the sets of leafs that I2RS will want to get
> > in a straightforward manne will not be the same (eg the latter will
> > include read-only statistics and 'config true'). And yes, it could
> > all be done with filters, which could be a nightmare.
> >
> >
> Examples of read-only data that only I2RS would want to get would help.
I believe that it would largely overlap config false state desired for
normal module purposes in many cases. For example, interface statistics
would likely be part of the standard interface module. Where things get
interesting are specific augmentations that tie different information
domains together - interface stats correlated against routing, for example.
(For prefix X, traffic is seen - similar to IPFIX exports.)
-- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
