Subject: Re: [netmod] mapping to snmp strings

From: Randy Presuhn <[email-masked]>
Date: Mon, 16 Dec 2013 10:00:54 -0800 (GMT-08:00)

Hi -

>From: Martin Bjorklund <[email-masked]>
>Sent: Dec 15, 2013 11:01 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [netmod] mapping to snmp strings
>
>Randy,
>
>Do you have a preference?

Yes. (5) would be my first choice, maximizing interoperability,
though it also has the biggest impact on code.  The pathological
"failure" cases are IMO within the bounds of what would be
acceptable under the principle of least astonishment.

(2) would be a distant second.  It has potentially significant
impact on code without helping interoperability.

(4) would be an even more distant third, and it begs the question
of "why bother".

Take these all with a grain of salt.  I'm no longer in this
line of business, so I have comparatively little stake in
the outcome.

Randy

>
>/martin
>
>
>"Randy Presuhn" <[email-masked]> wrote:
>> Hi -
>> 
>> > From: "Martin Bjorklund" <[email-masked]>
>> > To: <[email-masked]>
>> > Sent: Sunday, December 15, 2013 1:58 PM
>> > Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
>> ...
>> > Here are some options:
>> > 
>> >   1.  Do nothing; keep current text.
>> > 
>> >       NOTE: not clear how we handle DisplayString characters
>> >       that are not legal YANG string characters.
>> > 
>> >   2.  Say that implementations MAY map, but that they need to do some
>> >       vendor-specific translation procedure to handle the difference
>> >       in character sets and lengths.
>> > 
>> >   3.  Like 2 + add an additional config false leaf in the YANG model
>> >       to inform the YANG client about the resulting value.  (NOTE:
>> >       this value is of course already available over SNMP).
>> > 
>> >   4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
>> >       specify that there is a mapping between them.
>> > 
>> > Comments?
>> 
>> I'd add an option:
>> 
>> 5) Implementations MUST map in both directions using a *standardized*
>> mapping, with provision for pathological cases due to length constraints
>> and the inherent limitations of superimposing escape schemes onto existing
>> methods.
>> 
>> Randy
>> 
>> _______________________________________________
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod
>>

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 20 Dec 2013 10:14:15 -0800 (GMT-08:00)

Hi -

>From: Benoit Claise <[email-masked]>
>Sent: Dec 20, 2013 8:04 AM
>To: Martin Bjorklund <[email-masked]>, [email-masked]
>Cc: [email-masked]
>Dear all,
>If someone can NOT live with the proposal below, it's time to speak up.
>If no answers (allow a couple of working days), Martin, please post a 
>new draft-ietf-netmod-system-mgmt version. I'll progress the draft from 
>there.

I think the "MUST" and "must" variants of (2) are untenable.

*If* I were implementing this stuff, I'd still push for option
(5) because it would provide the most useful and predictable
interoperability.  However, I'm not implementing this, so I
could live with the "need to" variant of option 2.

(But I reserve the right to say "told you so" at a later date.  :-)

In fairness, while writing a first approximation of
a standardized mapping proposal would be pretty easy,
it quickly becomes messy when one considers how normalization
forms (unfortunately not specified in the definition of
SnmpAdminString) enter the picture, especially when the
DisplayString or SnmpAdminString is used as an index.

Randy