Re: [I2rs-proto-dt] Minutes for 10/2/2015 meeting

[Andy Bierman <[e-mail]>]

On Mon, Oct 5, 2015 at 1:46 PM, Jeffrey Haas <[e-mail]> wrote:

> On Fri, Oct 02, 2015 at 01:12:24PM -0400, Susan Hares wrote:
> > Please review the protocol strawman and send comments by Monday
> evening.  I
> > will send sending out on Monday evening:
>
> There's an awful lot of TBD in there.  But given the ephemeral piece is the
> critical and messy one, perhaps that's okay.
>
>

I am curious about bulk-read and bulk-write

IMO we just need 1 GET or 1 PUT type of method.
Using YANG Patch with RESTCONF, multiple edits can be done at once.



> I can tell from looking at the slides that I've missed some of the
> openconfig opstate discussions.  But from that, and prior context, it
> appears that the "actual" configuration is being classified as
> "operational"
> state and that the view that the devices receive comes from the logical
> merge operation on that view plus the view through the panes of glass.
>
>
I think the terms are "intended config" and "applied config".

It is important to decouple the produce (sensor) from the consumer (applied
config)
The sensor still puts out its operational value but the
system (directed by I2RS edits) uses the injected value
as the applied config instead of the sensor value.



> I sort of like the idea that a single client gets a single pane.  It
> simplifies things, but potentially makes things a bit ugly for scaling if
> you have too many clients.  This may be less of an issue if the models are
> guaranteed some level of disjointness between various panes with regard to
> their schemas.
>


It is really just an implementation detail, but if N clients map
to 1 priority (like the default priority if the client is not configured)
then the client ID needs to be saved to decide first-1-wins in
any future edit collisions.



> I'm a bit confused by the writeable config false ephemeral true node.  Do
> we
> really want to support that?
>


That is the most controversial part.

Are there YANG objects that are config=false used to model
the derived state?  Does that derived state ever need to
be altered by I2RS?   An alternative would be to have new YANG objects
that represent the I2RS-provided values.  But the config-stmt for
these nodes needs some value.  Clearly it is not true, since NETCONF
is not allowed to edit it.

Whether the derived state objects are edited directly,
or whether new objects that model the "I2RS-overrides"
are used, there still needs to be a way to indicate that
they are only editable in the ephemeral datastore.


   leaf desired-temp {
        type int32;
        config true;
        ephemeral true;
            units "degrees Celsius";
            description "The desired temperature";
            ephemeral true;
            }

     leaf actual-temp {
        type int32;
            config false;
            ephemeral false;
            units "degrees Celsius";
            description "The measured temperature";
            }

    leaf actual-temp-override {
        type int32;
            config false;
            ephemeral true;
            units "degrees Celsius";
            description "Override the actual temperature";
            }

With this design, the "plain" operational state objects are left as-is,
and clones or special overrides are in separate models.



> -- Jeff
>

Andy


>
> _______________________________________________
> I2rs-proto-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs-proto-dt
>