Subject: SnmpAdminString for entmib

From: "Bert Wijnen" <[email-masked]>
Date: Tue, 6 Jul 99 23:49:00 DST

Ref:  Your note of Tue, 06 Jul 1999 21:16:55 +0000

Subject: Re:   SnmpAdminString vs DisplayString

Andy responds to Randy:
> > >
> > > 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.
>
> 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 ;-)
>
Not sure I get what you are saying.
What does "add 'replacement'" mean?
I think you want to say that "change DisplayString Objects to
SnmpAdminObjects, keeping same OID and same descriptor.
Did I get that right?

Bert

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 6 Jul 1999 14:54:46 -0700 (PDT)

Hi -

> Date: Tue, 06 Jul 1999 21:16:55 +0000
> From: Andy Bierman <[email-masked]>
> To: Randy Presuhn <[email-masked]>
> CC: [email-masked], [email-masked]
> Subject: Re: SnmpAdminString for entmib
> References: <[email-masked]>
....
> > > 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.
> 
> 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.

I know that versions of our MIB compiler prior to January 1994 did
not automatically generate code to perform these repertoire checks for
DisplayString.   

...
> would agree, I could do the edits ;-)
...

This strategy would be my second choice.  My first choice would be to
simply change the TC referenced in the SYNTAX clauses from DisplayString
to SnmpAdminString.  No new objects needed, no need to deprecate the old.

I realize that the course I'm advocating might be a harder sell with IESG
MIB mavens and that what you're advocating is more "proper", but path the
WG is headed on bring its own risk: with two objects conveying the same
semantics, which takes precendence when their values are not identical?

If we really believe the party line on "deprecated", and if the existing
object "goes away" eventually, is its disappearance better or worse for
interoperability than the possibility that a byte with the high-order
bit set should appear in what an old manager thinks is a DisplayString?

 ------------------------------------------------------------------------
 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: Randy Presuhn <[email-masked]>
Date: Wed, 7 Jul 1999 09:33:51 -0700 (PDT)

Hi -

> Date: Wed, 7 Jul 1999 10:54:46 +0200
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> CC: [email-masked]
> References:  <[email-masked]>
...
> Replacing SYNTAX DisplayString with SYNTAX SnmpAdminString stretches
> SMIv2 rules (section 10.1 of RFC 2578). It may be justified to do so
> in this particular case. However, we should also make sure that this
> does not soften the rules in RFC 2578 in general. I suggest to add
> text to the relevant document(s) explaining the rationale and the
> tradeoffs for this change.
...

I agree that we shouldn't interpret this as a general relaxation of
the SMIv2 rules.  Perhaps the document's change history section
would be a good place for the rationale?