Brian, Gerhard,

Thanks for spotting this.
Here are the changes we should be applying... to the AUTH48 IMHO.

10.3.2  Reliability 
OLD:

   The Collecting Process SHOULD deduce the loss and reordering of 
   IPFIX Data Records by looking at the discontinuities in the IPFIX 
   Message sequence number. In the case of UDP, the IPFIX Message 
   sequence number contains the total number of IPFIX Data Records 
   received for the UDP association, prior to the receipt of this IPFIX 
   Message, modulo 2^32.  A Collector SHOULD detect out of sequence, 
   dropped, or duplicate IPFIX Messages by tracking the Sequence 
   Number.  

NEW:

   The Collecting Process SHOULD deduce the loss and reordering of 
   IPFIX Data Records by looking at the discontinuities in the IPFIX 
   Message sequence number. In the case of UDP, the IPFIX Message 
   sequence number contains the total number of IPFIX Data Records 
   _sent_ for the UDP _Transport Session_, prior to the receipt of this IPFIX 
   Message, modulo 2^32.  A Collector SHOULD detect out of sequence, 
   dropped, or duplicate IPFIX Messages by tracking the Sequence 
   Number.  


 10.4.2.1 IPFIX Message Encoding

OLD 
    
   In the case of TCP, the IPFIX Message sequence number contains the 
   total number of IPFIX Data Records received for the TCP connection, 
   prior to the receipt of this IPFIX Message, modulo 2^32.  

NEW
    
   In the case of TCP, the IPFIX Message sequence number contains the 
   total number of IPFIX Data Records _sent from this TCP connection, 
   from the current Observation Domain by the Exporting Process, _
   prior to the receipt of this IPFIX Message, modulo 2^32.  


(ii) There seem to be three different writings for the Sequence Number in


    protocol-24:"IPFIX Message sequence number"
    "Sequence Number"
    "IPFIX Sequence Number"
    "sequence number"

    Maybe we should only use "Sequence Number" and "IPFIX Sequence Number"
    when a specific discrimination from other transport layer sequence
    numbers
    is required.

Agreed.

Regards, Benoit


> Gerhard,
>
> In short, I agree. Specific comments inline:
>
> Gerhard Muenz wrote:
>   
>> There are two other inconsistencies (or am I wrong?):
>>
>> (i) Concerning the value of the Sequence Number:
>>
>> 3.1: "IPFIX Data Records sent"
>> 10.3.2: "IPFIX Data Records received"
>> 10.4.2.1: "IPFIX Data Records received"
>>
>> I think it is better to always write "IPFIX Data Records sent" because the
>> field is set by the exporter and not by the collector.
>>     
>
> Agreed. (Also, in 10.3.2 para 2, the document scopes the sequence number
> to a "UDP association", which should be a "UDP Transport Session").
>
>   
>> (ii) There seem to be three different writings for the Sequence Number in
>> protocol-24:
>>
>> "IPFIX Message sequence number"
>> "Sequence Number"
>> "IPFIX Sequence Number"
>> "sequence number"
>>
>> Maybe we should only use "Sequence Number" and "IPFIX Sequence Number"
>> when a specific discrimination from other transport layer sequence numbers
>> is required.
>>     
>
> The protocol document does not appear to mention TCP Sequence or SCTP
> Transport Sequence or Stream Sequence numbers, so omitting "IPFIX" from
> "Sequence Number" within the document is acceptable (especially in
> paragraphs and/or short sections mentioning the sequence number more
> than once). However, "IPFIX Message sequence number" would seem to imply
> that the numbers increment per message, not per record. So, yes, I'd
> agree that we should use "[IPFIX] Sequence Number" everywhere.
>
> Regards,
>
> Brian
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipfix
>   

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www1.ietf.org/mailman/listinfo/ipfix