Subject: [OPSAWG] Question on how to design a Yang model to reflect auto-asignment of a give leaf

From: Oscar González de Dios <[email-masked]>
Date: Tue, 11 Feb 2020 02:40:14 +0000

Dear OPSAWG and Netmod colleagues,

                During last IETF Opsawg meeting we raised a question (and there was some discussion during the meeting) that we have found yet no good answer and we would like to discuss it with operations and Yang experts.

                The use case is the following:  We have a yang module which holds certain optional leafs. The behaviors that we would like to have (and distinguish between them) are:

a)       The user does not provide the value and such value is auto-assigned by the system (a  device (if it is a device module) or a controller (if it is a network/service module)).

b)      The user does not provide a value and wants that such value IS NOT set by the system (as assigning a value has implications). That is, intentionally it is aimed at being left "empty" and should not be expanded. So, either the value is set or should remain empty

What is the best way to model this behavior? I see that some yang modules have added an "auto-assignment" leaf to express if auto-assignment is desired or not. (hence, auto-assignment false, and leaf not set, would  do not assign).

Which is the "default" rule for a leaf that is not set? It is that the system is free to create it (via template or any means of auto-assignment) or should leave it as is, that is, empty?

In NMDA, the system is allowed to expand a given configuration. This fact, in my personal view,  implies that by "default" any system could implement the "auto-assignment" behavior being compliant with Neconf/Restconf/NMDA rules (but I am not sure if the interpretation is correct).

Best Regards,

                Óscar

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 11 Feb 2020 09:29:07 -0000

Isn’t it possible to handle case b) by defining a value to have the meaning
“no value has been assigned” and then the user an explicitly set that value?

Adrian

From: netmod <[email-masked]> On Behalf Of Oscar González de Dios
Sent: 11 February 2020 02:40
To: [email-masked]; [email-masked]
Subject: [netmod] Question on how to design a Yang model to reflect
auto-asignment of a give leaf

                During last IETF Opsawg meeting we raised a question (and
there was some discussion during the meeting) that we have found yet no good
answer and we would like to discuss it with operations and Yang experts.

                The use case is the following:  We have a yang module which
holds certain optional leafs. The behaviors that we would like to have (and
distinguish between them) are:

a.	The user does not provide the value and such value is auto-assigned
by the system (a  device (if it is a device module) or a controller (if it
is a network/service module)). 
b.	The user does not provide a value and wants that such value IS NOT
set by the system (as assigning a value has implications). That is,
intentionally it is aimed at being left “empty” and should not be expanded.
So, either the value is set or should remain empty

What is the best way to model this behavior? I see that some yang modules
have added an “auto-assignment” leaf to express if auto-assignment is
desired or not. (hence, auto-assignment false, and leaf not set, would  do
not assign). 

Which is the “default” rule for a leaf that is not set? It is that the
system is free to create it (via template or any means of auto-assignment)
or should leave it as is, that is, empty? 

In NMDA, the system is allowed to expand a given configuration. This fact,
in my personal view,  implies that by “default” any system could implement
the “auto-assignment” behavior being compliant with Neconf/Restconf/NMDA
rules (but I am not sure if the interpretation is correct).

Best Regards,

                Óscar 

  _____  

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
puede contener información privilegiada o confidencial y es para uso
exclusivo de la persona o entidad de destino. Si no es usted. el
destinatario indicado, queda notificado de que la lectura, utilización,
divulgación y/o copia sin autorización puede estar prohibida en virtud de la
legislación vigente. Si ha recibido este mensaje por error, le rogamos que
nos lo comunique inmediatamente por esta misma vía y proceda a su
destrucción.

The information contained in this transmission is privileged and
confidential information intended only for the use of the individual or
entity named above. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this transmission in error, do not read it. Please immediately reply to the
sender that you have received this communication in error and then delete
it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
pode conter informação privilegiada ou confidencial e é para uso exclusivo
da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
indicado, fica notificado de que a leitura, utilização, divulgação e/ou
cópia sem autorização pode estar proibida em virtude da legislação vigente.
Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
imediatamente por esta mesma via e proceda a sua destruição

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Feb 2020 10:59:56 +0100 (CET)

Hi,

Oscar González de Dios <[email-masked]> wrote:
>                 there was some discussion during the meeting) that we have
>                 found yet no good answer and we would like to discuss it with
>                 operations and Yang experts.
> 
>                 holds certain optional leafs. The behaviors that we would like
>                 to have (and distinguish between them) are:
> 
> 
> a) The user does not provide the value and such value is auto-assigned
> by the system (a device (if it is a device module) or a controller (if
> it is a network/service module)).

I assume that this value not a static default value?

> b) The user does not provide a value and wants that such value IS NOT
> intentionally it is aimed at being left "empty" and should not be
> expanded. So, either the value is set or should remain empty

Do you mean that you want (a) and (b) at the same time for the same
leaf?

> What is the best way to model this behavior? I see that some yang
> modules have added an "auto-assignment" leaf to express if
> auto-assignment is desired or not. (hence, auto-assignment false, and
> leaf not set, would do not assign).
> 
> Which is the "default" rule for a leaf that is not set? It is that the
> system is free to create it (via template or any means of
> auto-assignment) or should leave it as is, that is, empty?
> 
> In NMDA, the system is allowed to expand a given configuration. This
> fact, in my personal view, implies that by "default" any system could
> implement the "auto-assignment" behavior being compliant with
> Neconf/Restconf/NMDA rules (but I am not sure if the interpretation is
> correct).

There are (at least) three ways to interpret "auto-assign".  The
client writes to running, and then the server auto-assigns X:

  (a) in running
  (b) in intended
  (c) in the operational state

(c) is uncontroversial and simple to implement in all servers, and
simple to understand.

(b) is allowed by NMDA but requires more of the server implementation;
specifically it requires the server to support that intended is
different from running.

(a) is not recommended in general; running should be fully owned by
the client(s) and not modified by the server.

/martin

> Este mensaje y sus adjuntos se dirigen exclusivamente a su
> destinatario, puede contener información privilegiada o confidencial y
> es para uso exclusivo de la persona o entidad de destino. Si no es
> usted. el destinatario indicado, queda notificado de que la lectura,
> utilización, divulgación y/o copia sin autorización puede estar
> prohibida en virtud de la legislación vigente. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por
> esta misma vía y proceda a su destrucción.
> 
> confidential information intended only for the use of the individual
> or entity named above. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly
> prohibited. If you have received this transmission in error, do not
> read it. Please immediately reply to the sender that you have received
> this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> senhoria o destinatário indicado, fica notificado de que a leitura,
> utilização, divulgação e/ou cópia sem autorização pode estar proibida
> em virtude da legislação vigente. Se recebeu esta mensagem por erro,
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> proceda a sua destruição

---

From: Oscar González de Dios <[email-masked]>
Date: Tue, 11 Feb 2020 18:05:51 +0000

-----Mensaje original-----
De: Martin Bjorklund <[email-masked]>
Enviado el: martes, 11 de febrero de 2020 11:00
Para: Oscar González de Dios <[email-masked]>
CC: [email-masked]; [email-masked]
Asunto: Re: [netmod] Question on how to design a Yang model to reflect auto-asignment of a give leaf

Hi,

[Oscar] True. Should the leaf have a default value, it implies that "if the value is not set, the default value is taken".

> expanded. So, either the value is set or should remain empty

Do you mean that you want (a) and (b) at the same time for the same leaf?

[Oscar] No. Depending on the leaf, we would like to specify behavior a or behavior b. Behavior a is ok for most of the cases.  The problem is that in some cases, assigning a value has way more implications and the service will not work properly. Those case are the ones we wanted to specifically tackle.

> Neconf/Restconf/NMDA rules (but I am not sure if the interpretation is

There are (at least) three ways to interpret "auto-assign".  The client writes to running, and then the server auto-assigns X:

  (a) in running
  (b) in intended

(c) is uncontroversial and simple to implement in all servers, and simple to understand.
[Oscar] agree

(b) is allowed by NMDA but requires more of the server implementation; specifically it requires the server to support that intended is different from running.
[Oscar] Agree . "Theoretically speaking" this is the behavior I would consider strictly follows NMDA guidelines. Reality is implementations are yet far from this...

(a) is not recommended in general; running should be fully owned by the client(s) and not modified by the server.
[Oscar] Agree.

[Oscar] So... what would be the best way to specify the behavior? Explicitly adding an auto-assign leaf to identify the behavior? Just "obey" NMDA rules?

/martin

> distribution or copying of this communication is strictly prohibited.
> If you have received this transmission in error, do not read it.
> Please immediately reply to the sender that you have received this
> communication in error and then delete it.
>

---

From: Oscar González de Dios <[email-masked]>
Date: Tue, 11 Feb 2020 18:34:26 +0000

Hi Adrian,

                The problem is that, as the leaf has a type,  It would require to say which value of that type means "No value assigned". An alternative could be a choice of "No value is assigned" (an empty type leaf?) or the leaf with the type itself.  Does this makes sense?

                Oscar

De: Adrian Farrel <[email-masked]>
Enviado el: martes, 11 de febrero de 2020 10:29
Para: Oscar González de Dios <[email-masked]>; [email-masked]; [email-masked]
Asunto: RE: [netmod] Question on how to design a Yang model to reflect auto-asignment of a give leaf

Isn't it possible to handle case b) by defining a value to have the meaning "no value has been assigned" and then the user an explicitly set that value?

Adrian

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Oscar González de Dios
Sent: 11 February 2020 02:40
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [netmod] Question on how to design a Yang model to reflect auto-asignment of a give leaf

Best Regards,

                Óscar

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 12 Feb 2020 08:47:45 +0100 (CET)

Oscar González de Dios <[email-masked]> wrote:
> [Oscar] True. Should the leaf have a default value, it implies that
> "if the value is not set, the default value is taken".
> 
> [Oscar] No. Depending on the leaf, we would like to specify behavior a
> or behavior b. Behavior a is ok for most of the cases.  The problem is
> that in some cases, assigning a value has way more implications and
> the service will not work properly. Those case are the ones we wanted
> to specifically tackle.

Ok.  See below.

> [Oscar] Agree . "Theoretically speaking" this is the behavior I would
> consider strictly follows NMDA guidelines. Reality is implementations
> are yet far from this...
> 
> [Oscar] So... what would be the best way to specify the behavior?
> Explicitly adding an auto-assign leaf to identify the behavior? Just
> "obey" NMDA rules?

For your "auto-assignment" case, I would describe the behaviour in the
description statement.  Something like: "If this leaf has not been
configured, the server will calculate a value [... specify how ... ]
and use that value operationally.  This calculated value is available
in the operational state."  

For your other case (the user really doesn't want a value) I also
would document this in the description (unless it's obvious).

/martin

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 24 Feb 2020 21:13:40 +0000

Agree that ideally we avoid (a) in running. Unfortunately I think we used (a) in ietf-interfaces though:

         leaf type {
           type identityref {
             base interface-type;
           }
           mandatory true;
           description
             "The type of the interface.

              When an interface entry is created, a server MAY
              initialize the type leaf with a valid value, e.g., if it
              is possible to derive the type from the name of the
              interface.

I do like (c) but note that it means the value calculated by the server may not be persistent (e.g. across reboot). It depends how the server calculates the value. If it is "allocated" from some sort of free list, then at reboot it may select a different value than the previously selected value.

Jason

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Martin Bjorklund
> Sent: Wednesday, February 12, 2020 2:48 AM
> To: Oscar González de Dios <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netmod] Question on how to design a Yang model to reflect auto-
> asignment of a give leaf
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod