Subject: Re: [IPFIX] "ID" in Information Element names

From: Andrew Feren <[email-masked]>
Date: Wed, 14 Nov 2012 17:38:38 -0500

Hi Paul,

It occurs to me that if well known names keep their case then there is a 
case for using "AS" in

16 	bgpSourceAsNumber 	unsigned32 	identifier 	current 	

The autonomous system (AS) number of the source IP address. If AS path 
information for this Flow is only available as an unordered AS set (and 
not as an ordered AS sequence), then the value of this Information 
Element is 0.

See [RFC4271 <http://www.iana.org/go/rfc4271>] for a description of 
BGP-4, and see [RFC1930 <http://www.iana.org/go/rfc1930>] for the 
definition of the AS number.

	[RFC5102 <http://www.iana.org/go/rfc5102>]
17 	bgpDestinationAsNumber 	unsigned32 	identifier 	current 	

The autonomous system (AS) number of the destination IP address. If AS 
path information for this Flow is only available as an unordered AS set 
(and not as an ordered AS sequence), then the value of this Information 
Element is 0.

See [RFC4271 <http://www.iana.org/go/rfc4271>] for a description of 
BGP-4, and see [RFC1930 <http://www.iana.org/go/rfc1930>] for the 
definition of the AS number.

	[RFC5102 <http://www.iana.org/go/rfc5102>]

and

128 	bgpNextAdjacentAsNumber 	unsigned32 	identifier 	current 	

The autonomous system (AS) number of the first AS in the AS path to the 
destination IP address. The path is deduced by looking up the 
destination IP address of the Flow in the BGP routing information base. 
If AS path information for this Flow is only available as an unordered 
AS set (and not as an ordered AS sequence), then the value of this 
Information Element is 0.

See [RFC4271 <http://www.iana.org/go/rfc4271>] for a description of 
BGP-4, and see [RFC1930 <http://www.iana.org/go/rfc1930>] for the 
definition of the AS number.

	[RFC5102 <http://www.iana.org/go/rfc5102>]
129 	bgpPrevAdjacentAsNumber 	unsigned32 	identifier 	current 	

The autonomous system (AS) number of the last AS in the AS path from the 
source IP address. The path is deduced by looking up the source IP 
address of the Flow in the BGP routing information base. If AS path 
information for this Flow is only available as an unordered AS set (and 
not as an ordered AS sequence), then the value of this Information 
Element is 0. In case of BGP asymmetry, the bgpPrevAdjacentAsNumber 
might not be able to report the correct value.

See [RFC4271 <http://www.iana.org/go/rfc4271>] for a description of 
BGP-4, and see [RFC1930 <http://www.iana.org/go/rfc1930>] for the 
definition of the AS number.

	[RFC5102 <http://www.iana.org/go/rfc5102>]

The uppercase version is used in the description.

Just thinking,
-Andrew

On 10/23/2012 09:51 AM, Paul Aitken wrote:
> Thanks Brian and Andrew.
>
> I've asked IANA to rename "applicationId" and "natPoolId" for 
> consistency with the other fields.
>
> I'll leave wlanSSID, ingressVRFID, egressVRFID, and virtualStationUUID 
> unchanged.
>
> P.
>
>
> On 23/10/12 14:30, Andrew Feren wrote:
>> Hi Paul and Brian,
>>
>> I agree on renaming applicationId and natPoolId and keeping UUID.
>>
>> My personal bias is to also keep VRFID, but I can't claim any 
>> evidence that is an established term.  I just prefer to keep it upper 
>> case, but I won't object either way.
>>
>> -Andrew
>>
>>
>> On 10/23/2012 08:43 AM, Brian Trammell wrote:
>>> Hi, Paul,
>>>
>>> UUID is an established term too, no? So we should keep that as is.
>>>
>>> Not sure about VRF.
>>>
>>> I'd rename applicationId and natPoolId.
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>> On Oct 23, 2012, at 2:25 PM, Paul Aitken <[email-masked]> wrote:
>>>
>>>> I've just been looking at how inconsistently "ID" and "Id" are used 
>>>> for IE names.
>>>>
>>>> Since the bulk of the existing names are "...Id", can we assume 
>>>> that the following are all good:
>>>>
>>>> vlanId
>>>> postVlanId
>>>> classificationEngineId
>>>> commonPropertiesId
>>>> observationPointId
>>>> lineCardId
>>>> portId
>>>> meteringProcessId
>>>> exportingProcessId
>>>> templateId
>>>> wlanChannelId
>>>> flowId
>>>> observationDomainId
>>>> dot1qVlanId
>>>> dot1qCustomerVlanId
>>>> metroEvcId
>>>> pseudoWireId
>>>> postDot1qVlanId
>>>> postDot1qCustomerVlanId
>>>> exportSctpStreamId
>>>> connectionTransactionId
>>>> selectionSequenceId
>>>> selectorId
>>>> informationElementId
>>>> virtualStationInterfaceId
>>>> layer2SegmentId
>>>>
>>>>
>>>> And that the following should change? :
>>>>
>>>> applicationID -> applicationId
>>>> natPoolID     -> natPoolId
>>>>
>>>>
>>>> Finally, I'm not sure about the following:
>>>>
>>>> wlanSSID           -> "SSID"seems to be an established term.
>>>> ingressVRFID       -> should it be "VRFId" ?
>>>> egressVRFID        -> should it be "VRFId" ?
>>>> virtualStationUUID ->should it be "UUId" ?
>>>>
>>>>
>>>>
>>>> Feedback?
>>>>
>>>> Thanks,
>>>> P.
>>>> _______________________________________________
>>>> IPFIX mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>> _______________________________________________
>>> IPFIX mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipfix
>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Wed, 14 Nov 2012 22:54:28 +0000

Andrew,

I agree. There seems to be some inconsistency here.

IPFIX-doctors says:

    o  use capital letters for the first letter of each component except
       for the first one (aka "camel case").  All other letters are non-
       capitalized, even for acronyms.  Exceptions are made for acronyms
       containing non-capitalized letters, such as 'IPv4' and 'IPv6'.
       Examples are "sourceMacAddress" and "destinationIPv4Address."

So it seems that:

     "wlanSSID" should be "wlanSsid"
     "ingressVRFID should be "ingressVrfId"
     "egressVRFID should be "egressVrfId"
     "virtualStationUUID" should be "virtualStationUuid".

- which all look wrong.

Else, the IPFIX-doctors rule should be relaxed to allow the existing 
names. Or, it should allow reviewer discretion.

Thanks,
P.

On 14/11/12 22:38, Andrew Feren wrote:
> Hi Paul,
>
> It occurs to me that if well known names keep their case then there is 
> a case for using "AS" in
>
> information for this Flow is only available as an unordered AS set 
> (and not as an ordered AS sequence), then the value of this 
> path information for this Flow is only available as an unordered AS 
> set (and not as an ordered AS sequence), then the value of this 
> The autonomous system (AS) number of the first AS in the AS path to 
> the destination IP address. The path is deduced by looking up the 
> destination IP address of the Flow in the BGP routing information 
> base. If AS path information for this Flow is only available as an 
> unordered AS set (and not as an ordered AS sequence), then the value 
> of this Information Element is 0.
>
> 	
> 	
> 	
>
> The autonomous system (AS) number of the last AS in the AS path from 
> the source IP address. The path is deduced by looking up the source IP 
> information for this Flow is only available as an unordered AS set 
> (and not as an ordered AS sequence), then the value of this 
> Information Element is 0. In case of BGP asymmetry, the 
> bgpPrevAdjacentAsNumber might not be able to report the correct value.
>
> 	
> 	
> 	
>