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

Martin Bjorklund <mbj@tail-f.com> Tue, 11 February 2020 10:00 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC65C120241; Tue, 11 Feb 2020 02:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BfA8_WyaG3B; Tue, 11 Feb 2020 02:00:37 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EC22F120220; Tue, 11 Feb 2020 02:00:36 -0800 (PST)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 20F251AE018B; Tue, 11 Feb 2020 11:00:35 +0100 (CET)
Date: Tue, 11 Feb 2020 10:59:56 +0100 (CET)
Message-Id: <20200211.105956.997059335051594687.mbj@tail-f.com>
To: oscar.gonzalezdedios@telefonica.com
Cc: opsawg@ietf.org, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <AM6PR06MB5653DFBCFC89E54F28E45AECFD180@AM6PR06MB5653.eurprd06.prod.outlook.com>
References: <AM6PR06MB5653DFBCFC89E54F28E45AECFD180@AM6PR06MB5653.eurprd06.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/dJfty1aZzjqumnJPcE4noMmIh90>
Subject: Re: [OPSAWG] [netmod] Question on how to design a Yang model to reflect auto-asignment of a give leaf
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2020 10:00:39 -0000

Hi,

Oscar González de Dios <oscar.gonzalezdedios@telefonica.com> wrote:
> 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)).

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

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



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