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 > <jschoenwaelder@constructor.university> 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 >> netmod@ietf.org >> 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 > netmod@ietf.org <mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
