Re: [IPFIX] [Sender: [email protected]] initiatorOctets/initiatorPackets/responderOctets/responderPackets change

Brian,

1. Some mistake in the numbering in your new definitions: you've written 
232 and 233 instead of 231 and 232.

2. What's the significance of "app" in these names? "Applicable"? 
"Application"? "Appearing"? "Appended"? "Approved"? "Appropriate"? 
"Approximate"? ...

P.


On 16/05/13 16:45, Brian Trammell wrote:
> Greetings, all,
>
> Following a previous suggestion to update  propose we modify the names and definitions of the initiatorOctets(231), responderOctets(232), initiatorPackets(298), and responderPackets(299) as follows, (1) to bring them in line with the naming of other IPFIX Information Elements, (2) to allow them to be used by RFC 5103-compliant biflow Exporting Processes, and (3) to ensure (especially in the case of 298 and 299) that the descriptions are interoperably implemented.
>
> I think the proposed descriptions reflect the intent of the present descriptions, within the context of RFC 5103 terminology, and should therefore not have any impact on interoperability; I note that the description of IEs 298 and 299 are, however, not decipherable as written, so I may be taking some necessary liberty with my interpretation.
>
>
> Element ID: 232
> Name:       appOctetDeltaCount
> Data Type:  unsigned64
> Semantics:  deltaCounter
> Description:
>
> The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any).
>
>
> Element ID: 233
> Name:       reverseAppOctetDeltaCount
> Data Type:  unsigned64
> Semantics:  deltaCounter
> Description:
>
> The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appOctetDeltaCount, causes appOctetDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope.
>
>
> Element ID: 298
> Name:       appPacketDeltaCount
> Data Type:  unsigned64
> Semantics:  deltaCounter
> Description:
>
> The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any).
>
>
> Element ID: 299
> Name:       reverseAppPacketDeltaCount
> Data Type:  unsigned64
> Semantics:  deltaCounter
> Description:
>
> The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appPacketDeltaCount, causes appPacketDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope.
>
>
> Following discussion on the list, I intend to submit this proposed change to the IE-DOCTORS for review.
>
> Thoughts?
>
> Many thanks, best regards,
>
> Brian
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix