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

["maqiufang (A)" <[e-mail]>]

Hi, Rob

Thanks for sharing your concerns, but I think there might be some misunderstanding that needs to be clarified, please see my reply inline.

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

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 agree with you that the client should have fully control over the contents of the running datasore, but I don't see this draft(-07) conflicting with that goal. Maybe we should make it more explicit in the document, but it is already the case the immutable configuration can only be created by the system (and present in <system>), other cases like the client creates a node instance but cannot modify that afterwards is the non-transactional behaviour we’ve discussed before and should be avoided. That said, only the server can create/update/delete immutable configuration, this has no impact to clients and <running> datastore by default. Only when the client would like to reference the immutable system configuration, will that configuration be copied and thus appears in <running>. But by default, immutable configuration is only seen in <system> (if implements) and <operational>. Hopefully this clarifies.
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.

As I mentioned above, I think it’s not our intention to break the goal of giving full ownership over running to the clients. It is still about the system-controlled configuration immutability declaration. This does not necessarily mean that we are encouraging such behaviour, the introduction section has also states that:

” Immutability is an existing model handling practice.  While in some
  cases it is needed, it also has disadvantages, therefore it MUST be
  avoided wherever possible.”
Would this be sufficient from your perspective?

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.
After the previous discussion on the list, we were trying to avoid the non-transactional APIs, and now we are only targeting immutable configuration with the lifecycle totally driven by the system. So I tend to agree with your proposal to define a flag to indicate a leaf is modified will potentially cause the server to delete it and recreate with its parent node. And I also agree this should not be called “immutable” anymore. But that is not we are trying to achieve in the document now, and is not in the scope of the current document.


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 think it might be the “at any time” that is overplayed. In NETCONF RFC(https://datatracker.ietf.org/doc/html/rfc6241#section-7) it already mentions that

“A protocol operation can fail for various reasons, including
   "operation not supported".  An initiator SHOULD NOT assume that any
   operation will always succeed.”
Immutable configuration is something the server always rejects, I think it a stable behaviour.

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.
Thank you, Rob. I don't object to a dedicated interim meeting personally, but before that I think it might be helpful for us to make sure that we have the same understanding about our scope of immutable configuration, agreed?
Regards,
Rob

Best Regards,
Qiufang

From: Kent Watsen <[e-mail]<mailto:[e-mail]>>
Sent: 01 June 2023 21:55
To: Jan Lindblad (jlindbla) <[e-mail]<mailto:[e-mail]>>; Jürgen Schönwälder <[e-mail]<mailto:[e-mail]>>; Andy Bierman <[e-mail]<mailto:[e-mail]>>; Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
Cc: maqiufang (A) <maqiufang1=[e-mail]<mailto:maqiufang1=[e-mail]>>; [e-mail]<mailto:[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