> 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 Your text is rather complicated to understand but 1. added nodes can be made mandatory using a "must" statement, to the same effect. 2. there may be other "safe augments", for example via if-feature, or when augmenting a choice. 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
