Ladislav Lhotka <[email protected]> wrote:
>
> > On 14 Dec 2015, at 16:14, Martin Bjorklund <[email protected]> wrote:
> >
> > 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.
>
> Hmm, but the latest revision rfc6020bis has a different text without
> this "MUST NOT ... except" logic. Am I missing something?
No you're right; sorry I was confused by Juergen's comment ;-)
The text in -09 is weaker than what I originally proposed, based on
the comments I received.
/martin
>
> Lada
>
> >
> >
> > /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
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
