Robert:
Yes, I am planning to update this to reflect revised-datastores-01.txt.
You updated on 3/13 (smile) - it was hard to anticipate all your changes
(smile).First of I2RS WG will suggest changes, and NETMOD will insert
these in appropriate documents. All my comments in this email should be
based on that point.
Second - I think we can break the documents suggestion into two separate
categories:
a) what is needed to support datastores and control plane datastores
b) what is needed for ephemeral modules in datastores, and ephemeral
datastores.
AFAIK - I2RS is just the first WG to define requirements for a+b. This
draft is trying to give examples of what is needed. Pros/Cons of different
ways can be debated by people who are implementing this work.
IMO - most of what I proposed is datastore and control plane datastore
specific. I had proposed these as optional additions to YANG 1.1 for I2RS
support - because I had not read your revised datastores 1.1 which suggested
datastores should be a fully supported function (if I understood that
correctly).
1) datastore def - this list of datastore with a list of modules
If I understood Juergen's suggestions - he suggested something like this
mechanism on the list. He did not suggest the sub-statements:
1) dstype - where it defines the type of datastore
2) module list - for a list of modules
3) precedence - the precedence between this datastore and other datastores.
Datastores will need to sort out what gets applied. It is better to provide
YANG language to support this specification to aid interoperability.
4) protosup - What protocol can be used to support this
protobase - NETCONF (v1/v2), RESTCONF or other protocols (gPRC, CoAP)
protoadd - what capabilities (control-plane datastores, ephemeral) - we
may need to add non-secure transport here.
5) validation - rules for validating entries
if in the datastore, then validation rules are default for all modules. If
in module, defines default rules for modules. If in an object (submodule,
submodule, an action, a container, a grouping, a leaf, a leaf-list, a
list, or an rpc), it defines that rules within that context.
Suggested rules:
1) bulkcheck - for large routing updates. Let's try this first within an
rpc.
2) Caching: By default, I2RS clients only support 1 plane of glass for I2RS
modules. Caching allows more than 1 pane of glass cached, but update to
applied has 1 value.
I2RS Rules:
Validation: substatement
1) nstransport - transport can be non-secure - It is important to flag
portions of modules with this feature.
Ephemeral rules:
1) ephemeral true/false; - valid on all forms datastore, module, and objects
(submodule, submodule, an action, a container, a grouping, a leaf, a
leaf-list, a
list, or an rpc), it defines that rules within that context.
What is not there from ephemeral state:
Edit-collision prevention (aka priority, client-id)
Opaque secondary id.
Sue
-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: Tuesday, March 21, 2017 9:41 AM
To: Susan Hares; 'Russ White'; i2rs@ietf.org
Cc: akat...@gmail.com
Subject: Re: [i2rs] FW: New Version Notification for
draft-hares-netmod-i2rs-yang-04.txt
Hi Sue,
I've only had a very quick scan of the doc, and I think that you may be
planning to update this to reflect revised-datastores-1 anyway.
But I have one high level question/comment (that I think may equally apply
to the I2RS impact on NETCONF and RESTCONF):
Is I2RS planning on making changes/additions to the core of YANG to support
I2RS requirements? I.e. new YANG statements that would expect to be
supported by all YANG implementations.
Or, is I2RS planning on defining some I2RS specific extensions to YANG,
which would also include defining some new I2RS specific datastore(s), but
that would not change the core of the YANG language? E.g. rather than
adding a new "ephemeral" keyword to YANG, the I2RS extension would define
the "ephemeral" extension statement, which would then be annotated in I2RS
specific modules as "i2rs:ephemeral true".
I think that the latter approach would be much more preferable if that is
feasible.
Similar comments to NETCONF and RESTCONF may equally apply (I've not read
your drafts yet). I.e. if possible, it is probably better to define
optional I2RS specific extensions than attempt to bake I2RS support into the
NETCONF or RESTCONF protocols themselves.
Thanks,
Rob
On 11/03/2017 19:37, Susan Hares wrote:
> Russ:
>
> I request a time slot to present a yang syntax that would support I2RS
work.
>
> Sue Hares
>
>
>
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Saturday, March 11, 2017 2:41 PM
> To: amit.d...@ericsson.com; Amit Daas; Susan Hares
> Subject: New Version Notification for
> draft-hares-netmod-i2rs-yang-04.txt
&g
