Subject: Re: [IPFIX] [IANA #579482] General Request for Assignment (ipfix)

From: Nevil Brownlee <[email-masked]>
Date: Thu, 12 Jul 2012 14:41:58 +1200

Hi Amanda:

These four IEs aren't in the registry yet, please add them.

Cheers, Nevil

On 19/06/12 11:08 AM, Nevil Brownlee wrote:
>
> Hi again Amanda:
>
> These four have been discussed on the IPFIX list, they're OK as
> submitted. They'll be
>
>    361  portRangeStart
>    362  portRangeEnd
>    363  portRangeStepSize
>    364  portRangeNumPorts
>
> Cheers, Nevil
>
>
> On 12/06/12 8:51 AM, Amanda Baber via RT wrote:
>> Hi Nevil,
>>
>> Here's Paul's second request.
>>
>> thanks,
>> Amanda
>>
>> ===
>>
>> Contact Name:
>> Paul Aitken
>>
>> Contact Email:
>> [email-masked]
>>
>> Type of Assignment:
>> IPFIX Information Elements
>>
>> Registry:
>> http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-elements
>>
>>
>> Description:
>> Please allocate the four new fields specified below, which may be used
>> in various combinations to specify port ranges in IPFIX.
>>
>> Additional Info:
>> Name: portRangeStart
>> Type: unsigned16
>> Semantics: identifier
>> Description: The port number identifying the start of a range of ports.
>> A value of zero indicates that the range start is not specified, ie the
>> range is defined in some other way.
>> Additional information on defined TCP port numbers can be found at [IANA
>> registry port-numbers].
>>
>> Name: portRangeEnd
>> Type: unsigned16
>> Semantics: identifier
>> Description: The port number identifying the end of a range of ports.
>> A value of zero indicates that the range end is not specified, ie the
>> range is defined in some other way.
>> Additional information on defined TCP port numbers can be found at [IANA
>> registry port-numbers].
>>
>> Name: portRangeStepSize
>> Type: unsigned16
>> Semantics: identifier
>> Description: The step size in a port range. The default step size is 1,
>> which indicates contiguous ports.
>> A value of zero indicates that the step size is not specified, ie the
>> range is defined in some other way.
>>
>> Name: portRangeNumPorts
>> Type: unsigned16
>> Semantics: identifier
>> Description: The number of ports in a port range.
>> A value of zero indicates that the number of ports is not specified, ie
>> the range is defined in some other way.
>
>

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Andrew Feren <[email-masked]>
Date: Mon, 16 Jul 2012 15:50:48 -0400

Are the semantics for these really "identifier"?

-Andrew

---

From: Paul Aitken <[email-masked]>
Date: Mon, 16 Jul 2012 21:21:52 +0100

Andrew,

> Are the semantics for these really "identifier"?

Per RFC5610 and RFC6313, there are just 7 semantics to choose from. See 
http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-element-semantics.

Note that a standards action is required to introduce new semantics.

361 and 362 are port numbers. Notice that the semantics for all the 
other port elements (sourceTransportPort, destinationTransportPort, 
udpSourcePort, udpDestinationPort, tcpSourcePort, tcpDestinationPort, 
collectorTransportPort, exporterTransportPort, 
postNAPTSourceTransportPort, and postNAPTDestinationTransportPort) are 
all "identifier", since the value identifies a port.

363 and 364 are simple numbers. If "identifier" is not appropriate for 
these, then "default" is the only other possibility.

P.

> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Andrew Feren <[email-masked]>
Date: Mon, 16 Jul 2012 16:43:17 -0400

Hi Paul,

> Note that a standards action is required to introduce new semantics.

Understood.

> all "identifier", since the value identifies a port.

I agree that 361 and 362 are port numbers which are identifiers.  My 
thinking, however, was that none of these are really identifiers 
individually.  Information Element Ids are identifiers too, but 
informationElementRangeBegin (342) and informationElementRangeEnd (343) 
have semantics of 'quantity' (which is neither 'default' nor 
'identifier'.  :-)

Should informationElementRangeBegin and informationElementRangeEnd have 
semantics of 'default'?

Now that I am typing this I think we covered some of this ground before 
in this thread 
(https://www.ietf.org/mail-archive/web/ipfix/current/msg06269.html). I 
don't yet have a strong opinion on what the right answer is.  I just got 
curious while I was reviewing information elemnts that had been added 
since the last time I pulled the list.

-Andrew

---

From: Paul Aitken <[email-masked]>
Date: Mon, 16 Jul 2012 22:04:20 +0100

Andrew,

>> postNAPTSourceTransportPort, and postNAPTDestinationTransportPort) 
>> are all "identifier", since the value identifies a port.
>
> informationElementRangeBegin (342) and informationElementRangeEnd 
> (343) have semantics of 'quantity' (which is neither 'default' nor 
> 'identifier'.  :-)

5101 says:

        3.2.1 <http://tools.ietf.org/html/rfc5102#section-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.*

        3.2.4 <http://tools.ietf.org/html/rfc5102#section-3.2.4>. identifier

    An integral value that serves as an identifier.  Specifically,
    *mathematical operations on two identifiers (aside from the equality
    operation) are meaningless.*   For example, Autonomous System ID 1 *
    Autonomous System ID 2 is meaningless.

(My bolding).

So, per 3.2.1, the default semantic is "quantity". However, since 
mathematical operations on port numbers are meaningless (other than 
equality and comparisons), my feeling is that "identifier" is more 
appropriate.

Thus the clue is in the definition, "The port number *identifying* the 
start of a range of ports." -> it's a number which identifies a port, 
rather than the value of some physical property of the port.

However, if the WG disagrees then I'm not strongly opposed to changing it.

> Should informationElementRangeBegin and informationElementRangeEnd 
> have semantics of 'default'?

Good question. It seems there should be consistency here.

> Now that I am typing this I think we covered some of this ground 
> before in this thread 
> (https://www.ietf.org/mail-archive/web/ipfix/current/msg06269.html).

What was the outcome of that thread? I found, "lets discuss this in 
Paris". However, I don't recall it being on the WG agenda.

> I don't yet have a strong opinion on what the right answer is.  I just 
> got curious while I was reviewing information elemnts that had been 
> added since the last time I pulled the list.

How often do you update? I have multiple tickets open with IANA. I'll 
try to announce to the WG list when I request new fields. However, note 
that WG discussion / consensus isn't part of the 5102 / expert review 
process.

P.

---

From: Andrew Feren <[email-masked]>
Date: Mon, 16 Jul 2012 17:56:06 -0400

Paul,

On 07/16/2012 05:04 PM, Paul Aitken wrote:

[ snip ]
> Paris". However, I don't recall it being on the WG agenda.

I don't recall any final outcome of that thread.
>
>
>> I don't yet have a strong opinion on what the right answer is.  I 
>> just got curious while I was reviewing information elemnts that had 
>> been added since the last time I pulled the list.
>
> try to announce to the WG list when I request new fields. However, 
> note that WG discussion / consensus isn't part of the 5102 / expert 
> review process.
No fixed schedule.  I generally pull the list at the start of each major 
release cycle.  I may also merge changes from IANA for a minor release 
if I get a bug report for an information element that is missing or not 
decoding correctly.

I'll keep an eye out for your other new fields.

Thanks,
-Andrew