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 https://www.ietf.org/mailman/listinfo/netmod
