There are several different cases one can consider and the text in the
description is not particulary clear which ones are covered (due to the
'e.g.' style).
a) Configuring an interface type that is not supported by the
firmware / operating system.
b) Configuring an interface type that is inconsistent with the
interface nameing scheme used by the firmware / operating system.
c) Configuring an interface type that is inconsistent with the
specific hardware currently plugged into the system.
d) Configuring an interface type for a piece of hardware currently
not present on the system.
The two concrete examples mentioned in the definition of the leaf seem
to cover a) and b). Cases c) and d) are likely where it is getting
tricky. I recall that people wanted to be able to provision config
that will become active once suitable hardware is provided. And that
includes provisioning new interface definitions that may not currently
match the hardware. Also note that a) and b) require that the server
"only" knows about the capabilities of the firmware / operating system
and the naming conventions while processing a configuration change
request. c) and d) require that the server knows about specific
hardware components present at the time the configuration change
request is processed. Hence, edits fail or succeed depending on the
physical resources present.
If we make it an art to restrict edits by declaring (temporary)
immutable data in the config, we are opening the gate to recreate
nightmares from SNMP land where configuration changes worked in
certain contexts but not in others and clients had to engineer how to
create sequences of edits that get your desired config established.
Its a slippery slope.
/js
On Wed, Apr 26, 2023 at 01:23:54PM +0000, Kent Watsen wrote:
>
>
> > 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.
>
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://constructor.university/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
