On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> > > On 31 Jul 2015, at 14:40, Andy Bierman <a...@yumaworks.com> wrote: > > > > > > > > On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > > Martin Bjorklund <m...@tail-f.com> writes: > > > > > 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. > > > > +1 > > > > > > So you are saying that a tool MAY ignore any extension, except > > inside a deviation-stmt? Then it becomes mandatory to support? > > > > Or do you mean: > > > > Yes you can put extension-stmts anywhere, but also, yes the tool > > MAY ignore every single extension (everywhere, including inside a > > deviation-stmt) > > I understood Martin’s proposal so that a device that doesn’t support an > extension used in modules it advertises will have to put it in a > “not-supported” deviation. > > So features are all "not-supported" by default. but extensions, which a tool MAY ignore, are all supported by default? A server would be required to identify and remember all extensions used? And what about nested extensions: acme:foo test1 { acme:foo2 test2; } The server would be required to completely parse all extensions, and not skip over them? Just to list them as deviations? I think extensions should be like features and the server should advertise them if they are supported. I don't agree that "external-stmt" should be under YANG conformance at all. That is why MAY skip over is in the text. A tool that understands the extension is purely optional. Lada > > Andy > > > > > > > > Lada > > > > Andy > > > > > > > > > > /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 > > >> > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod