On Thu, Aug 28, 2025 at 11:29:14AM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > Why? Is unfixable to consider this? > > I'm not sure. > > It depends on several factors: > 1. Do we have users of the json monitor mode? > 2. Can they cope with *partial* info? > For non-json, the user will be a human and they > can the delete messages will have enough info to > correlate it with the corresponding add messages. > But for automated robots consuming json? Dunno. > 3. Is the burden of correlating the delete info > with the full information about the deleted object > on the nft monitor -j side or the consumer of the > (Then incomplete) json info? I don't think json output should diverge from the native monitor mode, which only displays the partial information. Then, for stateful objects such as counters, maybe there is a usecase to display this in the delete object events, but then native nftables monitor should display the same behaviour. > > this is a relatively large rework, I started some code but is > > incomplete, including rule caching to deal with runtime incremental > > updates. > > Thanks Pablo. > > > I think it should be better to fix what we have then look pick back on > > the rework at some point. > > I also prefer repair to "nuke it". > But I dislike the idea of spending time on something that is not > used in practice. I don't find a good reason to cripple json to make it less capable than the native representation.
