Re: [yang-doctors] [netmod] Operational State usage of YANG choices and constraints (fix draft address)

Acee Lindem <acee.ietf@gmail.com> Fri, 19 January 2024 17:47 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 D036DC14F685; Fri, 19 Jan 2024 09:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 x7FhMbDUQH1Y; Fri, 19 Jan 2024 09:47:43 -0800 (PST)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 306B8C14F61F; Fri, 19 Jan 2024 09:47:40 -0800 (PST)
Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6e0a89b98e4so716652a34.1; Fri, 19 Jan 2024 09:47:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705686459; x=1706291259; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=vCzFPKKizvao5D+Mk+jlJOGYidaked8ZQ72KWH20o9A=; b=GYvJjsrT72noVFJLwIrDhhgk4ZtE2W2hy1VU3fJ4f3AAQluqLF3ae+d75p3a1SrDP4 7LiFPvmYxC97ZV9sO4tZPuyUNoYhQm/Xh8qlPpAG4X4Toj4HqCTV/AweDEZg9sDHwGYb vToMI5p/wrwLybg8avtZuhV+ODy2YTSqMQaHw/EzqS5LXBduPWmfhTMXwXuft/IC39dj SDLxIEMRFDxpnLMBe2aROMcZWSmae4vplk0/oGlG1j3aMcLFBWO2ZbnvXv8h9Wrt7Hs4 oNaaeNBsNdGyiMg8T2sj2pGzV57wDwCF4awx/DeQEZIYA4SX5c7dcHFnWkCM3OhtDxif aJ/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705686459; x=1706291259; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vCzFPKKizvao5D+Mk+jlJOGYidaked8ZQ72KWH20o9A=; b=OlTGL16CLP75Qc2ldZsWLKIEm64VHPRG5QwcNBdhofVHDyZwYbLZQhXmKedL27ryu2 jcGbfq6hq/tXGTp1Artn+94O0Dd8DSdkiZSxRAvzZtAQkzSflr4LkMSUyN4mbeDd1x8H tkjrIfB6H1n/5u5KiHu5T36cnwQAWML5Ro33I7vTKHaOsile6Tqc8M8GNfR9KNN7u0tQ CNdA12nSF64v+U6Ax+CMw9a6NtkuN1RCECcAOysY1ybMjdyt1D0iT/6e63BxX0JQGhZs VynWITBr6cXeTJHJWxh2YdX9y92coqO9fS06/4LbfP4P5NNkVoa9rp6soAX2xwHeA0Rv Pv9A==
X-Gm-Message-State: AOJu0YwJvY43GuyTUOjXzul6P1XT6XisnIfqKNALNj3RHwyO4vUgRYZr bQvpVER3r8KNf8iqNEZZVf+zap/q6ZBWDaBMQ9I9cf3PVc5qct8A
X-Google-Smtp-Source: AGHT+IFV0iHpMciprzl9RJHdVeO8Y+6Cj8zBsUNKpYOJ7qJgV/pGEUJSON64L+e/nNiZJHvdVdwPaA==
X-Received: by 2002:a05:6870:3322:b0:210:a58e:ce9a with SMTP id x34-20020a056870332200b00210a58ece9amr134386oae.70.1705686459245; Fri, 19 Jan 2024 09:47:39 -0800 (PST)
Received: from smtpclient.apple ([136.54.28.118]) by smtp.gmail.com with ESMTPSA id v7-20020ad448c7000000b006816843f6dcsm3830708qvx.137.2024.01.19.09.47.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2024 09:47:38 -0800 (PST)
From: Acee Lindem <acee.ietf@gmail.com>
Message-Id: <A2E743CE-9D29-4782-9970-AE8CF97DC603@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9DE6BA0A-580B-4887-AE84-B1356E444C25"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
Date: Fri, 19 Jan 2024 12:47:28 -0500
In-Reply-To: <CABCOCHQxAj7VAX1X8qTc3oiErmv=+6kBgw1ys5Ve-CspZU3d1Q@mail.gmail.com>
Cc: Jürgen Schönwälder <jschoenwaelder@constructor.university>, YANG Doctors <yang-doctors@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, draft-ietf-netmod-rfc8407bis@ietf.org
To: Andy Bierman <andy@yumaworks.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> <ED9E8589-26F0-4434-AF93-F3EFC781EF97@gmail.com> <CABCOCHQxAj7VAX1X8qTc3oiErmv=+6kBgw1ys5Ve-CspZU3d1Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/tQCx-vzzH7ligEbBcVxIU8kXmwQ>
Subject: Re: [yang-doctors] [netmod] Operational State usage of YANG choices and constraints (fix draft address)
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:47:46 -0000

Hi Andy, 

> On Jan 19, 2024, at 12:17, Andy Bierman <andy@yumaworks.com> wrote:
> 
> 
> 
> On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem <acee.ietf@gmail.com <mailto: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.

I’m fine with that - we just need to make sure that this is reflected in our IETF models. I think these points are worth addressing in RFC8407 BIS. 

Thanks,
Acee



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