> 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.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
