Re: [I2rs-proto-dt] I2RS meeting

Hi,

I have some new questions about I2RS.

1) save client-id or client-id and priority?
Jan was concerned about saving state for every node.
If there is only 1 client and 1 priority then there is nothing to save.
For multi-head agents they will need to save the client-id.
The priority is configured for the client. It if changes the
priority of all the client's data automatically changes.
If this is not acceptable, then the priority and the client have to
be saved per node.

2) edit boundaries are not remembered
Each edit by each client will just go into the ephemeral datastore.
Identification of individual edits is not remembered.
Therefore the data that gets bumped by a high-priority overlap
is deleted based only on the overlap, not the original edit.

3) because of (2) there might be client interactions that break things.
e.g...
   client-worst sets entire /foo/bar subtree and it is accepted and
activated
   client-best later sets some subtree inside /foo/bar and the old subtree
is deleted
   and replaced with the data from client-best.  At this point the overall
   config may be invalid. The agent needs to do lots of expensive validation
   and may need to remove even more data from client-worst.
   Whether arbitrary pruning is done or not, the config may be operationally
   invalid at this point. Maybe this is no different than clashing clients
in persistent config,
  and can be considered out of scope.

Andy

On Sun, Nov 1, 2015 at 1:32 PM, Dean Bogdanovic <ivandean@gmail.com> wrote:

> I support Andy's comments
>
> On Nov 2, 2015, at 06:04, Susan Hares <shares@ndzh.com> wrote:
>
> Andy:
>
>
>
> I really appreciate this email.   Please comment remotely or skype me
> (Susan.Hares) or send a note to the jabber scribe.
>
>
>
> How is your dog?
>
>
>
> Sue
>
>
>
> *From:* I2rs-proto-dt [mailto:i2rs-proto-dt-bounces@ietf.org
> <i2rs-proto-dt-bounces@ietf.org>] *On Behalf Of *Andy Bierman
> *Sent:* Sunday, November 01, 2015 3:36 PM
> *To:* Susan Hares; i2rs-proto-dt@ietf.org
> *Subject:* [I2rs-proto-dt] I2RS meeting
>
>
>
> Hi,
>
>
>
> I plan to listen in to the I2RS meeting.
>
> It's probably too late for a conf-call before the meeting,
>
> but I am available.
>
>
>
> I think it is OK to say the YANG constraints apply to
>
> the derived "intended config" and also apply
>
> to the running datastore as defined in YANG.
>
>
>
> That means if the max-entries is 5, then 5 can exist in
>
> the running config, and new entries added to ephemeral
>
> must override entries in running.  Retrieving the intended config
>
> actually used (e.g., which config entry is disabled) is
>
> a different issue.  The intended config can only have 5 entries
>
> in it.  It falls out that the ephemeral datastore can only
>
> have 5 entries in it as well.
>
>
>
> Not all YANG constraints are as easy as min-elements,
>
> and max-elements.
>
>
>
> mandatory, must, when, and unique need more careful thought
>
>
>
>
>
> Andy
>
>
>
> _______________________________________________
> I2rs-proto-dt mailing list
> I2rs-proto-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs-proto-dt
>
>