Thanks for this @dsharifi, and for announcing the new proposals and linking to the announcement from each proposal (I found this very useful while reviewing, in addition to having the subnet name in the proposal titles 
).
I’ll list them here just for future reference:
- ejbmu 132395
(duplicate) - 4zbus 132391
- brlsh 132392
- w4asl 132393
- qxesv 132396
- pae4o 132397
- 2fq7c 132398
- qdvhd 132399
- w4rem 132394 ← The first system subnet to have the notorisation delay reduced (another 13 node subnet though, so 300ms seems right)
This is all very exciting!
@Manu, @dsharifi, @andrea, would it be feasible to only specify the payload fields that are necessary in future proposals, or is there a reason for the NULL fields that I’m not considering?
One thing that occurred to me while going through these proposals is that the way subnet config update payloads are constructed is very noisy (meaning there’s a slight danger that there could be a sneaky config change that’s harder to spot, particularly if there are 10 or so other proposals that are submitted at the same time, and only one of them has a subtle deviation).
Given that almost all of the subnet config fields are optional, can I ask why every field is always explicitly included in the payload (with a NULL value). Why not just omit the optional fields that are not being set by the proposal. This would make it very easy to spot exactly what’s changing from a mile off, instead of having to very carefully scan the payload and risk missing something. 