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

Andy Bierman <andy@yumaworks.com> Fri, 19 January 2024 17:19 UTC

Return-Path: <andy@yumaworks.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 5CB78C17A743 for <yang-doctors@ietfa.amsl.com>; Fri, 19 Jan 2024 09:19:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.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 PwnZv3-QRP8U for <yang-doctors@ietfa.amsl.com>; Fri, 19 Jan 2024 09:19:18 -0800 (PST)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 E1047C15198F for <yang-doctors@ietf.org>; Fri, 19 Jan 2024 09:17:52 -0800 (PST)
Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-6d9af1f52bcso830001b3a.3 for <yang-doctors@ietf.org>; Fri, 19 Jan 2024 09:17:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1705684672; x=1706289472; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x2LT6dbDjCMo/fN6fhUR64CtvPiGI9Pa/vi//REQ3Zg=; b=NGvKx7kpVQXbLRzqCfyxv+29Jg580k4bDqYaDRaxu4YEPgKBtkFROP2Od0Jt4siFs5 eB/M6BzYp6TVBMJtfT5fMUIOK35dIH/HaI2lEuLTebz2Ff5hNbE/npPjLjMQ2vxvk66Q SDUJVti2ft2I7StMsG1DVzGEiYnI+zO8vqkIFbPG0Zw4JVi2qxPBXX7YbRvzjIYmDGJJ gNeLc2WI4JsCKt86hTk1qynkSXREv7MRmbL9FfSKrBZy/zT+OrblaGH3CzjA74j5RhYV qSPDPpVjF+tSGbJqySLu69e5oRZtRp9GcWYFJY+v7QJqtxsEs7mXXmMoVI7Rmovrync4 BHhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705684672; x=1706289472; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x2LT6dbDjCMo/fN6fhUR64CtvPiGI9Pa/vi//REQ3Zg=; b=xADYZgWsxYq10LIiRAMA649UU/8AKyfPI+RueapmV0gd+GM5MVcF6ctlPlGn9E3M2g 2aSktQ7XJH+/T72nHrGZYc8QDS6B8njTr7DQttciUsyMwtPzcEnIpO0FVTopXKg6DmTd 39Nc2x3G64X0WsYFjHPWimjqNLxQanDypAicnA6ziX1hYWlPijP6G9X5hP7/ru7kBr1s 8xOsUO7a3ZX86C73liV5iS5vyifqbEntR/7VIs+AQrfwEOwEH03cu70o3B5+onidpySs arqwymhfFuDcCRtdnUtn9p+kqse1aOo/dXeR+eQIeU5wADq5Lm8ZLoqQNtdDVLjC8Rv3 qC/w==
X-Gm-Message-State: AOJu0YxV+xJCqAHXWDG7d6VfDleQlDCwAnIoq/fl8n4hpTjDnAVe7OUN RNtO5j+o0YwkuJV0EvgZbm+2yKB2nC1NcncJXh4hZn/gK2saDl1Q/UWoWQ+jNXc/LZcbNrFpiyk f7umES1S54hX0QPXZimkk656japh/yllyMVxnwfSneWD4T51u
X-Google-Smtp-Source: AGHT+IEhsS1UdPUgblWtNzCDh34nwRzcSKC2kvVUq5bq1BprlF+3VxEEVSS0wMDzRRpn8QgJ0IKgBaUdeJ/l86knx5U=
X-Received: by 2002:a17:90a:d3d6:b0:290:6e2:1ee7 with SMTP id d22-20020a17090ad3d600b0029006e21ee7mr88631pjw.46.1705684671910; Fri, 19 Jan 2024 09:17:51 -0800 (PST)
MIME-Version: 1.0
References: <C1B843D2-D178-4E83-AEF8-6C726BD22597@gmail.com> <0100018c92fb0b64-5950acf7-2b47-4062-a35a-c2ca8fab14ce-000000@email.amazonses.com> <ZYXlOcZv8GUcfoBI@alice.eecs.jacobs-university.de> <ED9E8589-26F0-4434-AF93-F3EFC781EF97@gmail.com>
In-Reply-To: <ED9E8589-26F0-4434-AF93-F3EFC781EF97@gmail.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 19 Jan 2024 09:17:40 -0800
Message-ID: <CABCOCHQxAj7VAX1X8qTc3oiErmv=+6kBgw1ys5Ve-CspZU3d1Q@mail.gmail.com>
To: Acee Lindem <acee.ietf@gmail.com>
Cc: Jürgen Schönwälder <jschoenwaelder@constructor.university>, YANG Doctors <yang-doctors@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f7e650060f4fa8f6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/NYZVSXKfrvaMwqg5uezEcUfL8oQ>
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:19:22 -0000

On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem <acee.ietf@gmail.com> wrote:

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

What does "must be returned" mean?

Obviously, it does not mean returning the data even if the filters do not
select that node. (I hope)
I used to think it meant conformance  (whether the server must implement or
may implement).
I was told years ago that is not the case. Use if-feature for that. No
if-feature == mandatory-to-implement.

If a client requests the parent subtree, then how would it know the
difference between config=false
nodes that are not present vs. the server just decided not to return them
(even though conformance
to the retrieval operation requires them)?

IMO the mandatory-stmt for config=false nodes does not make any sense at
all.



> Thanks
> Acee
>
>
Andy


> > 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/>
>
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
>