I have read draft-ma-netmod-immutable-flag-08 and my concerns
remain. While I do see some valid use cases for this, I am concerned
that this mechanism will be abused. The writing suggests that the
server can dynamically decide what it considers immutable. If true,
its a small step to have the server's decision depend directly or
indirectly on other edits done by a client or on the operational state
(the later is even described in the draft).
Thinking loud: If we can work out an immutable mechanism and we can
then drop the system datastore, perhaps this is worth it. I do not see
why we need a system datastore if we allow servers to add immutable
data to <running>. On the other hand, <running> was originally
designed to be fully client controlled. The notion of server supplied
immutable data nodes in <running> breaks this model. The other model
is to have immutable data only in something like <system> and then
that data gets merged into <intended> somehow. It seems the WG needs
to settle what the right model is, for me the documents are still
confusing and I am concerned about increasing client complexity and
lowering interoperability. If the <system> datastore and immutable
flags are designed to work tightly together, then we should be
explicit about this and depending on how close they are tied together,
perhaps even throw them into a single document.
Detailed comments:
I am confused about the relationship of the proposed read-only (?)
system data store and this immutable mechanism. They seem to interact
or overlap, it is not clear to me how.
The abstract says:
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.
This seems to say that clients have to discover and work around
immutable leafs in the data tree. The argument is that this improves
the state of the art where modification requests simply fail without a
clear indication of the reason. The solution assumes that clients
retrieve the relevant portion of the data tree and then they can
adapt. I think I also understood that immutable means 'immutable by a
client', the data may be mutated by system, i.e., the data is mutable
but just not mutable by the client.
Immutable configuration does not affect
the contents of <running> by default.
What does this mean? I thought part of the motivation was that
immutable data may be in config true nodes so that it can be
referenced. If not in <running>, then where? What is the non-default
case? For me, this is too fuzzy and handwaving.
Why can a client be expected to create immutable leafs in <running>?
Why do we need a system datastore if we allow immutable data (data
only mutated by the server) in <running> et. al? Or we don't allow it
in <running> and this depends on <system>? More generally, if we have
something in <running>, then this does not always mean it gets
applied. If there is immutable state, then non-matching config is
likely not applied. If immutable config can be a function of
operational state (and if it may even change with operational state),
then we end up with other config depending on immutable config
depending on mutable operational state, something we always tried to
avoid.
Which error is returned when a client attempts to edit immutable data
(with wrong values)? Is there a specific error that is returned when
immutability causes an edit to fail? Or is the client expected to do a
get when a somewhat generic error happens (with the necessary flags)
to check whether something are some immutable leafs involved (and the
client had the wrong value in the edit request)?
The error reporting is performed
immediately at an <edit-config> operation time, regardless what the
target configuration datastore is.
Why this statement, is this not generally how things work? What would
be a delayed error report?
Servers adding the immutable property which does not have any
additional semantic meaning is discouraged. For example, a key leaf
that is given a value and cannot be modified once a list entry is
created.
Not sure what this is trying to say. So what are the conditions under
which a server can declare something to be immutable?
And if I have some immutable data in a list, can I delete the list?
If not, what is the error that I can expect to get?
The "immutable" flag is intended to be descriptive.
What does this mean? The YANG extension that is to be used at data
model writing time. If a YANG module author declares a subtree to be
immutable, then this means exactly what for an implementor (of servers
and clients)?
The "immutable" YANG extension can be a substatement to a "config
true" leaf, leaf-list, container, list, anydata or anyxml statement.
It has no effect if used as a substatement to a "config false" node,
but can be allowed anyway.
I am not sure whether this fits the YANG design, are there other
examples where YANG allows non-sensible statements just to ignore
them? Perhaps Martin knows best.
Some of the text needs editorial work or better descriptions. An
example:
"If servers always reject client modification attempts to
some data node that can only be created, modified and
deleted by the device itself, an 'immutable' YANG extension
can be used to formally indicate to the client.
The logic feels backwards to me. The server rejects modification
attempts because some data is considered immutable by the server. The
text suggests it is the other way round, or worse, makes no sense
(consider a server rejecting a request repeatedly due to a lack of
permissions, this does not imply that the data is now immutable). And
the immutable statement is about designing at data model design time
that certain leafs are immutable. The server's behavior follows the
model, not the other way round. And I would consider an immutable
definition in the data model to actually be prescriptive in some
form or the other.
Adding immutable of an existing immutable statement
is non-backwards compatible changes.
Other changes to immutable are backwards compatible.";
What?
I am also puzzled what the 'value' of the immutable extension
statement is. The definition needs to be rewritten so that it
defines precisely what this extension statement is.
The description of the immutable annotation has similar issues, except
that for this one we know that the value is a boolean value.
"define the with-immutable grouping.";
This is the kind of descriptions nobody needs. Perhaps explain what
this definition is good for in order to establish the context for the
stuff in the grouping and how it is used later.
The example in A.1 is not really convincing. For the leafref to work,
you need a set of immutable leafs, one for each timer value supported
by the server. Are people really doing such constructions for timer
values?? I understand that you want a leafref pointing to one out of N
supported values, the timer value story, however, sounds weird. Do you
have more convincing examples that are still easy to understand?
The example in A.2 confuses me. Interface configurations are applied
to physically present interfaces. There is a name binding of the
interface configuration to a physical interface. This section seems to
suggest something very different from how I understand RFC 8343.
I have no idea why A.2.1 is there, it seems to show normal NC behavior
or did I miss something? That said, what I am indeed missing is a
clear definition which error is returned if an attempt is made to
mutate an immutable leaf (well to a value it does not have).
In A.3, if we have entries in lists that are immutable because the
server believes this is good for the customer, then I am concerned
that this stuff is not a static rare thing but something that will
come and go dynamically. I see great potential for abuse of such a
mechanism. Once the client needs to adapt to server logic to determine
the mutability of things, we are on a slippery slope.
/js
On Tue, Sep 05, 2023 at 06:40:09PM +0200, Jan Lindblad wrote:
> Jürgen,
>
> I agree completely with you regarding transactional management. Well said.
>
> In my reading of -08, however, I don't see the non-transactional behavior you
> describe in there any more. It was there in -01, but based on feedback from
> me and others, I think it has been washed out. If you still find
> non-transactional behavior in the latest rev, could you please point it out
> to me as well? My support too depends on the absence of such language.
>
> I believe the document targets config true data that can never really be
> changed by any client. This data remains unchanged/unchangeable except
> possibly during a software version upgrade, entitlement/license change,
> hardware insertion or similar system-redefining event. Such data is config
> true simply because there are config true dependencies, such as leafrefs or
> must conditions on min and max range values. I think this kind of usage could
> be a relevant use case, and I'd support discussing ways to describe that in
> the WG.
>
> Best Regards,
> /jan
>
>
>
> > On 5 Sep 2023, at 18:05, Jürgen Schönwälder
> > <[email protected]> wrote:
> >
> > I do not support this work. Yes, it is some effort on the server side
> > to figure out how move from config state A to config state B. This
> > proposal essentially pushes the work towards the clients that now have
> > to figure out how to single step a server from config state A to
> > config state B - and if things fail on intermediate steps it is the
> > clients that have to figure out how to roll back the changes to get
> > back to config state A (if that is possible at all). The original
> > promise of NETCONF was that it is not necessary anymore to have
> > clients that please the server, which was comiing out of many years of
> > experience with protocols that required clients to please the servers.
> >
> > If implementations have constraints on what kinds of edits are
> > possible, then this is an implementation limitation and hence this
> > should be documented in deviation statements but not in the data
> > models.
> >
> > /js
> >
> > On Tue, Sep 05, 2023 at 12:42:35PM +0000, Kent Watsen wrote:
> >> NETMOD WG,
> >>
> >> This email begins a 2-week adoption poll for:
> >> https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/08
> >>
> >> There is no known IPR on this draft (IPR call
> >> <https://mailarchive.ietf.org/arch/msg/netmod/_S-cKw5jIBmDKEPBRq8KeAbNLGg/>).
> >>
> >> Please voice your support or technical objections to adoption on the list
> >> by the end of the day (any time zone) Sep 19.
> >>
> >> Thank you,
> >> Kent (as co-chair)
> >>
> >
> >> _______________________________________________
> >> netmod mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > --
> > 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] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/netmod
>
--
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
