Subject: RE: Changing DisplayString to SnmpAdminString (fwd)

From: "Harrington, David" <[email-masked]>
Date: Wed, 4 Aug 1999 10:13:07 -0400

Hi,

The discussion sort of petered out.
I concur that Randy answered by objections.

dbh

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: Wednesday, August 04, 1999 1:12 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Changing DisplayString to SnmpAdminString (fwd)
> 
> 
> Hi,
> 
> I've not seen any discussion of this issue since Dave's and Randy's
> messages.  (I've copied their two messages below because they weren't
> sent to the entmib mailing-list.)  It seems that Randy has refuted
> Dave's objections, and no one has objected to Randy's points.
> 
> Therefore, it appears to me that, for these particular objects in
> draft-ietf-entmib-v2-05.txt, the WG consensus is that we 
> should bend or
> break (whichever interpretation you prefer) the SMI's rules, and
> change their SYNTAX to SnmpAdminString.
> 
> So, Entmib WG members, if you object to th above as the consensus,
> please speak up quickly (say, within the next 7 days, i.e., 
> by 10 August).
> 
> Thanks,
> Keith.
> -------------
> Forwarded messages:
> >From [email-masked] Wed Jul  7 10:27:17 1999
> Message-ID: 
> <[email-masked]>
> From: "Harrington, David" <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
> Subject: Changing DisplayString to SnmpAdminString 
> Date: Wed, 7 Jul 1999 13:17:10 -0400 
> 
> Hi,
> 
> The consensus of this group so far appears to be to just 
> change the SYNTAX
> of existing objects from DisplayString to SnmpAdminString. 
> This consensus is
> based on a number of assumptions.
> 
> As a developer of managers and applications, I'd like to say "let's
> slow down just a bit and be sure we understand the full impact to
> interoperability before we change the syntax of objects."
> 
> ---
> First, to do so would violate rfc2578 10.1, on the asumption 
> that this is
> "no worse than questionable." I disagree with that assumption. I am
> concerned it would set a bad precedent, weaken the rule, and 
> ultimately
> weaken SNMP as a standard. The rule was put into place to 
> assure developers
> that if they developed their application following the rules, 
> they would
> have reduced development costs since they would only need to 
> implement once
> to interoperate with other products that also follow the 
> rules. Ignoring
> this rule violates a "trust" agreement with the industry. I 
> think this is a
> very bad idea.
> 
> Private industry watches the IETF to learn how to do things 
> right. If we set
> the precedent of changing the SYNTAX of an object without using the
> deprecation machanism, then enterprise mib developers will 
> feel free to do
> so as well. No amount of text justifying the decision will prevent the
> precedent from being set. 
> 
> ---
> Second, there is an assumption that interoperability is not a 
> problem. As
> Dave T. mentions in his comments, for some objects, there can be
> interoperability problems. As a class, these are those textual objects
> passed on the wire which the agent must parse to use. Many
> DisplayString/SnmpAdminStrings are never parsed by the agent, 
> just stored.
> But for community names, user names, and others, the agent 
> must actually do
> something based on the value of the object. If a manager sends an
> SnmpAdminString-legal value, but one that is not a legal DisplayString
> value, to an agent that understands only DisplayStrings, the 
> functionality
> to compare the value to some known values might fail, and 
> they might fail
> explicitly because the semantics of the object has been 
> changed, even though
> the OID has not been changed. 
> 
> This is an interoperability problem caused by a change that 
> the deprecation
> mechanism was designed to protect against.
>  
> ---
> Third, when an "old manager" gets a value that exceeds the 
> constraints of
> DisplayString, the observation is that "those code points 
> will probably not
> be displayed correctly, but nothing worse will happen." 
> Apparently, the
> assumption is that being unable to display data properly is not very
> important. I disagree with this assumption.
> 
> Network management is a field with limited availability of trained and
> knowledgeable personnel, so customers demand features that 
> improve the ease
> of use of network management products to reduce the initial 
> and ongoing
> costs of training and support. Application vendors spend lots of money
> trying to provide GUIs and maps and other ease-of-use 
> features; allowing
> customers to specify names used in mibs falls into this 
> category. SNMPv3
> prefers human-readable names over arbitrary integers as 
> indexes for just
> this reason. If one manager can set the value outside the range of
> DisplayString, making it not usable by a compliant "old 
> manager", that will
> reduce the ease-of-use of the products, and increase the
> total-cost-of-ownership of the network.
> 
> I do not think this is a good direction for the IETF to be moving.
> 
> ---
> Fourth, there is an implicit assumption that forcing manager 
> products to
> update to support UTF-8 is both desirable and no big deal.
> 
> I agree that it is desirable. I agree that we have put off requiring
> international character sets for way too long and that we 
> should encourage
> vendors to internationalize their products, and that we 
> should deprecate
> DisplayString in favor of SnmpAdminString. I just think 
> changing the SYNTAX
> of existing objects is very costly, and it puts the burden 
> primarily on
> manager products rather than agent products in a very unfair way. 
> 
> An agent receives a PDU containing an octet string which may 
> contain a value
> in the DisplayString or the SnmpAdminString syntax. The agent 
> is usually not
> required to validate the field. Storage of the field is 
> simply an array of
> octets in either case. From the agent point of view, there is 
> effectively
> little, if any, difference.
> 
> To a manager application, on the other hand, it can make a 
> BIG difference. 
> 
> Most SNMP applications have been written in either C or C++, 
> languages that
> require strings to be declared explicitly as containing wide 
> characters to
> support 16-bit character sets. Most programs have perfectly 
> legally assumed
> that a string, unless declared otherwise, contains normal one-octet
> characters. Indeed most C and C++ standard libraries make 
> that assumption
> for functions like strlen(). To add international support to 
> applications
> will require significantly rewriting applications to handle 
> unicode, and
> many vendors may be forced to upgrade their tools to newer 
> versions to get
> unicode-compatible libraries. This can be very expensive, and 
> could delay
> releases while the new tools are on order.
> 
> Most manager applications with graphical user interfaces rely 
> on a number of
> common GUI APIs, such as those available in MS-Windows or 
> X-windows. The
> display routine APIs often require that the length be specified so the
> window can be properly sized. Standard functions such as 
> strlen() assume
> bytes=characters, so the code which provides the length to be 
> displayed will
> need to be changed to accomodate the SnmpAdminString values. GUI API
> functions, strlen() and other functions from standard 
> libraries are freely
> scattered throughout an application's code, making it a 
> serious expense for
> application vendors to track down all uses of these functions 
> and substitute
> unicode compliant alternatives to preserve their existing 
> user interface
> designs. 
> 
> There are many mibs and many devices being introduced by the IETF and
> enterprises, and management application vendors struggle to 
> stay apace,
> given that the standards haven't penetrated as deeply as we 
> would all like
> into the industry. Vendors who are suddenly forced to 
> internationalize their
> products will need to divert resources from existing projects 
> to resolve the
> sudden problem of being unable to display textual information 
> properly. As a
> result, manager application vendors may be forced to decide 
> whether to miss
> promised deadlines, or eliminate promised new features from 
> their releases,
> or just display garbage to the customer.
> 
> While I support internationalizing applications, I think the 
> assumption that
> "those code points will probably not be displayed correctly, 
> but nothing
> worse will happen" is ignoring the larger realities of the 
> business world.
> Changing the SYNTAX to a semantically different textual 
> convention is not
> the correct way to encourage internationalization.
> 
> ---
> 
> The conclusion that "The interoperability impact of extending 
> the syntax is
> far less than that of creating new objects" is based on a 
> series of faulty
> assumptions. I firmly believe that closer scrutiny will show that "The
> interoperability impact of extending the syntax is far 
> GREATER than that of
> creating new objects."
> 
> dbh
> 
> > -----Original Message-----
> > From: Dave Thaler [mailto:[email-masked]]
> > Sent: Tuesday, July 06, 1999 8:19 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: SnmpAdminString for entmib
> > 
> > 
> > > > I think:
> > > >    Support for languages beyond English is essential.
> > > >    We should have changed these SYNTAXes long ago.
> > > >    Deprecation of the OBJECTs is not necessary.
> > > >    The interoperability impact of extending the syntax is
> > > >    far less than that of creating new objects.
> > [...]
> > > So... I would like to hear some more opinions on this
> > > topic please.
> > 
> > I agree with just changing the SYNTAX as proposed.
> > 
> > I've also been involved in a similar discussion recently,
> > where the question came up about what to do with foreign strings
> > entered as community names.  2574 already uses SnmpAdminString
> > for usmUserName and usmUserSecurityName, but various older mibs such
> > as 1757 (RMON-MIB) just use OCTET STRING for community names, and 
> > 2233 (IF-MIB) uses OwnerString which is defined as ASCII, and 
> > probably needs to be SnmpAdminString instead.  I think the 
> > interoperability issues are similar, where an agent is configured 
> > in Ascii, and the manager is given a community in (say) Unicode, or 
> > vice versa.  I would guess that the "right" thing to do is
> > probably to use the UTF-8 encoding.
> > 
> > -Dave
> > 
> 
> >From [email-masked] Wed Jul  7 12:04:55 1999
> From: Randy Presuhn <[email-masked]>
> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: Re:  Changing DisplayString to SnmpAdminString
> 
> Hi -
> 
> > From: "Harrington, David" <[email-masked]>
> > To: "[email-masked]'" <[email-masked]>
> > Subject: Changing DisplayString to SnmpAdminString 
> > Date: Wed, 7 Jul 1999 13:17:10 -0400 
> ...
> > Second, there is an assumption that interoperability is not 
> a problem. As
> > Dave T. mentions in his comments, for some objects, there can be
> > interoperability problems. As a class, these are those 
> textual objects
> > passed on the wire which the agent must parse to use. Many
> > DisplayString/SnmpAdminStrings are never parsed by the 
> agent, just stored.
> > But for community names, user names, and others, the agent 
> must actually do
> > something based on the value of the object. If a manager sends an
> > SnmpAdminString-legal value, but one that is not a legal 
> DisplayString
> > value, to an agent that understands only DisplayStrings, 
> the functionality
> > to compare the value to some known values might fail, and 
> they might fail
> > explicitly because the semantics of the object has been 
> changed, even though
> > the OID has not been changed. 
> > 
> > This is an interoperability problem caused by a change that 
> the deprecation
> > mechanism was designed to protect against.
> 
> I agree whole-heartedly with this point.  In the specific 
> case in question,
> hoever, this is not an issue since the object is just a 
> "post-it" object
> with no interpretation at the managed system.
> 
> > Third, when an "old manager" gets a value that exceeds the 
> constraints of
> > DisplayString, the observation is that "those code points 
> will probably not
> > be displayed correctly, but nothing worse will happen." 
> Apparently, the
> > assumption is that being unable to display data properly is not very
> > important. I disagree with this assumption.
> 
> With ISO 10646 / Unicode comes no requirement that every 
> system supporting
> those standards be able to display all possible glyphs.  There will be
> code points or combinations of code points that a particular 
> system won't
> be able to display.  A robust implementation would give the user a way
> to find out what the undisplayable bits were supposed to be, such as
> showing the hex or decimal equivalents.
> 
> > Network management is a field with limited availability of 
> trained and
> > knowledgeable personnel, so customers demand features that 
> improve the ease
> > of use of network management products to reduce the initial 
> and ongoing
> > costs of training and support. Application vendors spend 
> lots of money
> > trying to provide GUIs and maps and other ease-of-use 
> features; allowing
> > customers to specify names used in mibs falls into this 
> category. SNMPv3
> > prefers human-readable names over arbitrary integers as 
> indexes for just
> > this reason. If one manager can set the value outside the range of
> > DisplayString, making it not usable by a compliant "old 
> manager", that will
> > reduce the ease-of-use of the products, and increase the
> > total-cost-of-ownership of the network.
> 
> Consider the context: if the administrators of a particular 
> network have
> no common agreements for how they name their resources, they've got an
> even bigger problem.  For networks of any scale, 
> human-readable names are
> useful only to the extent that they fit into an 
> easily-understood naming
> schema, based on logical, physical, geographic, 
> organizational, or other
> considerations.  If a network is running a mix of old and new 
> managers,
> then it should be an administrative decision to abide by a convention
> of only using 7-bit ascii names.
> 
> > I do not think this is a good direction for the IETF to be moving.
> 
> I agree that blind replacement of DisplayString with SnmpAdminString
> would be unwise.  However, I do think that these need to be considered
> on a case-by-case basis, and that there are cases where stretching the
> rule makes sense.
> 
> > ---
> > Fourth, there is an implicit assumption that forcing 
> manager products to
> > update to support UTF-8 is both desirable and no big deal.
> > 
> > I agree that it is desirable. I agree that we have put off requiring
> > international character sets for way too long and that we 
> should encourage
> > vendors to internationalize their products, and that we 
> should deprecate
> > DisplayString in favor of SnmpAdminString. I just think 
> changing the SYNTAX
> > of existing objects is very costly, and it puts the burden 
> primarily on
> > manager products rather than agent products in a very unfair way. 
> > 
> > An agent receives a PDU containing an octet string which 
> may contain a value
> > in the DisplayString or the SnmpAdminString syntax. The 
> agent is usually not
> > required to validate the field. Storage of the field is 
> simply an array of
> > octets in either case. From the agent point of view, there 
> is effectively
> > little, if any, difference.
> 
> Yes and no.  Some agents actually do enforce the NVT ASCII 
> rules.  This
> was a specific item that came up at the interoperability tests years
> ago.
> 
> > To a manager application, on the other hand, it can make a 
> BIG difference. 
> > 
> > Most SNMP applications have been written in either C or 
> C++, languages that
> > require strings to be declared explicitly as containing 
> wide characters to
> > support 16-bit character sets. Most programs have perfectly 
> legally assumed
> > that a string, unless declared otherwise, contains normal one-octet
> > characters. Indeed most C and C++ standard libraries make 
> that assumption
> > for functions like strlen(). To add international support 
> to applications
> > will require significantly rewriting applications to handle 
> unicode, and
> > many vendors may be forced to upgrade their tools to newer 
> versions to get
> > unicode-compatible libraries. This can be very expensive, 
> and could delay
> > releases while the new tools are on order.
> 
> Unicode / ISO 10646 are effectively open-ended.  No one realisitcally
> expects and implementation to be able to display every 
> script.  Nothing
> requires that an implementation map a UTF-8 byte stream into 
> wide chars
> or anything else.  Even the assumption that 16-bit wchars will do is
> fraught with risk: scripts using combining marks may require several
> code points to represent what a user may consider to be one 
> "character",
> and the code space for ISO 10646 is 31 bits.  If an implementation
> can only display code points from the 7-bit ASCII repertoire, fine.
> Just don't lose the data.
> 
> > Most manager applications with graphical user interfaces 
> rely on a number of
> > common GUI APIs, such as those available in MS-Windows or 
> X-windows. The
> > display routine APIs often require that the length be 
> specified so the
> > window can be properly sized. Standard functions such as 
> strlen() assume
> > bytes=characters, so the code which provides the length to 
> be displayed will
> > need to be changed to accomodate the SnmpAdminString values. 
> 
> This doesn't even work correctly for 7-bit ascii
>    - with proportional fonts
>    - with tabs
>    - with CR, LF
>    - with BS overstrike
> 
> >                                                              GUI API
> > functions, strlen() and other functions from standard 
> libraries are freely
> > scattered throughout an application's code, making it a 
> serious expense for
> > application vendors to track down all uses of these 
> functions and substitute
> > unicode compliant alternatives to preserve their existing 
> user interface
> > designs. 
> 
> There are two completely separate issue here:
>    1) display / entry of these code points
>    2) communication of these code points between systems
> 
> For the first issue, display and entry of data, the 
> application supports
> whatever scripts / languages it supports.  Period.  Just because my
> system supports Unicode does NOT mean that it needs to be able to
> put Amharic glyphs on the screen.
> 
> The second, from my perspective, means that "bits is bits" should be
> the rule for shoveling this stuff between systems.
> 
> > There are many mibs and many devices being introduced by 
> the IETF and
> > enterprises, and management application vendors struggle to 
> stay apace,
> > given that the standards haven't penetrated as deeply as we 
> would all like
> > into the industry. Vendors who are suddenly forced to 
> internationalize their
> > products will need to divert resources from existing 
> projects to resolve the
> > sudden problem of being unable to display textual 
> information properly. 
> 
> Supporting UTF-8 between systems does NOT require anyone to
> internationalize anything.  All it means is that if I want to send a
> message in Armenian, I know which code points to use.  It doesn't say
> that my tools need to give me a way to enter or display that message.
> 
> >                                                             
>             As a
> > result, manager application vendors may be forced to decide 
> whether to miss
> > promised deadlines, or eliminate promised new features from 
> their releases,
> > or just display garbage to the customer.
> 
> I see it the other way around.  We're removing an obstacle 
> from the path
> of vendors who'd like to support customers who prefer to use languages
> other than 7-bit English to refer to their equipment.
> 
> > While I support internationalizing applications, I think 
> the assumption that
> > "those code points will probably not be displayed 
> correctly, but nothing
> > worse will happen" is ignoring the larger realities of the 
> business world.
> 
> With code points in the hopper for amendments to ISO 10646 
> and Unicode for
> years to come, I doubt that anyone expects any product to be able to
> satisfactorily display every glyph of every script.  For 
> management products
> that only support an English-only view of the world, nothing 
> really changes.
> The administrative domains for which such products are 
> adequate will continue
> to be able to function as they do today.
> 
> If those administrative domains have a requirement to go beyond 7-bit
> ascii in naming elements of systems, then it is reasonable that they
> have an even more pressing need to obtain appropriately localized
> management systems.
> 
> > Changing the SYNTAX to a semantically different textual 
> convention is not
> > the correct way to encourage internationalization.
> 
> We are not changing the semantics.  We are extending the repertoire.
> Code points and character sequences that are technically illegal in
> DisplayString (though enforced with widely varying strictness in
> implementations :-) are permitted in SnmpAdminString.
> 
> The objective is NOT to encourage internationalization.
> It is to permit localization.  I'd love to see a management
> system display "San Jose, California" correctly spelled.
> 
> > ---
> > 
> > The conclusion that "The interoperability impact of 
> extending the syntax is
> > far less than that of creating new objects" is based on a 
> series of faulty
> > assumptions. I firmly believe that closer scrutiny will 
> show that "The
> > interoperability impact of extending the syntax is far 
> GREATER than that of
> > creating new objects."
> 
> Summary of counter arguments:
> 
>     1) I concede argument 1, though I'm afraid that horse has already
>        left the barn.
> 
>     2) Argument 2 applies only if the string has a machine-interpreted
>        structure.  This is not the case for the objects in entmib; but
>        I agree that for this reason we can't do a "blanket" upgrade in
>        all MIBs.
> 
>     3) Argument 3 applies only if an administration uses 
> names requiring
>        glyphs not supported by the management systems it has deployed.
> 
>        This failure mode is still possible in an environment where
>        everything understands UTF-8.  We don't need to engineer around
>        administrative stupidity.  If my network administrators give
>        arabic names to all their resources but neglect to install
>        support for that script on any of their display systems, they
>        deserve what they get.
> 
>     4) Argument 4 is based on the incorrect assumption that 
> support for
>        UTF-8 entails support for every script whose code points might
>        appear in a UTF-8 byte stream.  A more reasonable 
> implementation
>        course would be to support the scripts for which that product
>        is (or possibly can be) localized. 
> 
>  
> --------------------------------------------------------------
> ----------
>  Randy Presuhn           [email-masked]     
> http://www.bmc.com/
>  Voice: +1 408 616-3100  BMC Software, 
> Inc.           965 Stewart Drive
>  Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
>  
> --------------------------------------------------------------
> ----------
>  Any relationship between my opinions and BMC's is probably 
> coincidental.
>  
> --------------------------------------------------------------
> ----------
>