Dear all,

Thanks for the feedback during the IPFIX interop and during the IPFIX WG meeting.
Here is the list of all protocol points discussed (the order is the one from the presentation by Elisa), along with their resolutions.

1. Variable Length Information Element Clarification
The new text is:
If the length of the Information Element is less than 255 octets, the length is carried in the octet before the Information Element, as shown in Figure R. If the length of the Information Element is greater than or equal to 255 octets, the length is encoded into 3 octets before the Information Element. The first octet is 255 and the length is carried in the second and third octets, as shown in Figure S. The octets carrying the length (either the first or the first three octets) MUST NOT be included in the length of the Information Element.

Examples for the Variable length Information Element added in: - 13.5 Variable length Information Element examples. - 13.5.1 Example of Variable Length Information Element with length < 255 octets. - 13.5.2 Example of Variable Length Information Element with length 255 to 65535 octets. 2. Compression Data Types New text:

If reduced sizing is used, it MUST be applied only to following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, signed.  The same signed versus unsigned properties MUST be preserved.  The downcasting can be to any smaller number of bytes.  For example, an unsigned64 can be downcasted to 1, 2, 3, 4, 5, 6 or 7 bytes.

The dateTimeMicroSeconds and dateTimeNanoSeconds MUST NOT be downcasted because they represent an inherent structure that would be destroyed by downcasting them.

3. Templates and Option Template withdraw messages can't contain new template definitions. New Text:

The Template Withdraw Message MUST NOT contain new Template or Option Template Records.

This new text also takes care of the issue "template withdraw message for all templates can't contain new template definitions" 4. The collector should interpret a template withdraw message with an unknown template as a error. New Text:

If the Collecting Process receives a Template Withdraw message for a Template Record it has not received before, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages. 

5. UDP template refresh If a Template is refreshed with a Template that differs from the previous received Template the Collecting Process SHOULD log a warning and replace the previous received Template with the new one. 6. Length. - variable length should allows 0 -> The protocol spec. are unchanged: - normal I.E. should tolerates 0 -> Remove "The Field Length MAY NOT be 0." from the Field Length definition. Anyway this statement was very confusing. What does "MAY NOT" mean? - Set length with length 0 is not possible All corner cases should be discussed in the implementation guidelines. 7. How to handle identical information elements in the same data records. Consensus is that we don't want to limit the protocol for now. So nothing to change in [IPFIX-PROTO] The next issues were not part of the IPFIX interop feedback. 8. dateTimeNanoSeconds and precision discussion (http://ipfix.doit.wisc.edu/archive/2891.html) The new text for dateTimeSeconds, dateTimeMilliSeconds, dateTimeNanoSeconds, and dateTimeMicroSeconds has been updated in the section 6.1.6., 6.1.7, 6.1.8, and 6.1.9 respectively 9. IANA port 4739. I corrected the text for TCP and UDP, but we still have no news about SCTP. So there are in the draft still 2 occurrences of "(EDITOR NOTE: to be assigned by IANA). " 10. Sequence Number New definition, to make it consistent with the rest of the draft. Incremental sequence counter modulo 232 of all IPFIX Data Records sent on this stream from the current Observation Domain by the Exporting Process. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Option Template Records do not increase the Sequence Number. Regards, Benoit.