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

Paul Aitken <[email protected]> Wed, 17 Dec 2014 23:18:21 +0100
Newsgroups gmane.ietf.ipfix
Message-ID <23B7BE54EACBED43957AB709C564F7B701853E2C75@EMEA-EXCH01.corp.brocade.com>
Juergen, Brian, thanks both - that's what I'll do.

P.


> If BITS really isn't intended to encode integers with numeric or flag
> semantics, then yes, it should be encoded as an octetArray.
> 
> Cheers,
> 
> Brian
> 
> > On 17 Dec 2014, at 16:48, Juergen Schoenwaelder
> <[email protected]> wrote:
> >
> > On Wed, Dec 17, 2014 at 04:05:52PM +0100, Paul Aitken wrote:
> >> Thanks for this Juergen. I'll produce an updated version for the editorial issues.
> >>
> >> For the BITS issue, the largest IPFIX types are currently 64 bits (ie,
> >> signed64 / unsigned64). Although we could request a 128-bit type, we're
> >> simply moving the absolute limit along without solving the underlying issue.
> >
> > SNMP encodes the bits into an octet string - an octetArray in IPFIX.
> > Could this be done here as well?
> >
> >> Do you know what size the largest BITS object is today? Would it be
> >> acceptable to limit the size that can be exported in IPFIX to the
> >> first 64 or 128 bits?
> >
> > The first question can't be answered so I can't answer the second. It
> > would be best, though, if IPFIX would not have to introduce a limit.
> > Would an octetArray not work?
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> >
> > _______________________________________________
> > IPFIX mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ipfix

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