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

Would it be a solution to assign some OID for this message and
then say that entry 1024 would contain

  "<the assigned OID> - Too many errors in the configuration file."

In which case you have a specific value for machine readable checking 
(<the assigned OID>) and human readable text that people can even 
localize if they want to.

Just thinking aloud here.

Bert

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of
> Eugene Nechamkin
> Sent: Thursday, January 13, 2005 18:47
> To: Randy Presuhn
> Cc: [email protected]
> Subject: RE: [ipcdn] [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
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
>