23 Nov 16 02:54, you wrote to me:

 MK> Definetly something to think about but in the meantime I believe the
 MK> better distraction would be to see official documentation for the
 MK> currently used pkt headers.  Of those I see type 2.2 being the best
 MK> simply because of the lack of a questionable datetime stamp.

i agree that the existing type 2.2 and 2+ proposals should be elevated to
standards...

the timestamp thing in the packet headers of type 2 and 2+? they don't bother
me either way... the purpose of the timestamps in the packet headers, AFAIK, is
to aid in determining when a packet was built on the originating system... this
may allow a tosser to skip processing packets that are "too old" by its
settings... in other words, a faster way to skip "too old messages" but it
would really only come into play if a system has been down for some time and
then comes back online... the timestamp may also make it easier for the
originating to track the logs at that period and see what errors may have been
generated during that packet's creation... not being UTC oriented or carrying
any UTC offset doesn't really matter as the operator of the originating system
should be able to determine what his clock is set to... the receipient of the
packet shouldn't care about the packet's internal timestamp unless they are
using it for a "too old" option or they are reporting a problem about that
packet to the originating system...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... Praise to the chile gods for giving us Habaneros.
---