Ladislav Lhotka <[email protected]> wrote:
>
> > On 09 Dec 2015, at 12:52, Martin Bjorklund <[email protected]> wrote:
> >
> > Hi,
> >
> > It seems we will not reach full agreement on some of the remaining
> > issues in 6020bis. Re-opening Y26 is one of them. I don't think this
> > is a good idea, but I realize that the consensus is to relax the "MUST
> > NOT augment mandatory nodes" rule.
> >
> > Here is my proposal for new text. Most of this text is copied from
> > 6087bis, so if we add this to 6020bis, 6087bis should probably be
> > updated as well.
>
> I'd prefer to keep it simple, e.g. as in Rob's proposal:
>
> https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU
I don't want to refer to 6087bis here. Note that 6087bis is
Informational. So I basically copied the text from 6087bis.
> Your text is rather complicated to understand but
>
> 1. added nodes can be made mandatory using a "must" statement, to
> the same effect.
Yes, and we won't do anything about that. This isn't handled by Robs
text / the reference in 6087bis.
> 2. there may be other "safe augments", for example via if-feature,
No, if-feature is NOT safe. See Andy's text in 6087bis.
> or when augmenting a choice.
Sure, but this already works in YANG 1.0, since it technically doesn't
add any mandatory nodes.
/martin
>
> Lada
>
> >
> > This new subsection would go into 7.17 The augment Statement.
> >
> >
> > *** Augmenting Conditionally Mandatory Nodes
> >
> > If the target node is in another module, then nodes added by the
> > augmentation MUST NOT be mandatory nodes (see ^terminology^), except
> > as described below. The reason for this is that clients that do not
> > know about the augmenting module should contiune to work.
> >
> > It is possible to add conditional augment statements such that an old
> > client would not know about the new condition, and would not specify
> > the new condition. The conditional augment statement can contain
> > mandatory nodes only if the condition is false unless explicitly
> > requested by the client.
> >
> > If the augmentation adds mandatory nodes to a target node in another
> > module, the augmentation MUST be conditional with a "when" statement.
> > Care must be taken when defining the "when" expression, so that
> > clients that do not know about the augmenting module do not break.
> >
> > **** Usage Example
> >
> > In the following example, it is OK to augment the "interface" entry
> > with "mandatory-leaf" because the augmentation depends on support for
> > "some-new-iftype". The old client does not know about this type so it
> > would never select this type, and therefore not be adding a mandatory
> > data node.
> >
> > module example-augment {
> > namespace "urn:example:augment";
> > prefix mymod;
> >
> > import ietf-interfaces {
> > prefix if;
> > }
> >
> > identity some-new-iftype {
> > base if:interface-type;
> > }
> >
> > augment "/if:interfaces/if:interface" {
> > when "if:type = 'mymod:some-new-iftype'";
> >
> > leaf mandatory-leaf {
> > mandatory true;
> > type string;
> > }
> > }
> > }
> >
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
