Re: [IPFIX] IPFIX length fields

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

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

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

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

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

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.

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