On Wed, Dec 09, 2015 at 12:52:01PM +0100, Martin Bjorklund 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.
>
> 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.
Replace
MUST NOT be mandatory nodes (see ^terminology^), except as described below.
with
SHOULD NOT be mandatory nodes (see ^terminology^).
to avoid the 'MUST NOT ... except' logic?
/js
> 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
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod