I reviewed draft-ietf-ipfix-protocol-26.txt as part of the Transport Area review effort. I did not find any particular issues in the described technology - a few nits: section 3.1 "Export Time" someday the IETF needs to stop using 32-bit "seconds since 1 jan 1970" for timing - at least within in the next 31 years section 6.1.2 - it might be reasonable to add the IEEE 8-byte MAC address as an address type - this is used in ZigBee and may be in wider use in the future section 10.3.3 - a max packet size of 1280 could be used if the connection is known to be running in an IPv6-only environment I'm not sure why the packet size discussion is only listed for UDP - it seems like the same restriction should apply to all protocols - fragmentation is not your friend Historically the biggest issue with IPFIX has been that most implementers want to run it over UDP with consequences be dammed. - this was weaseled in the IPFIX Requirements document (RFC 3917) by requiring (in section 6.3.1) that "For the data transfer, a congestion aware protocol must be supported." This draft meets that requirement by making the implementation of SCTP a MUST. That will not stop many implementers from ignoring the requirement for implementation or users to enable UDP and thus creating a potentially very high bandwidth non-congestion avoiding fire hose that can quite easily wipe out a net by misconfiguration or become a DoS engine by purposeful configuration. I'm not sure if anything can be actually be done about this risk - It might help some to say that UDP is a "MUST NOT" but I doubt it - in any case it would help somewhat, imho, to expand section 10.3 to be clearer about the threats posed by any use of a non-congestion avoiding transport protocol or to do that in the Security Considerations section Scott _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf