Subject: [netmod] new text for Y26

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Dec 2015 12:52:01 +0100 (CET)

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.

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 9 Dec 2015 15:16:57 +0100

> On 09 Dec 2015, at 12:52, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

I'd prefer to keep it simple, e.g. as in Rob's proposal:

https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU

Your text is rather complicated to understand but

1. added nodes can be made mandatory using a "must" statement, to the same effect.

2. there may be other "safe augments", for example via if-feature, or when augmenting a choice.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Dec 2015 15:28:34 +0100 (CET)

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

> 1. added nodes can be made mandatory using a "must" statement, to

Yes, and we won't do anything about that.  This isn't handled by Robs
text / the reference in 6087bis.

> 2. there may be other "safe augments", for example via if-feature,

No, if-feature is NOT safe.  See Andy's text in 6087bis.

> or when augmenting a choice.

Sure, but this already works in YANG 1.0, since it technically doesn't
add any mandatory nodes.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 9 Dec 2015 16:02:46 +0100

> On 09 Dec 2015, at 15:28, Martin Bjorklund <[email-masked]> wrote:
> 

OK, right. In this case I would simply change "MUST NOT" to "SHOULD NOT". 

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

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

> Sure, but this already works in YANG 1.0, since it technically doesn't

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Dec 2015 16:13:52 +0100 (CET)

> IMO this is also perfectly safe yet not allowed by your wording.

It is allowed even in YANG 1.

Note that there is a precise definition of "mandatory node", and note
that the augment really is:

  augment "A:/foo" {
    case top {
      container top {
        leaf bar { type empty; }

/martin

---

From: Robert Wilton <[email-masked]>
Date: Wed, 9 Dec 2015 15:24:03 +0000

Hi Lada,

Please see inline [RW] ...

> 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 avoi…
[RW]
Personally I think that there are two areas of concern.  The one that 
you have listed above, and also the module upgrade case.  E.g. a server 
has been upgraded to a new module version but a client is still coded to 
an older version.  The client should continue to have the same 
service/support available as they had previously even though they are 
not using the latest module version.

> 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?
[RW]
I would think that augmenting with if-feature can't be safe because it 
is only the server that chooses whether a feature is enabled, not the 
client.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 9 Dec 2015 15:30:39 +0000

Hi Martin,

> that the augment really is:
[RW]
Agreed, but I find the distinction to be a bit subtle.  I suspect that 
quite a lot of readers are likely to think that a mandatory node is any 
node with an associated "mandatory true" condition, and not make the 
mental leap to the above example being OK.

Hence I would suggest that we call out this case as being explicitly 
allowed either in 6020bis or perhaps more appropriately in 6087bis.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 9 Dec 2015 16:56:27 +0100

> On 09 Dec 2015, at 16:24, Robert Wilton <[email-masked]> wrote:
> 
> Hi Lada,
> 
> Personally I think that there are two areas of concern.  The one that you have listed above, and also the module upgrade case.  E.g. a server has been upgraded to a new module version but a client is still coded to an older version.  The client should continue to have the same service/support available as they had previously even though they are not using the latest module version.

The service will be different anyway because the server may send the client unknown data installed by another client that happens to be new. I wonder how many client implementations are resilient to such schema violations. A situation where the server and client work with different data models is IMO extremely problematic and we can't pretend that some CLRs make it safe.

My favorite example is this *non-mandatory* node:

leaf launch-missiles {
  type boolean;
  default true;
}

If an old client isn't aware of this leaf, it won't encounter any syntactic problems but is it still the same service/support?

> I would think that augmenting with if-feature can't be safe because it is only the server that chooses whether a feature is enabled, not the client.

Sure, but the same happens if the server advertises a new revision of a module along with a feature that's defined in that new revision.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Wed, 9 Dec 2015 16:41:16 +0000

Hi Lada,

On 09/12/2015 15:56, Ladislav Lhotka wrote:
> The service will be different anyway because the server may send the client unknown data installed by another client that happens to be new. I wonder how many client implementations are resilient to such schema violations.
I would think that in a tightly constrained environment (e.g. an ISP 
that is controlling all the network mgmt clients and network device 
implementations/versions) might just have specific schemas defined and 
supported on the clients.

But I can also quite easily imagine other off the shelf clients that 
have been written to be more flexible.  I.e. they will handle the 
specific nodes that they are interested in but otherwise ignore other 
unknown nodes that may be due to vendor specific augmentations or future 
version upgrades.

>   A situation where the server and client work with different data models is IMO extremely problematic and we can't pretend that some CLRs make it safe.
>
OK, I'm not actually convinced this specific example is a problem, if 
launching missiles is the correct/normal default behaviour for the new 
version of the YANG module!

But I agree with you that this isn't necessarily exactly the same 
service/support.  Perhaps a better way that I could have express this 
would be along the lines of: "The existing nodes used by an old client 
should still provide a consistent service inline with the documented 
description of the older version of the YANG module". I.e. a updated 
module should be allowed to provide new optional functionality which may 
also include appropriate defaults, but it shouldn't be changing the 
semantics of the existing functionality specified in the older version 
(excluding bug fixes).

But I do get your general point that the YANG language can't really 
prevent someone from doing something silly or naughty when either 
augmenting or upgrading a module, and I also agree with you that there 
is a limit to how much we should be trying to prevent this. For me, the 
compromise is that we should try and make it hard to have accidental 
violations, but not try overly hard to prevent the wilful violations.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 9 Dec 2015 18:45:54 +0100

> On 09 Dec 2015, at 17:41, Robert Wilton <[email-masked]> wrote:
> 
> Hi Lada,
> 
> I would think that in a tightly constrained environment (e.g. an ISP that is controlling all the network mgmt clients and network device implementations/versions) might just have specific schemas defined and supported on the clients.
> 
> But I can also quite easily imagine other off the shelf clients that have been written to be more flexible. I.e. they will handle the specific nodes that they are interested in but otherwise ignore other unknown nodes that may be due to vendor specific augmentations or future version upgrades.
> 
> OK, I'm not actually convinced this specific example is a problem, if launching missiles is the correct/normal default behaviour for the new version of the YANG module!
> 
> But I agree with you that this isn't necessarily exactly the same service/support.  Perhaps a better way that I could have express this would be along the lines of: "The existing nodes used by an old client should still provide a consistent service inline with the documented description of the older version of the YANG module". I.e. a updated module should be allowed to provide new optional functionality which may also include appropriate defaults, but it shouldn't be changing the semantics of the existing functionality specified in the older version (excluding bug fixes).
> 
> But I do get your general point that the YANG language can't really prevent someone from doing something silly or naughty when either augmenting or upgrading a module, and I also agree with you that there is a limit to how much we should be trying to prevent this. For me, the compromise is that we should try and make it hard to have accidental violations, but not try overly hard to prevent the wilful violations.

Yes, exactly! I do agree it is useful to be able to upgrade a network gradually without breaking management tools but it's IMO a matter of data-modelling discipline and careful planning. So everybody should read 6087bis to be aware of the potential problems for backward compatibility, but cluttering the specification of a data modelling language with convoluted CLRs in order to prevent incompatible updates of the data model is IMO wrong.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Dec 2015 15:59:00 +0100

> 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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Dec 2015 16:14:43 +0100 (CET)

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Dec 2015 16:20:35 +0100

> On 14 Dec 2015, at 16:14, Martin Bjorklund <[email-masked]> wrote:
> 

Hmm, but the latest revision rfc6020bis has a different text without this "MUST NOT ... except" logic. Am I missing something?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Dec 2015 16:25:40 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 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