Subject: [ipfix-protocol] new version of the IPFIX protocol draft:draft-ietf-ipfix-protocol-18.txt

From: Benoit Claise <[email-masked]>
Date: Fri, 05 Aug 2005 17:05:45 +0200

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.