Subject: [netmod] YANG 1.1 ABNF for deviate-stmt

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Apr 2016 18:50:27 -0700

Hi,

The ABNF for "default" is wrong in the deviate-*-stmt (add, replace, delete)
Is says [default-stmt] but it should be *default-stmt

Is it intentional that the ABNF for deviate-delete-stmt leaves out
config, mandatory, max-elements, and min-elements?
I understand why "type" cannot be removed.

IMO the rest of the statements should be removable.
Sec. 7.20.3.2 does not mention the restrictions indicated in the ABNF.
This section should make it clear a leaf has only 1 default
and the 0..n refers to leaf-list only.

It should also be clear that the "deviate add default" for a leaf-list
is YANG statement order-dependent.

Not as obvious -- a config=false leaf-list can have duplicate default
values.
The deviate-stmt has no way to specify which 1 to delete or replace
if there are duplicates.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Apr 2016 10:50:21 +0200 (CEST)

> Is says [default-stmt] but it should be *default-stmt

Thanks, fixed.

But for deviate-replace, it is not clear what the correct answer is.

This is pretty clear:

  leaf foo {
    type int32;
    default 42;
  }

  deviation /foo {
    deviate replace {
      default 10;
    }
  }

But what about this:

  leaf-list bar {
    type int32;
    default 42;
    default 43;
  }

  deviation /bar {
    deviate replace {
      default 10;
      default 11;
    }
  }

Are all defaults changed?

Compare with must and unique - they can not be replaced currently.

In order to resolve this we probably need more text as well :(

OLD:

  The argument "replace" replaces properties of the target node.  The
  properties to replace are identified by substatements to the
  "deviate" statement.  The properties to replace MUST exist in the
  target node.

NEW:

  The argument "replace" replaces properties of the target node.  The
  properties to replace are identified by substatements to the
  "deviate" statement.  The properties to replace MUST exist in the
  target node.  If multiple properties exist in the target node, all
  of them are replaced with the new properties defined in the
  substatements to the deviate statement.

+ add an example to the section "Usage examples":

NEW:

  In this example, the original definition of a leaf list has two
  default values "42" and "43:

    leaf-list bar {
      type int32;
      default 42;
      default 43;
    }

  A server can change this to the values "10" and "11" instead:

    deviation /base:bar {
      deviate replace {
        default 10;
        default 11;
      }
    }

Also, change the grammar:

OLD:

deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep
                      (";" /
                       "{" stmtsep
                           ;; these stmts can appear in any order
                           [type-stmt]
                           [units-stmt]
                           [default-stmt]
                           [config-stmt]
                           [mandatory-stmt]
                           [min-elements-stmt]
                           [max-elements-stmt]
                       "}") stmtsep

NEW:

deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep
                      (";" /
                       "{" stmtsep
                           ;; these stmts can appear in any order
                           [type-stmt]
                           [units-stmt]
                           *must-stmt
                           *unique-stmt
                           *default-stmt
                           [config-stmt]
                           [mandatory-stmt]
                           [min-elements-stmt]
                           [max-elements-stmt]
                       "}") stmtsep

> I understand why "type" cannot be removed.

I don't really remember, but I can see that if you want to "delete"
min-elements you can replace it and set it to 0.

> and the 0..n refers to leaf-list only.

In general, the result after applying deviations must be valid - e.g.,
you cannot deviate "foo" as the default for an int32 leaf.

> The deviate-stmt has no way to specify which 1 to delete or replace

Unless replace will replace *all*, as suggested above.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Apr 2016 11:21:24 +0200

> On 19 Apr 2016, at 10:50, Martin Bjorklund <[email-masked]> wrote:
> 

Makes sense. However, Balazs asked previously about multiple deviations with the same target node:

https://www.ietf.org/mail-archive/web/netmod/current/msg14532.html

It seems there has been no resolution. In this case, if default values are replaced multiple times, which version will take effect?

Lada

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

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Apr 2016 08:35:41 -0700

On Tue, Apr 19, 2016 at 2:21 AM, Ladislav Lhotka <[email-masked]> wrote:

> '

The replace and delete variants all need to work the same.
They apply to all the default-stmts.

   leaf-list foo {
      type int32;
      default 10;
      default 20;
   }

> It seems there has been no resolution. In this case, if default values are
> replaced multiple times, which version will take effect?
>
>

This will be implementation-specific.

module  dev1:

   deviation /foo {
      deviate replace {
          default 30;
       }
   }

module  dev2:

   deviation /foo {
      deviate replace {
          default 40;
       }
   }

If first one wins or last one wins, then it depends on the order that
the deviations are loaded and processed by the parser.

Which version of /foo is really in use?

  leaf-list foo {
      type int32;
      default 30;
   }

  leaf-list foo {
      type int32;
      default 40;
   }

This follows the requirement that the statement be valid at the end,
but it is really broken wrt/ which deviation wins.  This applies to
many deviations, not just default.

There needs to be a rule that a deviation duplicates are not allowed.

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Apr 2016 08:27:05 +0200

> On 19 Apr 2016, at 17:35, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

I agree, although it is a bit awkward because it would be an inter-module rule.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Apr 2016 10:45:23 +0200 (CEST)

Hi Andy,

Are you ok with the proposed OLD/NEW changes?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Apr 2016 08:43:20 -0700

> Are you ok with the proposed OLD/NEW changes?
Yes, except the issue of multiple deviations (that could be in 1 module on
N modules).
The actual result depends on the order the deviations are applied.
This "last one wins" is implementation-dependent. Some text should be added
either to fix it or warn people.  (Note that the <hello> and YANG library
are not ordered so they cannot be used to inform the client which of
the N is actually applied.)  This also affects the order of "deviate add
default"
for leaf-list.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Apr 2016 17:46:57 +0200 (CEST)

> the N is actually applied.)  This also affects the order of "deviate add

I prefer some warning text.  In reality, I don't think is an issue.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Apr 2016 14:24:39 +0200

> I prefer some warning text.  In reality, I don't think is an issue.

Hopefully. It could become a problem if, for example, deviations are
bundled with other definitions.

Lada