Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-syslog-snmp-00

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Mar 2009 23:25:53 +0100

On Wed, Feb 25, 2009 at 01:37:24PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder <[email-masked]> wrote:
> > 
> > I just typed "I will do this" when I figured out that there is still a
> > potential problem. A MIB aware translator able to apply DISPLAY-HINTs
> > will turn a MacAddress binary value '00E0812E961E'h into
> > "00:E0:81:2E:96:1E" and a MIB unaware receiver might turn this back
> > into '30303A45303A38313A32453A39363A3145'h. This would be bad. I see
> > two options:
> > 
> > a) We always ship the hex value in addition to the rendered value. We
> >    might consider using base64 instead of hex to save space.
> > 
> > b) We restrict the alternate textual representations to DISPLAY-HINTs
> >    of the form 'Na' or 'Nt' where N is some number. This implies that
> >    a MacAddress or a DateAndTime value will be carried in hex / base64
> >    representation.
> > 
> > Hm, not nice.
> 
> [...]
> 
> > Given this, the simplest solution for the string
> > mapping problem mentioned above would be to actually do the same.
> 
> Yes.  An alternative could be that for the DISPLAY-HINTs in case b)
> above, the hex string does not need to be sent.

Yes, this should works. I have written this down in the updated ID I
have just submitted.

/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/>