Re: [IPFIX] IPFIX length fields

Brian,

> Hi, Paul,
>
> On Mar 2, 2012, at 12:52 AM, Paul Aitken wrote:
>
>>> Does this indicate a need to clarify the applicability of quantity vs no semantics in 5102bis?
>>>
>> Yes, it seems so.
> Would there be a problem simply with striking quantity completely, and noting what the meaning of "no semantics" is?
>
> (Indeed, the meaning of "no semantics" is type-dependent. Addresses are always identifiers. Numbers are usually quantities. And so on.)

Rather than leave the semantics blank, with a hidden note elsewhere 
about what that means, we should aim to give semantics for each IE.


>> Some other inconsistencies:
>>
>> Boolean may be an identifier, it can't be a quantity:
>>
>>      276  dataRecordsReliability  boolean  identifier
>>      333  hashDigestOutput  boolean  quantity
> Agreed on quantity. Not clear to me what a boolean identifier is. "This is the thing you're looking for!" "This is not the thing you're looking for"... dataRecordsReliability is a (single) flag, which is (or should be) the default semantics for boolean.

I convinced myself that it's a True / False identifier.
In this specific case, it identifies whether or not data records are 
reliable.

"Quantity" suggests, "Yes, there is some hashDigestOutput" ??


>> 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
> As addresses are only ever identifiers, should these not be no semantics?

No, they should say "identifier".

Else you're expecting the registry reader to understand that no 
semantics (an empty box) also has a meaning, and check the RFCs to 
discover what it is.


> RFC 5610 has a section 3.10 on restrictions in export of semantics per data type; this was extracted from (a subset of) the Information Element registry at the time (note that "default" here is the description of the codepoint for "no semantics")

Then perhaps the registry should say "default" rather than having a 
blank box - though it would be better to explicitly state the default 
for each.


> 3.10.  Data Type and Semantics Restrictions
>
>     Note that the informationElementSemantics values defined in Section
>     3.2 of [RFC5102] are primarily intended to differentiate semantic
>     interpretation of numeric values, and that not all combinations of
>     the informationElementDataType and informationElementSemantics
>     Information Elements are valid; e.g., a counter cannot be encoded as
>     an IPv4 address.  The following are acceptable values of
>     informationElementSemantics:
>
>     o  Any value is valid for unsigned informationElementDataType values
>        ("unsigned8", "unsigned16", "unsigned32", or "unsigned64").
>
>     o  Any value except "flags" is valid for signed
>        informationElementDataType values ("signed8", "signed16",
>        "signed32", or "signed64").
>
>     o  Any value except "identifier" or "flags" is valid for floating-
>        point informationElementDataType values ("float32" or "float64").
>
>     o  Only "default" is valid for all other informationElementDataType
>        values ("octetArray", "boolean", "macAddress", "string",
>        "dateTimeSeconds", "dateTimeMilliseconds", "dateTimeMicroseconds",
>        "dateTimeNanoseconds", "ipv4Address", or "ipv6Address").

When you say, "any value", you're assuming that no new semantics are added.


> In the interests of self-consistency, I would suggest that cleanup should follow those guidelines, or the guidelines themselves should be updated by an erratum and/or moved into 5102bis and updated there.

Thanks,
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