Re: [IPFIX] IPFIX length fields
Paul Aitken <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Brian,
> Hi, Paul, Nick,
>
> It appears that "quantity" is applied a little haphazardly (indeed, "observationTime*" has quantity semantics which doesn't seen quite right), but that none of the IEs with explicit quantity semantics is a length.
>
> So in the interests of "make things internally consistent", I'd say that these should be changed to no semantics.
See my quote below from 5102 about no semantics == quantity.
> Does this indicate a need to clarify the applicability of quantity vs no semantics in 5102bis?
Yes, it seems so.
Some other inconsistencies:
Boolean may be an identifier, it can't be a quantity:
276 dataRecordsReliability boolean identifier
333 hashDigestOutput boolean quantity
These all have no semantics. They should be "identifier":
44 sourceIPv4Prefix ipv4Address
45 destinationIPv4Prefix ipv4Address
169 destinationIPv6Prefix ipv6Address
170 sourceIPv6Prefix ipv6Address
281 postNATSourceIPv6Address ipv6Address
282 postNATDestinationIPv6Address ipv6Address
P.
> On Mar 2, 2012, at 12:07 AM, Paul Aitken wrote:
>
>> Dear all,
>>
>> Reviewing IANA's IPFIX field list, we noticed that most of the *length fields have no semantics.
>>
>> However, mplsTopLabelPrefixLength has semantics of "identifier", while ethernetHeaderLength, ethernetPayloadLength, ethernetTotalLength have semantics of "identifier".
>>
>> We propose that these all be changed to no semantics.
>>
>> Or better, that all lengths be changed to semantics of "quantity", since RFC5102 says,
>> 3.2.1. quantity
>>
>> A quantity value represents a discrete measured value pertaining to
>> the record. This is distinguished from counters that represent an
>> ongoing measured value whose "odometer" reading is captured as part
>> of a given record.
>> If no semantic qualifier is given, the
>> Information Elements that have an integral data type should behave as
>> a quantity.
>>
>>
>> Feedback?
>>
>> Thanks,
>> Paul and Nick
>> _______________________________________________
>> IPFIX mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipfix
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix