Re: [yang-doctors] [netmod] Operational State usage of YANG choices and constraints

Acee Lindem <acee.ietf@gmail.com> Fri, 19 January 2024 17:02 UTC

Return-Path: <acee.ietf@gmail.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA4DC14F6AB; Fri, 19 Jan 2024 09:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlVeLTcBbsSd; Fri, 19 Jan 2024 09:01:55 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF117C14F617; Fri, 19 Jan 2024 09:01:54 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-4298e866cd6so6567011cf.0; Fri, 19 Jan 2024 09:01:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705683714; x=1706288514; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2hZCS5z/WDHlsCbZHqlIllUbdw21nAeueaaVTDNrhd8=; b=iSCsooNQ6F+k80VP5yzdIsgPDPsdEQ0f8KEZ4C44f7OTCRoSRBmDUHFk+3v/0kvFHu o4GEr1ddoofrFB9nsCJqKgDaPxbfRW4TOLE9H+E4klbjDSGn8zIAqU/0I/esl4DTrp7z nXhSdhHgjSDCJRJHfgvcRZSWbPxXxSyFsIXxiF64XqDD4nEyErLu22XoaaSTN8sZK4dX nriAvSkYG6syCIKQ6ZtPffzmw5pD/gPbJsrasZ8AwEcIUeehwtwaViZmA7pskUBwj+a7 B1DNQj3EUMgrUk9m5Qau9dQR6rlmJ6jo86P/yJNeO7CV8rUVLq3T6i4leb0O3fyjaKZb eNdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705683714; x=1706288514; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2hZCS5z/WDHlsCbZHqlIllUbdw21nAeueaaVTDNrhd8=; b=mRC74rC2Gg1yfTlJAPI4mwrel9lUdgRtLApq+Y0HHn2gkABvkHJtNDOcyeRVrgSuiR Y2emneZ02GvHYT2uhVDPXzTbtEzHFkGOs3HG/51UhCV//L0dxHB7ItfSi2NUv3NnZBAe yRN/8RjuzFijD9kcnUcEslaBf5oDtoPPWotXCIf7VmEQuXKBd062wmPwkYHjCCnGTEO5 1jkFl6CXz6zhb5uvEtDv7BS/LY4l3u83GrpR6miMSxc8HsQ63m2AS5VcJ26qHJtAeaBb zAeQ4JIDMR6mQsC/311B8Tuyakw5g2LQCyjWuljzmfxzKzAIVCh1Kqo+Aydiys5V5wDp EaJQ==
X-Gm-Message-State: AOJu0YyNlLv6mHr8rN5svVY25Kd8EPNvcHg1aoD+eXhnktnGoS0BeY3Q 7QDbgpxOzYqkC3GiySSOp0598n+KHeoKwC8E2TVdNKPRVhUSVUV4pkli74gd
X-Google-Smtp-Source: AGHT+IFcOw16nWHzix/oGTSk82ijYtJIRb6JYm2DwSuElYhjcBCsZh/TVwY8mLWs7gGP1Uc+Z6q4mA==
X-Received: by 2002:ac8:7d0c:0:b0:429:f695:7997 with SMTP id g12-20020ac87d0c000000b00429f6957997mr129942qtb.68.1705683713411; Fri, 19 Jan 2024 09:01:53 -0800 (PST)
Received: from smtpclient.apple ([136.54.28.118]) by smtp.gmail.com with ESMTPSA id w26-20020a05620a149a00b007838362da2dsm1010073qkj.111.2024.01.19.09.01.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2024 09:01:52 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Acee Lindem <acee.ietf@gmail.com>
In-Reply-To: <ZYXlOcZv8GUcfoBI@alice.eecs.jacobs-university.de>
Date: Fri, 19 Jan 2024 12:01:43 -0500
Cc: Kent Watsen <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>, YANG Doctors <yang-doctors@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <ED9E8589-26F0-4434-AF93-F3EFC781EF97@gmail.com>
References: <C1B843D2-D178-4E83-AEF8-6C726BD22597@gmail.com> <0100018c92fb0b64-5950acf7-2b47-4062-a35a-c2ca8fab14ce-000000@email.amazonses.com> <ZYXlOcZv8GUcfoBI@alice.eecs.jacobs-university.de>
To: Jürgen Schönwälder <jschoenwaelder@constructor.university>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/qkwGlmFc16Q66h2npJUa7TPgv54>
Subject: Re: [yang-doctors] [netmod] Operational State usage of YANG choices and constraints
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jan 2024 17:02:00 -0000

Along the same lines, what is the sentiment for “mandatory true” data nodes for operational state (i.e., “config false” nodes)? Does this make sense to identify data nodes the must be returned if the parent node is returned?

Thanks
Acee

> On Dec 22, 2023, at 2:36 PM, Jürgen Schönwälder <jschoenwaelder@constructor.university> wrote:
> 
> On Fri, Dec 22, 2023 at 07:22:55PM +0000, Kent Watsen wrote:
>> With limited experience wrt the impact on servers, as a client, it’s always best for the opstate data to be modeled as accurately as possible, for better processing and user experience.
>> 
> 
> What is accurate?
> 
> I think the answer is "it depends". There are states that a model
> allows to represent and there are states it does not allow to
> represent. If a device ends up in a state that the model can't
> represent, then the device has a problem, From a debugging point of
> view, the worst is a device in a state that can't be represented
> propoerly reporting a valid state it is not in.
> 
> So like everything else, it is a modeling decision, like picking types
> and everything else. I am not sure that 'as accurate as possible" is a
> helpful guideline; for operational state I prefer to see as much as
> possible the device's true state. (But even picking data types for
> leaves restricts what can be represented, so it is a judgement call.)
> 
> /js
> 
> -- 
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://constructor.university/>