RE: [pkt-prov] MTA MIB Error OID table - a number of questions

> If that is not practical, then, 
> at least for the cases that a script or automated management 
> system would need to recognize, the EXACT strings that appear 
> in protocol should be spelled out, with recognition that a 
> user interface might present some localized equivalent.

Let me remind you that the initial concern was the presense of almost
mandatory requirement for the EXACT particular string 'TOO MANY ERRORS
IN THE CONFIGURATION FILE' which seemed to be not in line with the
language localization on the managed device (if such required in some
environments). As a recognition of this, the modification has been
proposed which softened the requirement.

Given the fact that the NMSs can accommodate various logics of mapping
the messages generated by the range of devices to the locally
meaningfull events, the last proposed text seems to be satisfactory
because it 1). allows localized text on the managed devices (if
necessary), and 2). still does not prevent the NMSs from using the
corresponding localization policies with the managed devices.

Eugene.


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Randy Presuhn
Sent: Wednesday, January 12, 2005 11:19 PM
To: [email protected]
Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of
questions

Hi -

> From: "Eugene Nechamkin" <[email protected]>
> To: "Randy Presuhn" <[email protected]>
> Cc: <[email protected]>
> Sent: Wednesday, January 12, 2005 8:44 PM
> Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of 
> questions
>
> If your concern is the usage of the object in the different lingual 
> environments with presumably normative language in the object's 
> description, then the proposed, I believe, adequately addresses your 
> concern. If your concern is the interoperability, then the object 
> itself, without the normative requirement, carries the informative 
> meaning for the NMS personal, and is becoming even wider
interoperable.
>
> If this is still not satisafctory, please feel free to make a specific

> editorial suggestion.
...

A managed device has no way of knowing what locale(s) may be in effect
on the network management systems (both human-controlled and purely
automated) that are communicating with it.  The locale in effect may
even change, depending on which operator is currently using a management
system.
Consequently, localization of error messages is something to be done at
the management systems, not the managed devices.

NMS operators are not all human.  More and more work is done by scripts
and programs working on behalf of humans.  In general software isn't all
that good at figuring out "semantic equivalents".  The problem is even
worse if the localized text doesn't carry some kind of language tag.

Error messages are quite different from names and labels.  The latter
can be treated as opaque values by software, and in general there's no a
priori value that can be associated with them.  Error messages, on the
other hand, do have semantics, and management software will be expected
to alter its behaviour based on the messages it encounters.

My preference is for a machine-readable enumeration of error codes.
If that is not practical, then, at least for the cases that a script or
automated management system would need to recognize, the EXACT strings
that appear in protocol should be spelled out, with recognition that a
user interface might present some localized equivalent.

Randy



_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn