Hi Kent, authors, NETMOD,
Here are my WGLC comments on draft-ietf-netmod-immutable-flag-02.
Thank you to the authors persevering with topic. I’m not totally convinced
that we need this document but I can appreciate that the authors (and other
SDOs) believe that this work is important and helpful, and I can also
appreciate that reporting this is one common way is better than bespoke vendor
extensions. As such, and as written I think that it does no harm, hence I’m
not opposed to the WG publishing this …. All being said, I have a few comments:
Moderate level comments:
(1) p 7, sec 5.1. The "leaf" Statement
When a leaf node instance is immutable, its value cannot change.
Surely, you can also not delete a leaf that is marked as immutable, otherwise,
it would be possible to change its value simply by deleting it, then creating
it with a new different value? The same comment also applies to leaf-lists.
(2) p 7, sec 5.3. The "container" Statement
When a container node instance is immutable, it cannot change, unless
the immutability of its descendant node is toggled.
Do you mean descendant node here, or ancestor node? Why would the immutability
of a child node affect its parent node? The same comment applies to list
statements.
(3) p 7, sec 5.4. The "list" Statement
When a list node instance is immutable, it cannot change, unless the
immutability of its descendant node is toggled.
RFC 7952 does not allow meta-data annotations to list's themselves, only to
list entries. This probably needs to be clarified that lists (and leaf-lists)
can only inherit immutability from a parent node.
(4) p 11, sec 9. YANG Module
feature immutable {
description
"Indicates that the server supports the 'immutable' metadata
annotation.";
}
Is this feature required? What does it mean if this module is implemented by
the server but this feature isn't implemented?
(5) p 12, sec 10. Security Considerations
The security considerations for the Defining and Using Metadata with
YANG (see Section 9 of [RFC7952]) apply to the metadata annotation
defined in this document.
Note that RFC's security considerations section states:
This document introduces a mechanism for defining metadata
annotations in YANG modules and attaching them to instances of YANG
data nodes. By itself, this mechanism represents no security threat.
Security implications of a particular annotation defined using this
mechanism MUST be duly considered and documented in the annotation's
definition.
This probably means that you may need a bit more text in this document to state
that knowing whether or not a data node is immutable does not give any
significant additional information to an attacker.
Minor level comments:
(6) p 3, sec 1. Introduction
* UC4 Declaring immutable system configuration from an LNE's
perspective
LNE isn't defined anywhere. Presumably Logical Network Element?
(7) p 5, sec 3. Applicability
While immutable flag applies to all configuration nodes, its value
"true" can only be used for system configuration.
'system configuration' should probably be defined and reference the
system-datastore draft or NMDA draft.
(8) p 5, sec 3. Applicability
The immutable flag is also visible in read-only datastores like
<system> (if implemented, see [I-D.ietf-netmod-system-config]),
<intended> and <operational> when a "with-immutable" parameter is
carried (Section 4.2), however this only serves as descriptive
information about the instance node itself, but has no effect on the
handling of the read-only datastore.
This states that the immutable flat is also visible in read-only datastores,
but presumably it is only visible in read-only datastores, since everything in
<running>, is by definition, under the clients control and writable, or can be
deleted?
(9) p 5, sec 3. Applicability
An instance has the same immutability if it appears in different
writable datastores, the immutability of data object is also protocol
and user independent. The immutability and configured value of an
existing node MUST only change via software upgrade, hardware
resources change, or license change.
I think that this second sentence isn't really clear. Is the following what is
meant, and would this be more clear?
The immutability of any configuration data node, and the value of any immutable
configured data node, MUST only change via software upgrade, hardware sources
change, or license change.
(10) p 5, sec 4.2. "with-immutable" Parameter
This section specifies the NETCONF [RFC6241] and RESTCONF [RFC8040]
protocol extensions to support the "with-immutable" parameter. The
"immutable" metadata annotations are not returned in a response
unless explicitly requested by the client using this parameter.
Possibly consider naming the flag:
"with-immutability",
"with-immutability-flag",
"with-immutability-annotation"
This would make it more consistent with "with-defaults"
(11) p 9, sec 9. YANG Module
<CODE BEGINS> file
[email protected]<mailto:[email protected]>
module ietf-immutable {
Maybe consider calling this module "ietf-immutable-annotation" or
"ietf-immutability-flag".
Kind regards,
Rob
From: Kent Watsen <[email protected]>
Date: Wednesday, 26 February 2025 at 23:06
To: [email protected] <[email protected]>
Subject: [netmod] 1st WGLC on immutable-flag
This email begins a two-week WGLC on:
YANG Metadata Annotation for Immutable Flag
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-10
Please take time to review this draft and post comments by Mar 12. Both
favorable comments and objections are welcomed.
FWIW, a new IPR call is in progress:
https://mailarchive.ietf.org/arch/msg/netmod/le-_mNVF8hBpZRkDl27kckHKr4Q/
We’re running these calls in parallel since both the previous IPR call and what
is currently on file indicates no IPR.
Kent (and Lou)
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
