[netmod] Draft minutes for Feb 6th Virtual Interim on immutable flag

["Jason Sterne (Nokia)" <[e-mail]>]

Hi all,

The draft minutes for the Feb 6th virtual interim on the immutable flag have been uploaded:
minutes-interim-2024-netmod-02-202402061400-00.md (ietf.org)<https://datatracker.ietf.org/meeting/interim-2024-netmod-02/materials/minutes-interim-2024-netmod-02-202402061400-00>

Also copied below for quick reference.

Please let me know if some of this needs revising to more correctly capture discussions, conclusions or status from the meeting.

Thanks again to Qiufang Ma for leading this discussion, and to the many people who actively participated. Links to materials and video recording can be found here:
interim-2024-netmod-02 : netmod (ietf.org)<https://datatracker.ietf.org/meeting/interim-2024-netmod-02/session/netmod>

Regards,
Jason (as Secretary)

---------------------------------

Session Intro & WG Status (5 min)
Presenter: Chairs
YANG Metadata Annotation for Immutable Flag
Draft: https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09
Presenter: Qiufang Ma

Minutes:

Note these minutes are not necessarily in the order of the
discussions/transcript. There were many interleaved topics and some
topics came back up multiple times during the meeting.

This also represents only the opinions of the attendees of the interim
meeting. Several proposals and details need to go back to the list for
confirmation.

The 'immutable' annotation is inherited. The default is "false". Top
level elements are not required to have the annotation (and hence are
immutable false by default). Servers are allowed (and perhaps
encouraged) to suppress the annotation if it is inherited and unchanged,
but are not precluded from returning the annotation on every single
element (Postel's Law)

A server can have a parent element (e.g. presence container) marked as
immutable false, and then a child element can be marked as immutable
true (and vice-versa). i.e. a child element can override the (inherited)
immutability of a parent.

A client would never send the annotation (TBD: server accept and ignore?
error?)

Annotation for a list or leaf-list overall:

  *   not possible in XML encoding, so perhaps we should avoid it for all
encodings
  *   annotation for individual list entries or leaf-list entries is fine
  *   a parent container of the list may have the annotation, but that
should mean the same thing as each individual list entry being
annotated
  *   in theory it could be done at the schema level with an extension

Does an immutable true tag on a user-ordered leaf-list entry prevent
reordering of that entry (or other entries)?

  *   No. This immutable tag should have no bearing on order (allowing or
preventing reordering).
  *   Perhaps another flag or extension could be used (as part of other
future drafts)
  *   Gets complicated, especially with a mix of mutable and immutable
entries in a list
  *   would it just be the immutable entries that can't be reordered, and
just with respect to each other?

If all elements in a leaf-list (or list) are marked as immutable, then
it does not necessarily prevent further elements from being added. A
separate annotation (in a future draft) could potentially be used to
indicate that a list or leaf-list can't have any entries added.

  *   one thought experiment: imagine a list that has a mix of immutable
and mutable entries. Then the client deletes the mutable entries
leaving only immutable entries. We'd want the mutable entries to be
able to be re-added to the list.

We may want schema extensions (or use YANG tags) for indicating
immutability at the schema level, or for indicating that the list can't
be reordered. These maybe shouldn't be in scope for this particular
draft though.

Can a server:
1) change/create/delete an immutable element?
2) change an element from immutable true to immutable false or
vice-versa?
Answer: yes, but only in very specific senarios that will be defined in
the document (as an exhaustive list of the only allowable scenarios),
e.g.:

  *   software update of the server
  *   licensing changes of the server
  *   hardware changes

Debate occurred about whether we want to say a client can't modify nodes
marked as immutable? This may be a subtle point but the draft could
describe an annotation without necessarily saying that a cient can't
modify immutable data (or a server can't allow it to be modified). In
other words, the main use case is simply 'discoverability' (client can
discover what is labelled immutable).

  *   But note that immutable data can always be deleted from running
(since it can only come into running as a copy of system
configuration).
  *   Not all 3GPP use cases will be addressed by this work (some
consciously rejected). We're trying to avoid breaking transactional
semantics.
  *   The immutable annotation should not be used to prevent moving from
one valid configuration to another valie configuration (i.e. to push
non-transactionality back to the client)

If a server has an element that can be changed by a client, but causes
the parent object to be destroyed and re-created under the hood during
the commit, then the immutable annotation is not the correct annotation
to use to communicate this behavior. It would be some other
"will-cause-delete-create" type annotation or schema extension (totally
separate annotation and behavior than immutable).

A server should return an error if a client asks to modify immutable
data and the server won't/can't do it.

Interim attendees unanimously support adoption of this work (via poll).
Rob Wilton clarified his support is conditional on not affecting
fundamental expected YANG/NETCONF transactional declarative behavior
(e.g. we need to avoid server implementations from using this as a
shortcut and pushing non-declarative/non-transactional behavior to the
client, e.g. client must do step 1, commit, then step 2, commit to
achieve a final end config).