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