Subject: [netmod] YANG 1.1 Default for Mandatory Statement

From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]>
Date: Wed, 7 May 2014 06:48:48 +0000

Issue:

There can be containers which contain a set of fields which are all mandatory, and currently each leaf needs to be individually tagged as mandatory. For readability, it would be good to be able to indicate that everything within a subtree is mandatory.

This can be useful in two scenarios: Firstly when multiple leaves make up a single logical "block" of data (as close as it gets to a complex type); and secondly when a container (in particular in operational data) has a large number of leaves, all of which are mandatory.

Example:

grouping lacp-system-id-group {

  container lacp-system-id {

    presence;

    leaf id  { type uint16; mandatory true; }

    leaf mac { type yang:mac-address; mandatory true; }

  }

}

Solution:

Enable the "mandatory" keyword under lists, containers, and case statements. In this usage, the keyword would apply to all contained leaves.

(This is effectively a parallel of how the "config" statement works as described in RFC 6020.)

container lacp-system-id {

  presence;

  mandatory true;

  leaf id  { type uint16; }

  leaf mac { type yang:mac-address; }

}

Alternative solution:

Add a new "default-mandatory" keyword  that's supported under lists, containers and case-statements, with values "true" and "false", which sets the default state of the mandatory keyword for elements contained. (This avoids overloading the keyword, but

container lacp-system-id {

  presence;

  default-mandatory true;

  leaf id  { type uint16; }

  leaf mac { type yang:mac-address; }

}

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 May 2014 09:27:31 +0200 (CEST)

Hi,

Added as Y52.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 May 2014 09:40:39 +0200 (CEST)

Hi,

> There can be containers which contain a set of fields which are all
> mandatory, and currently each leaf needs to be individually tagged
> as mandatory. For readability, it would be good to be able to
> indicate that everything within a subtree is mandatory.

Readability is always subjective.  Personally, I think it is more
clear to have the explicit mandatory statement in each subnode.

Also, I think is confusing to let the 'mandatory' statement be applied
recursively in some cases (these new cases), but not in others
(existing mandatory in choice).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 7 May 2014 10:26:05 +0200

> (existing mandatory in choice).

+1

Another complication would be augments that may add new nodes to the subtree from outside.

Lada

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

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

---

From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]>
Date: Wed, 7 May 2014 12:57:25 +0000

> -----Original Message-----
> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: 07 May 2014 09:26
> To: Martin Björklund
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netmod] Y52: Default for Mandatory Statement
> 
> 

Sure, perhaps readability was the wrong word. To put it another way:
What's being suggested is that in some cases, "it is expected that
elements in this container are mandatory" might be  "this leaf is
mandatory". (And it would make the model less verbose.) Though I expect
it's still subjective ;-)

In particular, is it fair to say that the usage of the "config" statement
on non-presence containers has equivalent behavior/use cases? (i.e. The
alternative would be that instead of putting the "config" statement on a
non-presence container it should be specified for each subnode.)

> > (existing mandatory in choice).

Fair point; so the alternative suggestion of using "mandatory-default"
instead to set the default sense for subnodes would be clearer.

> Another complication would be augments that may add new nodes to the subtree

Sure; I would expect augmenting within a subtree that defaults to true
would not be a mainline use case, but it does need considering. If we use
"mandataory-default" to set the default sense for the mandatory keyword
(i.e the "alternative solution"), does that help?

Cheers,
Peyman