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> Wed, 12 February 2020 07:48 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 52731120041; Tue, 11 Feb 2020 23:48:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vaJQpx64-do0; Tue, 11 Feb 2020 23:48:32 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D2D3E120893; Tue, 11 Feb 2020 23:48:29 -0800 (PST)
Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id F12A81AE018C; Wed, 12 Feb 2020 08:48:24 +0100 (CET)
Date: Wed, 12 Feb 2020 08:47:45 +0100 (CET)
Message-Id: <20200212.084745.340561451697677336.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: <AM6PR06MB5653B347EE8C00708CBE7EC5FD180@AM6PR06MB5653.eurprd06.prod.outlook.com>
References: <AM6PR06MB5653DFBCFC89E54F28E45AECFD180@AM6PR06MB5653.eurprd06.prod.outlook.com> <20200211.105956.997059335051594687.mbj@tail-f.com> <AM6PR06MB5653B347EE8C00708CBE7EC5FD180@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/lFqna77YQFQvhadTg1S6FVoJ8Uo>
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: Wed, 12 Feb 2020 07:48:34 -0000

Oscar González de Dios <oscar.gonzalezdedios@telefonica.com> wrote:
> 
> 
> -----Mensaje original-----
> De: Martin Bjorklund <mbj@tail-f.com>
> Enviado el: martes, 11 de febrero de 2020 11:00
> Para: Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>
> CC: opsawg@ietf.org; netmod@ietf.org
> Asunto: Re: [netmod] Question on how to design a Yang model to reflect
> auto-asignment of a give leaf
> 
> 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?
> 
> [Oscar] True. Should the leaf have a default value, it implies that
> "if the value is not set, the default value is taken".
> 
> > 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?
> 
> [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.

> > 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.
> [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?

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





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