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

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

Hi, Jan

Thanks for supporting this work! Please see inline.
From: Jan Lindblad (jlindbla) [mailto:jlindbla=[e-mail]]
Sent: Friday, June 2, 2023 10:23 PM
To: Kent Watsen <[e-mail]<mailto:[e-mail]>>; maqiufang (A) <[e-mail]<mailto:[e-mail]>>
Cc: 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]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

Kent, Quifang,

I support adoption of this work. It is an architecturally deep and important topic. I think a good amount of work remains before we reach consensus, and that it is important to get the details just right since this is going deep towards the roots of our vision.
Glad to know that;-)
I have some detailed comments below, but nothing that affects the adoption call.


On 1 Jun 2023, at 22:55, Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:

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

Quifang,

Thank you for the updated draft. I think each version is getting better :-) but I still have some comments.
Sure.
+ Section 1, Introduction

   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.
While I strongly agree with the view stated here, I don't think we can have a MUST requirement on something so nebulous as "whenever possible". Change to SHOULD?
Happy to change to SHOULD.
+ Section 1.2, Applicability

   The immutability of data nodes

   is protocol and user independent.
I agree fully that the immutability concept should be protocol and user independent (i.e. works the same for both NC/RC/xC and all users). I would also like to add that immutability needs to be independent of operational state, i.e. that immutable nodes are immutable from time of creation and remain so for as long as they exist.
Thank you Jan for pointing this out. But I am unsure if the “operational state” here has the same meaning as in NMDA spec. My understanding is that you would like to mention immutability is unchanged in the node instance’s lifecycle, I think I agree with you. Do you think would it be okay to add the following sentence:
“It is also independent of the lifecycle of a node from time of creation to deletion.”
The immutability property and configured value of an existing node must only change by software update.
Sure, but would the configured value of an immutable node also changes by other conditions like license or hardware capability/resource changes?

+ Section 2, Solution overview

   However, the following operations SHOULD be allowed for immutable

   nodes:



   *  Use a create, update, delete/remove operation on an immutable node

      if the effective change is null.  E.g., if a leaf has a current

      value of "5" it should be allowed to replace it with a value of

      "5"



   *  Create an immutable data node with a same value that already

      exists in <operational> or <system> (if exists) in order to e.g.,

      configure a mutable descendant or reference it in a "when", "must"

      or "leafref" expression.



   *  Delete an immutable data node from read-write configuration

      datastores (i.e., <running>, <startup> and <candidate>) which do

      not prevent the data node still appearing in <operational> or

      <system> (if exists)
By the already established rules of 7950, I think the above statements are already MUST requirements. It may be good to clarify/restate that expectation here, but if so, I find it essential not to weaken the requirement to SHOULD (in the first cited line above) , but keep it MUST.
Okay, but it is not the intention to weaken the rules in the existing RFCs. Do you have any suggestions to rephrase these above statements?

+ Section 6.1, Definition

   Note that "immutable" metadata annotation is used to annotate data

   node instances.  A list may have multiple entries/instances in the

   data tree, "immutable" can annotate some of the instances as read-

   only, while others are read-write.
I think the immutable annotation on individual instances is useful, meaning those list instances would always have to be present. This is however getting very close to the edge for some of the deep no-nos for me. Let's say there is a management interface that always has to exist for the configuration to be valid. Annotating that with immutable seems ok. But if someone suggests that some of these must-exist list elements can vary over time, i.e. sometimes have to exist, sometimes not, then I'm out. Not supportive.
Let’s state in the document that “the existence of immutable node instances cannot change unless software update, license or hardware capability/resource changes”, thoughts?

Basically, I don't want to ever get into a situation where I have a backup from time t that is not valid at some later time t+1.
Noted.
+ Section A.5, UC5 - Immutable BGP peer type

     list neighbor {

       key "remote-address";

       leaf remote-address {

         type inet:ip-address;

         description

           "The remote IP address of this entry's BGP peer.";

       }

       leaf peer-type {

         im:immutable;

         type enumeration {

           enum ebgp {

            description

              "External (EBGP) peer.";

           }

           enum ibgp {

             description

               "Internal (IBGP) peer.";

           }

         }

         mandatory true;

         description

           "Specify the type of peering session associated with this

            neighbor. The value can be IBGP or EBGP.";

       }
In my opinion, this use case is taking the immutability concept too far. It creates more problems than it solves. A configuration that was valid at time t may no longer be valid at time t+1.

Someone may argue that this use case is similar to UC2 in section A.2, which is an interface list with the interface type being immutable. I think UC2 is ok if the set of immutable list nodes is constant as long as the hardware capabilities and software version remains the same.

With UC5, the dependency is towards an external system that could basically change at any time. I don't want immutable nodes to appear, disappear or change value unless we're doing something drastic like installing new hardware or software.
I understand your point and tend to agree with you, I think it probably should be removed from the document.
Best Regards,
/jan

Best Regards,
Qiufang


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