Comment 10 for bug 1795212

@slaweq
Thanks for the comments.
From our point of view, it does not matter how long the full sync takes. Processing any RPC messages, even ones that are not stale, before the initial full sync completes is not guaranteed to provide consistent results.
For example, if a port-update-end arrives before that port is received as part of the initial sync it will unnecessarily result in a full resync on that port’s network. Similarly, if a port-delete-end arrives before that port is received as part of the initial sync then it will be added to the “deleted_ports” list but that list is not referenced during the full sync so the information for that port will remain in the DHCP configuration for that network even though the port no longer exists. That will cause issues later when a new port is created and uses the IP address of that deleted port.
We were opting the agent delay approach in the spirit of avoiding compatibility changes and changes that would impact running against an unmodified server. We agree that timestamp is a good approach but that will come with backward compatibility constraints and additional complexity.
Let us know if any further question or concern. Thanks!