Subject: SnmpAdminString for entmib

From: Randy Presuhn <[email-masked]>
Date: Tue, 6 Jul 1999 12:40:11 -0700 (PDT)

Hi -

Attached are three recent messages I sent to the [email-masked] list.
I'm re-sending them since the earlier posting were blocked by the list's
spam filters.  Bert Wijnen requested that I also send this material to
the mibs mailing list, since the issue transcends the entmib work and
potentially applies to several other MIBs.

 ------------------------------------------------------------------------
 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.
 ------------------------------------------------------------------------

> From rpresuhn Fri Jul  2 12:05:49 1999
> To: [email-masked]
> Subject: SnmpAdminString for entmib
> Cc: [email-masked]
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Hi -
> 
> > From: Keith McCloghrie <[email-masked]>
> > To: [email-masked]
> > Date: Fri, 2 Jul 1999 01:52:01 -0700 (PDT)
> > Cc: [email-masked]
> ...
> > Thus, the IESG is asking that we change the objects defined using
> > DisplayString in RFC 2037 so that they are defined using SnmpAdminString.
> 
> This seems reasonable.
> 
> > It would be simple if we could just change the SYNTAX clause of the
> > relevent objects (entPhysicalDescr, entPhysicalName, entLogicalDescr).
> > However, RFC 2578 (section 10.1) says:
> > 
> >  (2)  The value of a SYNTAX clause may be replaced by a textual
> >       convention, providing the textual convention is defined to use the
> >       same primitive ASN.1 type, has the same set of values, and has
> >       identical semantics.
> > 
> > SnmpAdminString has the same primitive ASN.1 type, and it does have the
> > same semantics, but SnmpAdminString has a larger set of values than
> > DisplayString.  So, we believe the legality of this is questionable.
> 
> But it's no worse than questionable.  Let's look at the interoperability
> impact:
>      Old Manager to new agent:
>          GETs: if values happen to be composed from 7-bit ASCII: no problem
>          GETs: if values include other code points: those code points will
>                probably not be displayed correctly, but nothing worse
>                will happen
>          SETs: if values happen to be composed from 7-bit ASCII: no problem
>          SETs: if values include other code points: no problem; the manager
>                isn't supposed to be able to do this anyway  :-)
>      New Manager to old agent:
>          GETs: if values happen to be composed from 7-bit ASCII: no problem
>          GETs: if values include other code points: no problem; the old
>                agent isn't supposed to be able to do this :-)
>          SETs: if values happen to be composed from 7-bit ASCII: no problem
>          SETs: if values include other code points: no problem; the
>                old agent may reject this SET request with badValue or
>                wrongValue (depending on SNMP version and proxy).
> 
> Of course, this neglects to mention those agent implementations that
> don't check DisplayString repertoire, for which this change would
> be of no consequence whatsoever.
> 
> It seems to me that there is no NEED to deprecate the objects in question,
> and that being able to support non-english environments is a big win.
> 
> > Therefore, the IESG is effectively requesting that we deprecate all the
> > objects which use DisplayString, and define a new object for each such
> > deprecated object using SnmpAdminString instead.  
> 
> I think that would be a case of letting our procedures overrule our
> common sense.  Due to the compatibility between DisplayString and
> SnmpAdminString, the interoperability impact of simply changing the
> syntax clause is far less than the impact of deprecating the existing
> definitions and registering new ones.  I just don't see the need to
> deprecate the definitions with this TC substitution.
> 
> An AGENT-CAPABILITIES statement should suffice for those legacy
> implementations that are restricted to 7-bit ASCII.
> 
> >                                                   I believe we
> > need WG consensus to make such a change.   So, please provide your
> > input on whether you are willing for such a change to be made, and if
> > not, then your reasons for opposing it.
> ...
> 
> 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.
> 
>  ------------------------------------------------------------------------
>  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.
>  I live in a large American city whose name has non-ASCII characters.
>  ------------------------------------------------------------------------

> From rpresuhn Fri Jul  2 12:10:40 1999
> To: [email-masked]
> Subject: SnmpAdminString for entmib
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Hi -
> 
> > From: Keith McCloghrie <[email-masked]>
> > To: [email-masked]
> > Date: Fri, 2 Jul 1999 01:52:01 -0700 (PDT)
> > Cc: [email-masked]
> ...
> > For the benefit of internationalization, the IESG is requesting 
> > that all MIBs use SnmpAdminString rather than DisplayString.  In
> > particular, they are asking that this WG's latest MIB module
> > (draft-ietf-entmib-v2-05.txt) use SnmpAdminString instead of
> > DisplayString for all objects.
> ...
> 
> I raised this issue on this list in August 1997.  It's good to know that
> the IETF is sooo much faster than other standards bodies.  :-)
> 
>  ------------------------------------------------------------------------
>  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.
>  ------------------------------------------------------------------------

> From rpresuhn Fri Jul  2 12:13:23 1999
> To: [email-masked]
> Subject: RE: SnmpAdminString
> Cc: [email-masked]
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Hi -
> 
> > From: Andrew Smith <[email-masked]>
> > To: "'Keith McCloghrie'" <[email-masked]>, [email-masked]
> > Cc: [email-masked]
> > Subject: RE: SnmpAdminString 
> > Date: Fri, 2 Jul 1999 11:07:02 -0700 
> > 
> > 
> > I do not think we should make this change - entPhysicalDescr,
> > entPhysicalName and entLogicalDescr are some of the most widely used objects
> > in the RFC2037 MIB and it would be painful to deprecate them. By all means
> > add some new objects to mirror them but don't change the STATUS of these
> > ones.
> ...
> 
> I agree that deprecating the objects would be a mistake.
> I am not persuaded by the argument that changing from DisplayString
> to SnmpAdminString should require deprecating the objects.
> 
>  ------------------------------------------------------------------------
>  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.
>  ------------------------------------------------------------------------
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 Jul 1999 21:16:55 +0000

Randy Presuhn wrote:
>....

I was going to send email to mention this...
I can neither confirm nor deny that certain agent implementations
treat this type of object merely as 'scratchpad memory' for the NMS. ;-)

In implementation, an agent makes no use of the contents of these
objects, and therefore has no reason to check anything but the length.

> > deprecate the definitions with this TC substitution.

I agree 100%

> >    far less than that of creating new objects.

I think a WG consensus is emerging to add 'replacement' SnmpAdminString 
objects, and leave the existing objects untouched. (Now if only the IESG 
would agree, I could do the edits ;-)

> >  Randy Presuhn           [email-masked]     http://www.bmc.com/

Andy