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

"Adrian Farrel" <> Tue, 11 February 2020 09:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57A3B1201E0; Tue, 11 Feb 2020 01:29:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PhohsT1tPBSJ; Tue, 11 Feb 2020 01:29:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E5F1120020; Tue, 11 Feb 2020 01:29:11 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 01B9T9Iw009440; Tue, 11 Feb 2020 09:29:09 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 5B0E82204A; Tue, 11 Feb 2020 09:29:09 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 44A0522048; Tue, 11 Feb 2020 09:29:09 +0000 (GMT)
Received: from LAPTOPK7AS653V ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 01B9T8j7007329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Feb 2020 09:29:08 GMT
Reply-To: <>
From: "Adrian Farrel" <>
To: "=?iso-8859-1?Q?'Oscar_Gonz=E1lez_de_Dios'?=" <>, <>, <>
References: <>
In-Reply-To: <>
Date: Tue, 11 Feb 2020 09:29:07 -0000
Organization: Old Dog Consulting
Message-ID: <05b201d5e0bd$b6072520$22156f60$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05B3_01D5E0BD.B6072520"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQMbx7ZisvSDR1EI+zVXCf/lvNieh6WJ67IQ
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--19.789-10.0-31-10
X-imss-scan-details: No--19.789-10.0-31-10
X-TMASE-Result: 10--19.788600-10.000000
X-TMASE-MatchedRID: yebcs53SkkDxIbpQ8BhdbMzSKGx9g8xhqb3/o5s+OcNZ+YxyNxdzR1+N xwaxRYfvZJ+1U5CKLArxfWM+PIJa9uyt+a9Mtf+e8sc9oYKBve0+8WcgUjQUwiVJ1X9ZfHjXjQb 0ZijHcXA3Opzody2+qtfks/hPGgP5oQB3WAEpQLBUtFP653DHOLPgPvvwZyAROFiq9T5j3bWm2A O8c0o94kyabxvG0VndZok17GuDVgto/KGUV8ExqKroPbyANljgNRgcGqeB7b17uKMeruD2hrxcn Qq9vpcj4UVrO0h/WPxNspS/wQzGfYEA1AgGhA6pRBpDaTjP17ZQYo4xNF42Pi1fxFk3nlsuIw64 a0XgvUQYN30K9opVtdpLCq43Ert9y8DgNDt52YPPt0BCUKvjb5T90Kmx3bAeNs6rkdfjKVonp08 UAE0Wd73DiVsmUFdzelWcbd+lNvA8EsNqyZ1CzkS06t+EwLFSo+Qf8eUQWkePidi1OtopYyxCxM 8fgRh8Ps+FZHj2fJroPgRaUWjEzSztlhHSitjbxMxd/ZbO4GrPb1ynRkjJR3UayEpPvCHIej2V/ C8k9MaSsoEmD0IX6/d/G8vPpfqdvgWKYfsc+010KSA6l/GyKr5z1PmtbhtDcLmqoDKWuTAH2v62 8TAejK1zvtrcSIIrX18uUCAKL1X1f6EBkUtKaVHmrymVJ0uQtHpusXAVaAzc9KE2iwgwHhvPK7H JN6/Eenf1BR7Ur2M90zXgxkIfv6x9MD7jDQlWfY+iJfFQBxctxMagbN9/PAzvg1/q1MH2i8AKIR x0BCaUIK5oH9AEyYbQBKvu5aGu0bMgNH2rplKeAiCmPx4NwGmRqNBHmBve4vrbb+Cbm+mw7M6dy uYKgwDJmNK5f3bTb9mqLPX9lwfHa5sKNdYV6FxpOLYQuCsiTFL1glziFeA=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [OPSAWG] [netmod] Question on how to design a Yang model to reflect auto-asignment of a give leaf
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2020 09:29:15 -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?




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


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,





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

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

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