Hi,

I don't think I2RS is slowing down YANG 1.1.
The ephemeral state issue has been known to the NETMOD WG
for over a year.  I don't care if YANG 1.1 is delayed a month because
the solution details need to be worked out.

An ephemeral datastore would be useful for describing the collection of
YANG data nodes that share the ephemeral property.
A YANG statement is needed so ephemeral only data can
have its own validation rules.  I strongly object to using
extensions because they are not part of YANG.  They
cannot be used properly in refine-stmt or deviate-stmt.
They can be ignored by YANG tools.
Extensions are fine for proprietary usage, but not standards.





On Thu, Jul 30, 2015 at 11:19 AM, Martin Bjorklund <m...@tail-f.com> wrote:

> Andy Bierman <a...@yumaworks.com> wrote:
> > On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund <m...@tail-f.com>
> wrote:
> >
> > > Andy Bierman <a...@yumaworks.com> wrote:
> > > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <m...@tail-f.com>
> > > wrote:
> > > >
> > > > > Andy Bierman <a...@yumaworks.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I understand the intent is that an implementation of NACM
> > > > > > has to understand these NACM extensions.  I agree with Lada
> > > > > > that the YANG text about MAY ignore extensions casts doubt
> whether
> > > > > > this sort of NACM rule is enforceable or specified correctly.
> > > > >
> > > > > So do you agree that it would be a good idea to clarify this
> > > > > according to Juergen's suggestion?
> > > > >
> > > > >
> > > > >
> > > > Not really.
> > > > Pretending the extension is just another description-stmt
> > > > does not really fix anything.
> > > >
> > > > A real YANG statement like config-stmt or a new statement
> > > > called ephemeral-stmt can be modified with refine-stmt
> > > > or deviate-stmt.   This can never happen for
> > > > an external statement.
> > >
> > > There are two separate issues here:
> > >
> > > 1) It seems we are in agreement that if a model uses an extension
> > >    statement, it is normative (like ietf-system's usage of nacm:*).
> > >
> > >    Should we somehow clarify this in 6020bis?
> > >
> > >
> > No -- I agree that was the intent, but it is not achievable
> > because tools MAY ignore extensions.
>
> But as have been said several times, this was clearly not the
> intention.  So we should clarify this in 6020bis.
>
> > > 2) Extensions cannot be refined or deviated.
> > >
> > >    Actually, the *syntax* rules allows things like:
> > >
> > >      deviation /x:foo {
> > >        deviate replace {
> > >          i2rs:ephemeral true;
> > >        }
> > >      }
> > >
> > >    I agree that it not clear what this means, but we could also
> > >    clarify this in 6020bis.
> > >
> > >
> > > > IMO ephemeral data support needs to be a real statement
> > > > that can be used with refine-stmt and  deviate-stmt.
> > > > It is a real property of a data node.
> > >
> > > Note: it is still not clear that such a statement (base or extension)
> > > is needed at all.
> > >
> > >
> >
> > I do not understand why you are so opposed to using real YANG statements
> > to support ephemeral state.
>
> If this solution was already well defined and agreed upon by everyone,
> then it could be done as a YANG statement.  But I am worried that
> adding this will take quite some time, and will thus delay YANG 1.1;
> and since IMO extensions can be used just as well, there is no real
> reason for adding this delay.
>
> > Do you have a better solution that the
> > proposal from draft-haas-i2rs-ephermal-state-reqs-00?
>
> Use a separate ephemeral datastore.
>
> > I don't see it.
> > I am opposed to using extensions to ephemeral state because
> > they are poorly defined in YANG.
>
> Then we should fix this.
>
>
> /martin
>
> > This is OK since they are for
> > defining statements outside the YANG standard.  Normal mechanisms
> > like uses/refine and deviate must be supported.
> >
> > I do see any advantages whatsoever for using external statements
> > instead of YANG statements.
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to