Re: [IPFIX] IPFIX length fields

On Mar 2, 2012, at 10:50 AM, Paul Aitken wrote:

> 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.

Okay. So let's figure out how we want to express that then update the registry.

>>> 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.

I'd read that as "this is the reliable record." Fits the definition of "identifier" if that definition is a little stretchy.

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

"Quantity" suggests a typographical error IMO.

>>> 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.

Good point. That wouldn't particularly make things easier.

>> 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.

Absolutely. This belongs in 5102bis, I think. 

>> 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.

Sorry, I cut the last part of the section, which says:

   Future Standards Actions that modify the Information Element Data
   Type subregistry or the Information Element Semantics subregistry
   should contain a Data Type and Semantics Restrictions section such as
   this one to define allowable combinations of type and semantics
   information.

However, that's not quite restrictive enough, because it also assumes no new types are added. (I personally think that semantics are more likely to be added than types, but we should be thorough.)

Shall I add this as an open issue on 5102bis?

Cheers,

Brian

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