Andrew,
I think something for implementers to consider, would be to allow a configurable amount of IP payload in the header packet section. If you want the first 8 bytes of payload + all of the IPv4 or IPv6 packet, then you couldn't pick a fixed size to cover all cases without it being large enough to grab a large part of the payload in some cases.
So instead of a boolean [don't]continue-into-payload switch, an application could provide a configurable continue-into-payload count of n octets, being zero or more depending on the user and legal requirements.
Being an application specific thing, this isn't something for either the protocol or info model to dictate. But since we don't have a PSAMP Implimentation Guide, I propose these texts:
ipHeaderPacketSection
Description:
This information element carries a series of octets from the start
of the IP header of a sampled packet.
An application may append zero or more payload octets to the end
of the ipHeaderPacketSection.
The size of the exported section may be constrained due to
limitations in the IPFIX protocol.
mplsLabelStackSection
Description:
This information element carries the first n octets from the MPLS
label stack of a sampled packet.
An application may append zero or more payload octets to the end
of the mplsLabelStackSection.
See [RFC3031] for the specification of MPLS packets.
See [RFC3032] for the specification of the MPLS label stack.
The size of the exported section may be constrained due to
limitations in the IPFIX protocol.
--
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>