Updated the spec with the latest clarifications. 2018-01-21 0:42 GMT+01:00 Bruno Verstuyft <bruno.verstu...@gmail.com>:
> > > 2018-01-19 23:21 GMT+01:00 Guy Harris <g...@alum.mit.edu>: > >> On Jan 19, 2018, at 5:03 AM, Bruno Verstuyft <bruno.verstu...@gmail.com> >> wrote: >> >> > 2018-01-19 10:10 GMT+01:00 Guy Harris <g...@alum.mit.edu>: >> > >> >> Is the Burst ID just a sequence of octets? >> > >> > For the moment, the Burst ID is a uint64_t. Should this not be not >> enough >> > in future implementations, it can be increased to e.g. uint128_t >> >> So it should be treated as an opaque array of bytes, with no significance >> to the values of the bytes, and used only for matching bursts and the MAC >> frames contained within them by comparing the byte arrays for equality? >> > > Yes, this is correct. > > >> >> >> What does the Burst ID Reference field contain? Another burst ID? >> > >> > The Burst ID reference is the same as the Burst ID. Burst IDs are used >> in >> > databursts, while Burst ID references are used in Mac Frames. For the >> > moment, these are both uint64_t. >> >> I.e., one or more MAC frames can be transmitted in a burst, and a capture >> can contain a record for a burst as well as records for the MAC frames >> within the burst, with the record for the burst having a Burst ID >> parameter, and all the records for the MAC frames in that burst have a >> Burst ID Reference parameter containing the burst ID value for the burst in >> which it appeared? >> > > This is also correct. > _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
