Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen <[e-mail]>]

> Where in the NC or YANG RFCs do we talk about immutable data? Where in
> the interfaces data model do we define that the type leaf becomes
> immutable once a line card has been plugged into a slot?

Following is from RFC 7223.  Note that the description statement almost says that the value is immutable:

         leaf type {
           type identityref {
             base interface-type;
           }
           mandatory true;
           description
             "The type of the interface.

              When an interface entry is created, a server MAY
              initialize the type leaf with a valid value, e.g., if it
              is possible to derive the type from the name of the
              interface.

              If a client tries to set the type of an interface to a
              value that can never be used by the system, e.g., if the
              type is not supported or if the type does not match the
              name of the interface, the server MUST reject the request.
              A NETCONF server MUST reply with an rpc-error with the
              error-tag 'invalid-value' in this case.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifType";
         }

Also from RFC 7223, note that the value is used in a "when" expression:

     augment "/if:interfaces/if:interface" {
         when "if:type = 'ianaift:ethernetCsmacd'";

         container ethernet {
             leaf duplex {
                 ...
             }
         }
     }


My assumption (not knowing the true history) is that the "type" node is historically "config false" and, in <operational>, might have origin "learned", or maybe "system".  For some reason that I'm unaware of, it was desirable for the "type" node to appear in <running>, so that it can be, e.g., referenced in "must" and/or "when" statements.  That is, the "type" node in the YANG module was made to be "config true", but the "description" statement says that it is always expected to have the value that is (or will be, for a pluggable card) seen in <operational>.  Presumably, existing server behavior would reject (or ignore) a client's attempt to set the interface's "type" to anything other than it actually is.  If this is all true then all this draft does, for this specific example, is codify the "description" statement text to an "immutable" extension statement, so the behavior can be understood programmatically.

K.