Re: [IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03

On 07/11/2013 18:28, Juergen Schoenwaelder wrote:
> On Thu, Nov 07, 2013 at 06:02:01PM +0000, Colin McDowall wrote:
>>
>>> (3) Clarifying and SNMP-naif question on 11.2.2 mibObjectIdentifier: it
>>> seems from the examples that the intention is that the OID will be
>>> encoded in the document as a Unicode string of digits and "."
>>> characters? Is this the way OIDs are encoded in SNMP? The encoding of
>>> fundamentally binary data in strings is not very IPFIXish (7013 section
>>> 4.2 para 6), and I kind of expected these to be encoded as octetarrays
>>> of unsigned integers of a specified size, or something similar. However,
>>> if encoding-as-string is how things are done on the wire in SNMP, it's
>>> the right thing to do here too (7013 section 4.5). The same comment
>>> applies to 11.2.4.
>>>
>>
>> This is carried over from the previous versions of the draft so I'm
>> not sure about the background on the choice.
>>
>> I agree that encoding the mibObjectIdentifier in the same format as
>> SNMP might be ideal as we would have a complete definition in
>> another RFC.
>>
>> Sending the OID as a string is 'simpler' but potentially
>> wasteful. On the other hand a lot of the sub-identifiers are short
>> and would be more efficient as a single character than a 32bit
>> number.
>
> Once again, each sub-identifier (except the first two) can be an
> unsigned32 number. SNMP uses BER encoding and using BER encoding,
> smaller numbers need less space. For most of the small sub-identifiers
> (range 0-127), you only need one octet in BER and there are no
> separators (hence they will be about 50% of the length of a string
> representation). For larger sub-identifier, the savings may be even
> more significant (but they are less frequent, although private OIDs
> usually have at least one larger sub-identifier, the enterprise ID,
> except for those companies that got a private number very early).
Ok, I think I'm understanding you now.

I'll experiment with the format.

>
> Bottom line: If you care about efficiency on the wire, use BER
> encoding of the OIDs. If efficiency is not much of a concern since
> these OIDs only show up rarely, a string encoding may be easier for
> implementors.
Sounds like BER might be the better choice.

A string encoding may be easier for some implementors but might require
translation into a string if any OIDs being exported are already stored internally
with a BER encoding. I'm thinking more of the case where the value of a mibObject
is itself an OID.

Exporting the value is more likely to be a straight copy into the export packet if it
is in the same format.

The encoding is already a standard and there are library implementations of the BER encoding.
Also anything extracting values out of an existing MIB implementation will probably already
have support.

Thanks,
colin   

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