IETF Logo Mail Archive

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

Kent Watsen <kent+ietf@watsen.net> Wed, 26 April 2023 01:45 UTC

Return-Path: <01000187bb3c4440-4ce1d8f4-288d-413e-ba24-66ec77a3012c-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 CF7AEC1526E9 for <netmod@ietfa.amsl.com>; Tue, 25 Apr 2023 18:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 5cI6FZoZmtYF for <netmod@ietfa.amsl.com>; Tue, 25 Apr 2023 18:45:03 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A66C1519AE for <netmod@ietf.org>; Tue, 25 Apr 2023 18:45:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1682473502; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Ccy3uOpzqlOarpR4Wzc54TWy1XPx4BIvQkwYjrsHguk=; b=NW3x8jvHiPutZFyh0Ccp25qJEPVWOJIE7dh5xm0In1YCRZ5a/c11WuUha+BEWeyQ KB58NVYJauCTuWBXXHrl+ecwBopt7Vv29RoyPlGyetxGFmrnnI30iR3IIoM9e5em6ux hRbOgKw+m8Nb5GggJ3sl24bK3NjvaId1bwRgSiQU=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000187bb3c4440-4ce1d8f4-288d-413e-ba24-66ec77a3012c-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_866EF1F4-7C28-4E34-877D-A4F094604AD5"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Wed, 26 Apr 2023 01:45:01 +0000
In-Reply-To: <CABCOCHS=FWJu4NgTvbUH5Kji1AKkWHW8U2yB5WhcVb4D63a-OA@mail.gmail.com>
Cc: Jürgen Schönwälder <jschoenwaelder@constructor.university>, "maqiufang (A)" <maqiufang1=40huawei.com@dmarc.ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>
To: Andy Bierman <andy@yumaworks.com>
References: <20230425121257.djkmjqjkiojhrkhd@anna> <01000187b87320fc-5de40e8d-889d-424f-8eb5-7e18a2f7bac5-000000@email.amazonses.com> <20230425131539.fnjz3f5h7xvcvncn@anna> <CABCOCHS=FWJu4NgTvbUH5Kji1AKkWHW8U2yB5WhcVb4D63a-OA@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2023.04.26-54.240.8.31
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/LV9VdFUcRc8D7LAsC0hRl-CFIw8>
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06
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, 26 Apr 2023 01:45:03 -0000

Hi Andy,

> I hope the immutable flag will work with non-NMDA as well as the current NMDA.

Yes. 

A non-NMDA server can still:

Present YANG modules having the "immutable" extension statements.  It's up to the clients if they understand it and, if not, then nothing changes.

Return the "immutable" metadata annotation, if the client sends the `with-immutable` parameter in a get request.

The only thing "missing" is the ability for the client to get the <system> datastore.  The ability to get <system> is desirable to discover, e.g., vendor-defined reference-able "shared" objects.   The same information could be supplied via another way, e.g., vendor documentation.

K.

v2.23.0 | Report a Bug | By Email