Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Kent, all,

Writing as a contributor, I still have strong concerns with this draft.

From a YANG architecture perspective, I believe that the contents of the running datastore should be entirely under the client’s control, and servers should accept any valid configuration, and be able to move from any valid configuration to any other valid configuration.  We also already have the server datastore draft that I think should be the mechanism to allow a server to include server-controlled configuration before it is merged with running and validated as intended, that is somewhat outside the client’s control.  I.e., I think that having a clean split of ownership and responsibilities between a running datastore (managed by the client) and other datastores (e.g., intended and system-controlled) managed by the server is a good clean architecture.

I appreciate that not all servers allow clients to fully control their running configuration, but I think that a better solution (for management clients) so to encourage servers to migrate towards the goal of giving full ownership over running to the clients.  Hence, I’m particularly concerned about standardizing a YANG meta-data annotation that allows, and arguably even encourages, vendors or other SDOs to build immutable properties into their management models that breaks this goal.  I think that we need to be really careful here that we are not creating yet another fork of NETCONF/YANG with a fairly fundamentally different architecture to what we are currently aiming for.

I am somewhat more amenable to an annotation that indicates that if a particular leaf is modified it will potentially cause a more impactful change, by effectively causing a delete and re-add of the parent list/container (changing interface type could be an example of this).  But I don’t think that this stop clients from modifying the leaf to a new valid state, instead, the server should perform any necessary orchestration steps to apply the configuration rather than pushing that as extra orchestrations steps onto the client.  There is also part of me that questions how useful such an annotation or metadata would really be given that there are many other data nodes that have wide impact if they are modified.  So, from this perspective, I think that “immutable” is perhaps the wrong name.


Finally, I still question the assertion “Clients believe that "config true" nodes are modifiable even though the server is allowed to reject such a modification at any time.“ and regard it as possibly a bit disingenuous or perhaps being overplayed.  I’m not sure whether this assertion is coming from the YANG language (i.e., does RFC 7950 state this – I couldn’t quickly find it), or from NETCONF?  To me, it makes sense that a NETCONF server can reject a configuration change for various reasons (e.g., invalid yang, out of memory, some bug or flaw in the implementation), but I don’t think that really means that it is okay for a server (from a client’s perspective) to arbitrarily reject configuration.  A slightly strawman, but, e.g., would it be valid for a server to reject a request based on whether a generated random number was odd or even?  Can a server reject a config request because although the YANG schema indicates that it should be a number, the server has decided that sometimes it will only accept the item as string?  Perhaps according to the NETCONF spec these are both valid, but I’m not sure that either of these behaviours are helpful to clients or within the spirit of what is expected.



I do think that this is useful and interesting topic to have further discussion, particularly because of the external SDO interest - possibly a dedicated interim may be helpful – if we can get the key parties together?  As to adoption, I’m not necessarily opposed to this because there is definitely interest in this work, but personally I would like to see quite significant changes, and I suspect that more work is required to reach consensus.

Regards,
Rob


From: Kent Watsen <[e-mail]>
Sent: 01 June 2023 21:55
To: Jan Lindblad (jlindbla) <[e-mail]>; Jürgen Schönwälder <[e-mail]>; Andy Bierman <[e-mail]>; Rob Wilton (rwilton) <[e-mail]>
Cc: maqiufang (A) <maqiufang1=[e-mail]>; [e-mail]
Subject: Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

Hi Quifang,

The latest update looks very good to me - IMO, ready for adoption.

Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been addressed?

Thanks,
Kent




On May 25, 2023, at 8:16 AM, maqiufang (A) <maqiufang1=[e-mail]<mailto:maqiufang1=[e-mail]>> wrote:

Hi, all
This version reflects the input we've received from the mailing list.

Thank you everyone(Jan, Rob, Kent, Jürgen, Andy, Frank et al.) for your great comments and suggestions!
Please see if the following updates are good for you:
   *  Use a Boolean type for the immutable value in YANG extension and
      metadata annotation
   *  Define a "with-immutable" parameter and state that immutable
      metadata annotation is not included in a response unless a client
      explicitly requests them with a "with-immutable" parameter
   *  reword the abstract and related introduction section to highlight
      immutable flag is descriptive
   *  Add a new section to define immutability of interior nodes, and
      merge with "Inheritance of Immutable configuration" section
   *  Add a new section to define what the immutable flag means for each
      YANG data node
   *  Define the "immutable flag" term.
   *  Add an item in the open issues tracking: Should the "immutable"
      metadata annotation also be returned for nodes described as
      immutable in the YANG schema so that there is a single source of
      truth.

Thanks a lot.

Best Regards,
Qiufang

-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Thursday, May 25, 2023 4:52 PM
To: Balazs Lengyel <[e-mail]<mailto:[e-mail]>>; Hongwei Li <[e-mail]<mailto:[e-mail]>>; Qin Wu <[e-mail]<mailto:[e-mail]>>; Qin Wu <[e-mail]<mailto:[e-mail]>>; maqiufang (A) <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-ma-netmod-immutable-flag-07.txt


A new version of I-D, draft-ma-netmod-immutable-flag-07.txt
has been successfully submitted by Qiufang Ma and posted to the IETF repository.

Name:                  draft-ma-netmod-immutable-flag
Revision:              07
Title:                      YANG Extension and Metadata Annotation for Immutable Flag
Document date:               2023-05-25
Group:                  Individual Submission
Pages:                   24
URL:            https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-07.txt
Status:         https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag
Diff:           https://author-tools.ietf.org/iddiff?url2=draft-ma-netmod-immutable-flag-07

Abstract:
   This document defines a way to formally document existing behavior,
   implemented by servers in production, on the immutability of some
   configuration nodes, using a YANG "extension" and a YANG metadata
   annotation, both called "immutable", which are collectively used to
   flag which data nodes are immutable.

   Clients may use "immutable" statements in the YANG, and annotations
   provided by the server, to know beforehand when certain otherwise
   valid configuration requests will cause the server to return an
   error.

   The immutable flag is descriptive, documenting existing behavior, not
   proscriptive, dictating server behavior.




The IETF Secretariat



_______________________________________________
netmod mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod