Agenda for NetMod interim-2024-netmod-02

2024-02-06 09:00-11:00 EST

Material:
https://datatracker.ietf.org/meeting/interim-2024-netmod-02/session/netmod

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).