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

On 11/03/2013 05:12 PM, Juergen Schoenwaelder wrote:
> On Sun, Nov 03, 2013 at 04:14:53PM -0800, Andrew Feren wrote:
>> On 11/03/2013 11:05 AM, Juergen Schoenwaelder wrote:
>>> On Fri, Nov 01, 2013 at 04:47:05AM +0100, Brian Trammell 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.
>>>>
>>> SNMP uses ASN.1/BER and this gives you are much more compact encoding
>>> of OIDs (but this is of course a much less human/programmer friendly
>>> representation).
>> So, would a simple octetArray like Brian asked about make sense?  I'm
>> still not sure.
> Not sure exactly what Brian proposed but a sub-identifier can be up to
> 32-bit long.

OK.  I need to give this some thought, but perhaps a string is better.

>>>> IpAddress -> ipv4Address (side question: how do you do V6 with SNMP?)
>>> The IPv6 address types are an OCTET STRING on the wire (not a tagged
>>> type anymore).
>> I've occasionally wondered if an ipAddress type (varlen 4 or 16 octets)
>> would be useful in IPFIX.
> Maybe it is but surely this is not how SNMP represents data; the
> InetAddress textual convention actually can carry zone indexes and
> hence the assumption 4 or 16 octets may not hold true in general.
Perhaps the details of my example were too narrow, but my question remains.

Actually, reading Juergen's comment I went looking for the InetAddress
textual convention and was reminded that some textual conventions denote
structure which we will need to represent.  Even looking at a simpler
textual convention like InetPortNumber which is just a name for a
unsigned16 I'm not sure what I should do with that if sent using IPFIX. 
Is that:
sourceTransportPort
destinationTransportPort
collectorTransportPort
exporterTransportPort
postNAPTSourceTransportPort
postNAPTDestinationTransportPort

Perhaps it is possible to use other info in the various MIBs to map an
InetPortNumber appropriately, but I'll need to do some more looking to
really know.

Juergen, just out of curiousity... What exactly is the "zone index" in
the InetAddress?  I read some words in RFC3291, still wasn't clear how
that is used.

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