Re: [netmod] Draft Minutes for Virtual Interim

Kent Watsen <kent+ietf@watsen.net> Wed, 31 January 2024 02:16 UTC

Return-Path: <0100018d5d4d31da-04396a66-ba47-4b83-8a49-db0748caa408-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 C4D63C15155A for <netmod@ietfa.amsl.com>; Tue, 30 Jan 2024 18:16:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 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_H2=-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=ham 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 qfK-c6wBHB9L for <netmod@ietfa.amsl.com>; Tue, 30 Jan 2024 18:15:58 -0800 (PST)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C46C151520 for <netmod@ietf.org>; Tue, 30 Jan 2024 18:15:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1706667356; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=xO7enabnLC0WgduW2L8nZ6Wm/bcO4qbnEFtEpaF5q2s=; b=jOzvm2rlA/k2hB/qe5FL2PWEmw3KkvwET24oeLh3kSZb+oudqwMxo8xV9KZrl9A2 nMwDFfk4awLnixejA1gZkPxS0oynZS8i9NJLKz4KIZxYAcmf3AHN8ClFaaD1OGVaBeV dc7PyfHfAxZP31dyn0gQBR39tBTZZtIECHl973t4=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100018d5d4d31da-04396a66-ba47-4b83-8a49-db0748caa408-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5BE95A71-88D5-4A92-889F-F058DB8AAC1C"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Wed, 31 Jan 2024 02:15:56 +0000
In-Reply-To: <BN7PR08MB523394ACDB47D1220F8C177F9B7D2@BN7PR08MB5233.namprd08.prod.outlook.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
To: "Jason Sterne (Nokia)" <jason.sterne@nokia.com>
References: <0100018d57bd8064-9b75a7c7-50cc-4eae-a947-553892702141-000000@email.amazonses.com> <BN7PR08MB523394ACDB47D1220F8C177F9B7D2@BN7PR08MB5233.namprd08.prod.outlook.com>
X-Mailer: Apple Mail (2.3731.600.7)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.01.31-54.240.8.96
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/9vDJ4dilosYiKq_T6EhU2HD1mW4>
Subject: Re: [netmod] Draft Minutes for Virtual Interim
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jan 2024 02:16:01 -0000

Hi Jason,

> On Jan 30, 2024, at 11:55 AM, Jason Sterne (Nokia) <jason.sterne@nokia.com> wrote:
> 
> Hi WG,
> (and in particular to those who attended the interim).
>  
> The summary below mostly matches my memory of the discussions, but I don’t really remember us concluding on this:
>  
>      The WG agreed to let 7950-bis "update" 8342 (NMDA) with the
>      clarification the <running> alone does not have to be valid.
>      E.g., clients may have to perform transforms to calculate
>      <intended>, which is subject to validation.

The audio indicates Rob saying this and no one objecting.
Are you objecting?


>  (the rest of the minutes/summary below also seems to contradict that paragraph being a conclusion no?)

Your comments below are not text-edits to the minutes, so it is unclear how they apply to the minutes.

Kent


> I thought it was going to remain somewhat optional/indeterminate if running will be valid:
> Servers may or may not enforce running to be valid (i.e. they may only validate intended as a proxy for validating running)
> Clients can’t necessarily expect to be able to offline validate running, although it may work in circumstances where the operator doesn’t use templates or inactive config *or* the client reproduces the server logic for the running->intended transforms
>  
> Jason
>  
> From: netmod <netmod-bounces@ietf.org <mailto:netmod-bounces@ietf.org>> On Behalf Of Kent Watsen
> Sent: Monday, January 29, 2024 7:21 PM
> To: netmod@ietf.org <mailto:netmod@ietf.org>
> Subject: [netmod] Draft Minutes for Virtual Interim
>  
>  
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext <http://nok.it/ext> for additional information.
>  
> 
> Link to minutes:
> https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/
>  
> Reproduced below for convenience.
>  
> Please report any updates needed here.
>  
> Kent (and Lou)
>  
>  
>  
> This virtual interim was soley focused on the "system-config" draft.
> Qiufang Ma presented.
>  
> Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config
>  
> In the course of two hours, there was a lot of discussion.  So much so
> that trying to capture all the points verbatim would take too long. A
> link to the video is here: https://www.youtube.com/watch?v=sAF0fppqBGA.
>  
> A high-level summary is:
>  
>   Qiufang's presentation focused on two main questions?
>  
>   1) The "origin" issue.
>  
>      The WG agreed that <system> nodes copied into <running> should
>      have origin "intended".  The system-config draft will "update"
>      RFC 8342 (NMDA) to state this.
>  
>      The WG agreed that data-migration is 1) not <system>-specific
>      concern and 2) is out-of-scope for this draft.
>  
>   2) Validity of <running> alone.
>  
>      The WG agreed to let 7950-bis "update" 8342 (NMDA) with the
>      clarification the <running> alone does not have to be valid.
>      E.g., clients may have to perform transforms to calculate
>      <intended>, which is subject to validation.
>  
>      The WG agreed on a new Option 4: this document doesn't say
>      anything at all about the validity of <running>.  That is,
>      fully rely on existing 7950 and 8342 statements.
>  
>      This leaves it up to interpretation.
>  
>      Templates and inactive configuration are nice for humans, but
>      unnecessary for machine-to-machine interfaces.  That is, the
>      issues arounds such mechanisms are largely moot in environments
>      using a controller.