Andrew, Paul, I agree to Andrews comments and I like his wording very much. I think this makes the IE really clear. I guess we will get something like an Implementation Guide as more and more people will implement PSAMP. Regards, Thomas Am Montag, 27. März 2006 12:27 schrieb Andrew Johnson: > Paul, > > Paul Aitken wrote: > > 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. > > Yes. > > > 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: > > Well just because we don't have an implementation guide at the moment, > doesn't mean we won't in the future. If something is best left to the > implementation guide then I don't think we should have to adjust the > model or protocol documents. > > > 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. > > The wording of this sounds as though it would allow a few octets from the > MPLS stack (not all) then a few octets from the payload. The previous > description isn't so bad as it doesn't talk about n octets of the header. > > I would prefer something like: > This information element carries a series of octets from the start of > of the IP header of a sampled packet. The size of the packet section > is controlled by the PSAMP device and MAY continue into the payload. > > The element MUST NOT contain any padding and if the PSAMP device is > configured to stop after n octets, at the end of the IP header or > after m octets of payload, the size of the field must be adjusted > to match the number of bytes exported using either a variable length > field or a template containing a field of the correct size. > > regards > > Andrew > > > 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. > > -- > 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/> -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany
Attachment:
smime.p7s
Description: S/MIME cryptographic signature