Subject: Re: [IPFIX] Export of MIB variable in IPFIX: new IETF draft

From: Benoit Claise <[email-masked]>
Date: Fri, 05 Nov 2010 18:31:58 +0100

Hi Juergen,

Thanks for your feedback.
See inline.
> On Tue, Oct 19, 2010 at 04:52:40PM +0200, Benoit Claise wrote:
>>   Dear all,
>>
>> Andrew, Paul, and I posted this new draft, "Exporting MIB variables
>> using the IPFIX Protocol".
>> http://www.ietf.org/staging/draft-johnson-ipfix-mib-variable-export-00.txt
>>
>>         Abstract
>>
>>            This document specifies a way to export Management
>>            Information Base (MIB) objects within the IPFIX protocol,
>>            avoiding the need to define new IPFIX Information Elements
>>            for existing Management Information Base objects that are
>>            already fully specified.
>>
>>            This method requires an extension to the current IPFIX
>>            protocol.  New Template Set and Options Template Sets are
>>            specified to allow the export of Simple Network Management
>>            Protocol (SNMP) MIB Objects.
>>
>>
>> The problem we want to solve is that we keep development two data
>> models for a unique information model (*) , i.e. MIB and IPFIX
>> information elements, which are overlapping. For example: there is
>> an IPFIX information element representing the ifName MIB Object.
>> Note that some more advantages are specified in the draft.
>> (*) RFC 3444, "On the Difference between Information Models and Data Models"
>>
>> Please read it and send your feedback.
> I do not have time for a detailed review, but some things already
> come to mind:
>
> a) I find text like this in several places:
>
>              An alphanumeric-format variable name which denotes a
>              variable name expressed as a sequence of decimal numbers or
>              names separated by periods, as specified by the OBJECT
>              IDENTIFIER in [RFC2578].
>
>     As far as I can tell, RFC 2578 does not specify a format with names
>     separated by periods (and terminology wise 2578 call these "names"
>     descriptors).
Good, we will update this.
> b) It is good to see that you require authorization via VACM. However,
>     this requires that in addition to the variableName the following
>     is known (see RFC 3415):
>
>                securityModel        -- Security Model in use
>                securityName         -- principal who wants access
>                securityLevel        -- Level of Security
>                viewType             -- read, write, or notify view
>                contextName          -- context containing variableName

Actually, I know what I want to write, but I'm not sure how to write it ;-)
Basically, we can't bypass the SNMP authorization.
> c) In the SNMP world, a variable exists in a context. A context is
>     identified by a contextEngineID and a contextName (see RFC 3411).
>     I think you need to make sure this is captured somewhere.
Yes, we forgot this one.

Thanks for your review.

Regards, Benoit.
> > From a quick read, I have not yet understood how the index handling
> works. But I might see if I take more time to read in detail.
>
> /js
>