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?
> >
> > 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.
> >
> >
> 
> But this will take even longer than just defining the statements that
> are needed for ephemeral state, so no point in doing that.
> 
> The text in  7.18.3.2 clearly does not support the example above at all.

The grammar allows extensions everywhere, so the example is (as I
wrote) syntactically valid.

> Only one of the keywords listed in the table are supported.

The text doesn't say so, and anyway my point was that - regardless of
the outcome of the ephemeral dicussion - it might be a good a idea to
clarify that extensions can be deviated as well.

/martin

> 
> 
>    The substatement's keyword MUST match a corresponding
>    keyword in the target node, and the argument's string MUST be equal
>    to the corresponding keyword's argument string in the target node.
> 
>                        The deviates's Substatements
> 
>                  +--------------+---------+-------------+
>                  | substatement | section | cardinality |
>                  +--------------+---------+-------------+
>                  | config       | 7.19.1  | 0..1        |
>                  | default      | 7.6.4   | 0..1        |
>                  | mandatory    | 7.6.5   | 0..1        |
>                  | max-elements | 7.7.4   | 0..1        |
>                  | min-elements | 7.7.3   | 0..1        |
>                  | must         | 7.5.3   | 0..n        |
>                  | type         | 7.4     | 0..1        |
>                  | unique       | 7.8.3   | 0..n        |
>                  | units        | 7.3.3   | 0..1        |
>                  +--------------+---------+-------------+
> 
> 
> 
> 
> > > 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.
> >
> >
> 
> Maybe not to you, but according to the I2RS ephemeral requirements,
> it is needed, so unless you have a better plan, this is the default.
> 
> Explain how ephemeral state can be identified within a data node.
> It must be possible to use groupings to define such data nodes.
> If must be possible to refine these groupings.
> It must be possible for a vendor to write deviation statements.
> All YANG tools must recognize the ephemeral data property.
> It should not be isolated to a particular YANG module, which would
> create a dependency in all future YANG modules.
> 
> 
> Andy
> 
> 
> 
> 
> 
> >
> > /martin
> >

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to