Hi Andrew,Of course, the psamp-info draft does not restrict me since I can always define my own IEs. It's just that having such an IE in the standard would have looked natural to me.
Cheers, Gerhard Andrew Johnson wrote:
Hi Gerhard If I recall correctly, the packet section fields were defined to meet the PSAMP requirements and provide a minimum requirement for the basic packet reports. The extended packet reports can contain any information you like as long as you have an IE for it, so I hope you don't feel that the current PSAMP drafts will restrict what you want to do. Some more inline: Gerhard Muenz wrote:A generic transport payload IE is not feasible because to implement properly an implementation would have to understand and parse all transport protocols, including ones which are yet to be defined.I thought of a generic transportPayloadPacketSection similar to the sourceTransportPort that exists besides udp|tcpTransportPort. In any case, a monitor would only export the information it is able to retrieve from a packet.Sure, but the sourceTransportPort is restricted to specifically TCP, UDP and SCTP. Where is gets a bit woolly, and the part I don't like, is the option to use it for future protocols, which could lead to different implementations of the protocol doing different things for the same traffic. I think that all our IEs should have very solid definitions.Apart from the generic type, is there any argument against IEs for udp|tcpPacketPayloadSection? Since IEs for almost all UDP/TCP header fields exist, the payload type would cover the remaining unparsed packet data.If a new IE was created to cover UDP, TCP and SCTP payloads then I suppose that would be fine. The option to use it with future types is debatable but I wouldn't object if it was consistent with the transportSourcePort field. [SNIP]If you, or anyone, has an application that would require that PSAMP beextended in some way then please mail the list details of the applicationand we can discuss the best way to address the requirements, possibly requesting new IEs as needed. Don't forget, however, that new IEs can be requested at any time in the future, so we don't have to cover all cases right now.An application I'm working on is signature detection on sampled packets.OK, to summarise then. Would I be right in saying that current PSAMP draftsmeet your requirements with the basic packet reports, and could be met more efficiently with certain extended packet reports? To be more efficient still you want a new IE for just the TCP or UDP (and maybe SCTP) payload? In which case I would say that this new IE doesn't specifically belong in the PSAMP drafts, it is merely one of the many IEs that can be used in an extended packet report. That said, the IE may be relevant and generally useful enough to be included in the PSAMP drafts as a good candidate for extended packet reports. The alternative is for you to request the IE yourself on the IPFIX mailing list. Cheers Andrew
-- Dipl.-Ing. Gerhard Münz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science, University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature