Subject: [netmod] mandatory augmenting nodes

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 07 May 2010 12:44:07 +0200

Hi,

YANG draft says in section 7.15:

   If the target node is in another module, then nodes added by the
   augmentation MUST NOT be mandatory nodes (see Section 3.1).

Why is this CLR necessary?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Fri, 7 May 2010 09:50:05 -0400

>Why is this CLR necessary?

So keep from breaking the contract of the original module.  If
module B augments A with a mandatory leaf, then only B-speaking
clients can talk to servers that implement B, since a A-only
client will not provide the mandatory node and will fail.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 08 May 2010 09:32:53 +0200

> client will not provide the mandatory node and will fail.

The server advertizes both A and B and this is now the new contract. The
client cannot simply ignore B, that would be error-prone. For example,
the augmented nodes may contain some 'must' constraints addressing nodes
in module A which the client has to observe, otherwise the A-only
configuration would be invalid. Also, what if the server's initial
configuration contains nodes added by B?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 8 May 2010 09:54:06 +0200

On Sat, May 08, 2010 at 09:32:53AM +0200, Ladislav Lhotka wrote:
> Phil Shafer p????e v P?? 07. 05. 2010 v 09:50 -0400:
> > Ladislav Lhotka writes:
> > >Hi,
> > >

Lada, we would fundamentally change the semantics of advertisements if
they would require that a client has to understand _all_ advertised
modules. This is flawed idea since vendors will have vendor specific
extensions to standard modules and thus we would require that every
client understands all vendor specific extensions.

Hence, a data model design that contraints other definitions such that
they do not work anymore in isolation is broken. And yes, with must
expressions, you can do lots of harm if you are not extremely careful.
They are a very sharp and thus potentially dangerous tool.

/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: Ladislav Lhotka <[email-masked]>
Date: Sat, 08 May 2010 10:40:29 +0200

> client understands all vendor specific extensions.

Hmm, so what happens if such a client receives a configuration
containing nodes it doesn't know about? Is it supposed to ignore them or
keep them unchanged? This seems very tricky and may open security holes.
IMO both parties should work with an identical schema.

> They are a very sharp and thus potentially dangerous tool.

Very true. That's probably why asserts proposed for XML Schema 1.1,
which are a direct analogy to YANG's 'must', may only address the
subtree of the node where they appear.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 8 May 2010 10:45:14 +0200

On Sat, May 08, 2010 at 10:40:29AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v So 08. 05. 2010 v 09:54 +0200:

You must be dreaming.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 08 May 2010 11:46:17 +0200

> > IMO both parties should work with an identical schema.

The situation where the server uses some vendor-specific extensions that
the client has no idea about is essentially just a special form of
deviation, with all the consequences. I don't believe, dreaming or not,
that this can ever work.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 8 May 2010 11:57:44 +0200

> deviation, with all the consequences. I don't believe, dreaming or not,

It is only a deviation if the extension changes the semantics of the
module the client knows about. And this is why augmenting mandatory
nodes is not allowed.

If you assume that every client needs to be aware of all modules
announced by a server, than that is just completely unrealistic,
unless the client is shipped by whoever shipped the server. If we are
talking about open standards, then assuming every client understands
all modules announced by all servers does not seem to reflect my
reality when I look at my heterogenous zoo of network devices.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 08 May 2010 13:01:47 +0200

> module the client knows about. And this is why augmenting mandatory

The extensions can change the semantics in many different ways. After
the recent fuss concerning deviations, consider the following example:

A standard module defines something this:

module standard {
  ...
  prefix std;

  container outer {
    leaf crucial {
      mandatory true;
      ...
    }
    ...
  }

Now, vendor Foo, Ltd. decides they don't like the "crucial" leaf.

They can do either

module foo {
  ...
  deviation "/std:outer/std:crucial" {
    deviate not-supported;
  }
  ...
}

or (if, say, deviations were banned) 

module foo {
  ...
  augment "/std:outer" {
    leaf ignore-crucial {
      description 'If true, completely ignore the "crucial" leaf.' 
      type boolean;
      default true;
  }
  ...
}

Semantically, both versions are the same for the server, so why the
deviation is bad and the augment isn't?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 8 May 2010 14:18:10 +0200

> deviation is bad and the augment isn't?

I never said deviations are bad.

/js