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