> On 09 Dec 2015, at 15:28, Martin Bjorklund <[email protected]> wrote:
>
> 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.
OK, right. In this case I would simply change "MUST NOT" to "SHOULD NOT".
>
>> 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.
Sure, I just don't understand why it is so critical to bother with "mandatory
true" if another door for achieving the same is wide open.
I believe your main concern (and mine as well) is that rogue vendors may try to
create silos by augmenting standard modules with mandatory proprietary stuff.
This is a real danger but we can't avoid it anyway.
>
>> 2. there may be other "safe augments", for example via if-feature,
>
> No, if-feature is NOT safe. See Andy's text in 6087bis.
Hmm, section 11 permits a module to be updated with mandatory nodes "if they
are conditionally dependent on a new feature". Why is the augment case
different?
>
>> or when augmenting a choice.
>
> Sure, but this already works in YANG 1.0, since it technically doesn't
> add any mandatory nodes.
module A:
choice foo {
...
}
module B:
augment "A:/foo" {
container top {
leaf bar { type empty; }
leaf baz { mandatory true; type empty; }
}
}
IMO this is also perfectly safe yet not allowed by your wording.
Lada
>
>
> /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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
