Re: comments on draft-ietf-sming-reqs-02.txt: I18n

[David Harrington <dbh@enterasys.com>]

Hi Frank,

4.3.18 says nothing about restricting this to enterprise mib definitions.

My company purchases some product from OEMs, who develop their own proprietary mibs
to expose the management information related to their product. If we allow i18n in
enterprise mibs, then we begin to run into problems such as

1) which languages must our mib tools understand to compile the mibs for our
products? I don't want to have to fight with our OEM supplies about which language
to use.

2) which languages must our customers' mib tools support to be able to compile the
mibs that define the management information for our products? I'm sure our
customers don't want to fight with our support staff over what languages must be
able to be imported into somebody else's tools.

By having one languagge defined as the standard for writing the information in
mibs, we avoid those kinds of problems, just as we avoid problems by having one
langauge defined for writing mibs (the SMI), rather than making the choice of
langauge optional (e.g. by allowing "mibs" to be written in SMI, SPPI, GDMO, MOF,
etc.)

If the engineer you mention doesn't speak English and wants to write mibs in
French, and it will never been seen outside his company, I say more power to him.
Let him write it however he wants; but it is still non-standard, and compilers that
are written to be compliant to the standard need not understand French. If we make
i18n part of the SMI, then compilers written to be compliant either must understand
any language anybody wants to use, or must be explicitly allowed to ignore the
information contained in a mib module. In the second scenario, we have mibs written
that cannot be compiled using the commonly available tools, and cannot be
understood by most network operators in the world. I don't see that such a
situation helps promote standardization of products across vendors and across
national boundaries. By establishing one language as the standard for writing text
in mibs, we limit the range of languages an operator must learn to work with mibs
(ASN.1, SMI, and English).

I realize this is does not make things easy for those who don't speak English, but
mibs are also not easy for those who don't speak ASN.1 or SMI. I think it would be
a bad mistake to allow people to start developing mibs in GDMO and MOF and other
languages because they don't know the langauge that has been established as the
standard language for defining mibs.

dbh

Frank Strauss wrote:

> Hi!
>
> >> > 71: We believe that 4.3.18 should be "nice to have". See also the
> >> >     comments in Appendix A.
> >>
> >> [Dave] Saying Internationalization would be nice to have seems to be an
> >> innocuous change. Any objections?
>
> David> This topic has been raised multiple times in the IETF. Fred Baker made
> David> it very clear that documents must be written in English, the language of
> David> the IETF. Maybe that will change under the new leadership, but it hasn't
> David> changed yet.
>
> David> I strongly disagree with i18nized DESCRIPTIONS, or any other element of
> David> the language that could impact the interpretation of the specification.
>
> David> There should be one and only one language that is the standard for the
> David> official specification, and the IETF has declared that English is that
> David> language. I have no objection to somebody publishing a translation into
> David> other languages, but there should only be one official specification in
> David> the one official language, in case translation creates ambiguities.
> David> Otherwise interpretation and interoperability suffer.
>
> David, please read carefully what this requirement is about. We
> absolutely agree that (a) all the SMIng documents and (b) all
> DESCRIPTIONs and other stuff in each and every IETF-defined SMIng
> module *MUST* be written in english.
>
> But we don't want to enforce a Frenchman to write his closed MIB
> modules for his closed single company in a language he does not even
> understand, if the module never gets to an IETF guy's eyes. This would
> be narrow-minded and anything else but a flexible design.
>
>  -frank