> 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?
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
