[netmod] Re: origin "system" in system-config-09

Kent Watsen <kent+ietf@watsen.net> Thu, 07 November 2024 14:33 UTC

Return-Path: <01000193070b1fcf-4d31f485-4e28-4973-9588-5166ba258073-000000@amazonses.watsen.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C9BC15199C for <netmod@ietfa.amsl.com>; Thu, 7 Nov 2024 06:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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_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 (1024-bit key) header.d=amazonses.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 zOuLp5dH3Xx1 for <netmod@ietfa.amsl.com>; Thu, 7 Nov 2024 06:33:11 -0800 (PST)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E890EC15108D for <netmod@ietf.org>; Thu, 7 Nov 2024 06:33:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1730989989; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=dTPvokCMTQZhuJUyUI9sAX64wdvh47V3cyg/WfZYfcg=; b=uB6apvsj6WAy6XCt7ZEpizzckgJT8Jz963lDDI2GFJ9Z3mTTKJp4rI6s5sEftYfD OhgCD3R1hdmPachorivhxJhdvqDqk5tKHFhg0/tlFj8tSaI4/VDRxbuls/jHmKkEq/D HFKdTcqXliEU06JiM8Xa0ixebe/znpf5Qj5yrVAw=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000193070b1fcf-4d31f485-4e28-4973-9588-5166ba258073-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_92E9E9DB-3DF9-437B-8A93-DBFDD6FE75EB"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Thu, 07 Nov 2024 14:33:09 +0000
In-Reply-To: <SN6PR08MB4847C69AB9C1D8A57635B38F9B5C2@SN6PR08MB4847.namprd08.prod.outlook.com>
To: "Jason Sterne (Nokia)" <jason.sterne=40nokia.com@dmarc.ietf.org>
References: <Zyu1J4uSD62RTjl6@alice.eecs.jacobs-university.de> <0100019305a44f78-f23a2a7b-826f-4c92-9f6a-64209f30eb49-000000@email.amazonses.com> <ZyyCGfhEb1jccgIW@alice.eecs.jacobs-university.de> <SN6PR08MB4847C69AB9C1D8A57635B38F9B5C2@SN6PR08MB4847.namprd08.prod.outlook.com>
X-Mailer: Apple Mail (2.3774.400.31)
Feedback-ID: ::1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.11.07-54.240.8.96
Message-ID-Hash: JYCBLZO4QPVGST5JOBE5YR5YBPJCMADV
X-Message-ID-Hash: JYCBLZO4QPVGST5JOBE5YR5YBPJCMADV
X-MailFrom: 01000193070b1fcf-4d31f485-4e28-4973-9588-5166ba258073-000000@amazonses.watsen.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Jürgen Schönwälder <jschoenwaelder@constructor.university>, "netmod@ietf.org" <netmod@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [netmod] Re: origin "system" in system-config-09
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/B-bjeKrR02TUUaS_FLSJTDXU1Yc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>

Hi Jason and Juergen,

This email responds to both of your messages, i.e., keep scrolling!  ;)

Kent // contributor


> On Nov 7, 2024, at 1:35 PM, Jason Sterne (Nokia) <jason.sterne=40nokia.com@dmarc.ietf.org> wrote:
> 
> Hi Kent,
> 
> My thinking was along the lines of what Jurgen mentions here: there are some values in operational that come from the system, but don't come from the system DS.  

Before a server implements ietf-system, *all* such values fall into that category, right?  Now assume in the next release the server implements ietf-system, which just indicates what values are/were selected before.  Nothing else (e.g., internal code) changes.  Did the value suddenly come from the <system> datastore, or is it more that the <system> datastore accurately modeled the system’s behavior?  I think that it is that latter, but read on...


> I don't think the intention was that *anything* marked with origin "system" is also sitting there in the system DS.

That would entail the data-tree in <system> being perfectly complete and accurate, which is ideal but highly unlikely.   FWIW, I view this point as supporting my perspective of not trying to over engineer this.


> My example of node "foo" having different values was between <running> and <operational> (nothing to do with system DS).  In the current specs (without the new DS draft), do you agree the origin of foo would be "or:system"?  

Yes.


> I'm simply talking about a situation where the user asks for 1500 in the <running> but the server can't quite program that in the h/w due to some other constraints, or some rounding function, etc and can only do 1492 so that is what they report in <operational>. I don't think it makes sense for that leaf to suddenly now show up in the system DS.

Why not?  The system-config draft indicates that the contents of the <system> datastore may change based on events such as a software/hardware/license change.  What else of you think the draft intends then?


[keep scrolling]


> Jason
> 
>> -----Original Message-----
>> From: Jürgen Schönwälder <jschoenwaelder@constructor.university>
>> Sent: Thursday, November 7, 2024 4:02 AM
>> To: Kent Watsen <kent+ietf@watsen.net>
>> Cc: Jason Sterne (Nokia) <jason.sterne@nokia.com>; netmod@ietf.org
>> Subject: Re: [netmod] Re: origin "system" in system-config-09
>> 
>> 
>> CAUTION: This is an external email. Please be very careful when clicking links or
>> opening attachments. See the URL nok.it/ext for additional information.
>> 
>> 
>> 
>> On Thu, Nov 07, 2024 at 08:01:14AM +0000, Kent Watsen wrote:
>>> 
>>>> I think it is important to keep the distinction between 'or:system'
>>>> and 'sysds:system' since config generated by the system is different
>>>> than config originating from a system datastore.
>>> 
>>> I saw this comment last night and it didn’t sit right.
>>> 
>>> Assume a server initially has no <system> datastore, and so reports a node’s
>> origin as “ds:system”.
>>> 
>>> Then later supports the <system> datastore, trying to expose some of what it
>> does internally.   Nothing has changed with the internal code, only the datastore
>> was created.  Why should the node’s origin change?
>> 
>> For me, a valued copied from a datastore is different than a value
>> generated by some program logic buried somewhere inside the system. I
>> assume we have different understandings what a system datastore is all
>> about, which then may be a bigger problem.

I appreciate this perspective, but I also think that the entire goal of the <system> datastore is to model (as best as possible) the values that the buried program logic generates.


>>> Regarding a value in <operational> varying from a value in <system>,
>>> this just seems like a bug in the YANG defined for the <system>
>>> datastore.
>> 
>> For me, the origin indicates where I can find the source of a value.
>> If the source is the system datastore, then I expect that to be
>> reported and I expect to find the value also in the system datastore.
>> If the source of the value is the system itself, then I expect that to
>> be reported and I do not necessarily expect to find the value in the
>> system datastore.

I get that but, again, I see any variance as an opportunity for the server-developer to update the values populated in <system> to better model the system’s true behavior.


>> I fear we may have a bigger problem by not agreeing on what the system
>> datastore actually is...

Indeed.  It might help to think about the use-case that <system> intends to support.  My understanding is that it’s trying to reveal more about what the buried program logic does, so that the network’s functioning can be better understood, e.g., to implement a digital twin.

K.


>> 
>> /js
>> 
>> --
>> Jürgen Schönwälder              Constructor University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> _______________________________________________
> netmod mailing list -- netmod@ietf.org
> To unsubscribe send an email to netmod-leave@ietf.org