Startup barrier is not according to definition

According to the definition of the startup barrier (https://kb.hilscher.com/pages/viewpage.action?pageId=112435881 ), three conditions need to be fullfilled for the barrier to be passed:

1) DDP data has been set and the DDP was rendered active
2) The ethernet subsystem has been started (happens automagically when DDP was set active and contains valid MAC address(es) via DrvEth_Startup_Init())
3) Remanent data has been set/loaded by either the GenAP/SpecificAP or the host application

All three conditions are respected by the startup barrier and the actual stack booting (starting of objects, execution of the process loop, ...) will be blocked until the conditions are fullfilled.
Anyway, we are supposed to reject all packets with an appropriate error code if the conditions are not fullfilled yet except for a few whitelisted packets.
Currently, the packets are only rejected in dependence of condition 1 plus a validity check of the EIP DDP data.
If, for instance, remanent data has not yet been set, all packets are still accepted.
If, for instance, the Ethernet subsystem has not been started, all packets are still accepted.
Remanent data can be set by the host at anytime and also multiple times (latter case should be ok, no need to restrict it).
In case we retrieve a channel_init and remanent data has not been set yet, a deferred stack boot is requested, so that the channel inti will automagically be performed once the remanent data has been set.

This is implemented this way because the implementationis actually older than the definition and we adapted only lazily when the definition was made.
Stuff should be reworked to be more explicit and reduce complexitiy:

A) All three startup barrier conditions shall be fullfilled in order for the barrier to be passed (as in current implmenentation).
B) All packets except for the whitelisted ones shall be rejected while any of the three startup barrier conditions is not fullfilled yet with meaningful error codes (e.g. ERR_HIL_REMANENT_DATA_MISSING for remanenetd ata not set, ERR_HIL_NO_MAC_ADDRESS_AVAILABLE? for ethernet subsystem not yet active)
C) The deferred stack boot logic shall be removed.

I tis to be discussed whether this shall be reworked also for V3.7.0.1 (I vote for yes if security firmware shall be rolled out based on the V3.7 minor version)