Subject: [IPFIX] IPFIX length fields

From: Paul Aitken <[email-masked]>
Date: Thu, 01 Mar 2012 23:07:08 +0000

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

---

From: Brian Trammell <[email-masked]>
Date: Fri, 2 Mar 2012 00:24:03 +0100

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.

Does this indicate a need to clarify the applicability of quantity vs no semantics in 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".
> 
> Or better, that all lengths be changed to semantics of "quantity", since RFC5102 says,
> 3.2.1.  quantity
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Thu, 01 Mar 2012 23:52:51 +0000

Brian,

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

---

From: Brian Trammell <[email-masked]>
Date: Fri, 2 Mar 2012 08:14:47 +0100

Hi, Paul,

>> Does this indicate a need to clarify the applicability of quantity vs no semantics in 5102bis?

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

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

>     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

>>>    of a given record.  
>>>    If no semantic qualifier is given, the

---

From: Paul Aitken <[email-masked]>
Date: Fri, 02 Mar 2012 09:50:58 +0000

Brian,

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

> 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, wh…

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

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

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.

>        "dateTimeNanoseconds", "ipv4Address", or "ipv6Address").

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

Thanks,
P.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 2 Mar 2012 13:22:55 +0100

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

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

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

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

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

> 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

---

From: Paul Aitken <[email-masked]>
Date: Fri, 02 Mar 2012 12:32:20 +0000

Brian,

...

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

Yes, please list the issues.

We can discuss them in Paris, if not sooner.

P.

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 2 Mar 2012 13:25:32 +0000

Hi all,

I agree that we should remove "quantity" from the observationTime* IEs.

Saying this, I am aware that these indeed are quantities specifying
the number of nano/micro/milliseconds since a given point in time.

But their semantics is sufficiently specified by their type.
The semantics of "quantity" does not add to clarifying its semantics.
That's why it rather should be removed.

Thanks,
    Juergen

On 02.03.12 00:52, "Paul Aitken" <[email-masked]> wrote:

>
>  
>  
>    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. 
>
>[email-masked]://www.ietf.org/mailman/listinfo/ipfix
>      
>
>      
>    
>
>    
>  
>

---

From: Andrew Feren <[email-masked]>
Date: Mon, 05 Mar 2012 16:43:04 -0500

On 03/02/2012 04:50 AM, Paul Aitken wrote:
>> 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.)
>

Agreed.  If the semantics can be stated they should.

---

From: Andrew Feren <[email-masked]>
Date: Tue, 06 Mar 2012 13:49:03 -0500

> Hi, Paul,
[ snip ]
> 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…
I'd be in favor of updating the guidelines.  I would think that at least 
"identifier" could apply to octetArray, macAddress, string, ipv4Address, 
and/or ipv4Address.  For the addresses I think it would always apply.

I don't currently have a preference of erratum vs 5102bis.

-Andrew

---

From: Chris Inacio <[email-masked]>
Date: Wed, 28 Mar 2012 07:33:10 -0400

I vote to keep IPaddress as a semantic type.  Because I can do things like masking / subnetting, etc. when it is an IPAddress - but I don't think about doing that with an identifier.

We are currently implementing stuff the depends on IP (v4/v6) as a semantic meaning.

I assume I can do pretty much *nothing* intelligent operationally, masking, flags, ranges, summation, etc.  with identifier.  Only key matching.  But I know I can do more with an IP address.

Chris

On Mar 1, 2012, at 6:07 PM, Paul Aitken wrote:

> <ATT00001.c>

---

From: Andrew Feren <[email-masked]>
Date: Thu, 29 Mar 2012 11:32:45 -0400

Hi Chris,

The datatype is IPAddress.  Why do you also need a semantic type of 
IPAddress?

-Andrew