Juergen Schoenwaelder <[email protected]> wrote:
> 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?
I think "MUST NOT ... except" is correct. I also searched existing
RFCs for this construct, and found quite a few.
/martin
>
> /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
