Hi folks,
Randy Presuhn (editor of the RFC 190x updates for the IETF SNMPv3 WG)
has some good clarifications below. In particular, he observes that
the 'over-the-wire' syntax of these objects does *not* change (always
was the ASN.1 base type 'OCTET STRING').
Read on, if you're interested in the reasoning details.
Cheers,
- Ira McDonald (consulting architect at Sharp Labs America)
High North Inc
-----Original Message-----
From: Randy Presuhn [mailto:rpresuhn at dorothy.bmc.com]
Sent: Tuesday, January 11, 2000 10:19 AM
To: snmpv3 at lists.tislabs.com
Subject: Re: Issue 1907-18 proposed text
Hi -
> Message-Id: <v04220800b49f7e8b9dbf@[10.69.10.3]>
> In-Reply-To: <200001060232.SAA17791 at dorothy.peer.com>
> References: <200001060232.SAA17791 at dorothy.peer.com>
> Date: Mon, 10 Jan 2000 07:48:30 -0500
> To: Randy Presuhn <rpresuhn at dorothy.peer.com>, snmpv3 at lists.tislabs.com> From: Robert Story <rs-snmp at revelstone.com>
> Subject: Re: Issue 1907-18 proposed text
...
> I'm relatively new to this list, so I have missed the initial
> discussion of this issue. Does anyone have a link to the list
> archives and a timeframe for the initial discussion so I could catch
> up? Given the disclaimer that I'm probably raising objections that
> have already been raised (and possibly resolved), here's my two cents.
There was fairly extensive discussion on the lists of the
entity MIB working group. The thread started in July/August
1997. It revived in July and August of 1999, with concurrent
discussion on the mibs at ops.ietf.org list.
If there are problems accessing those archives, let me know
and I'll see if I can distill out a relevant subset of the
discussion.
> I think that changing the semantics/syntax of an existing object is a
> really bad idea. I can't tell you how many times I've had to explain
> to a client that we couldn't change the syntax of an object once the
> MIB was published. I don't relish the prospect of now having to tell
> these clients that their existing agents/management applications need
> to be updated because one of the standards has gone and changed the
> semantics/syntax of an existing object.
Neither the syntax nor the semantics would be changed.
The syntax remains OCTET STRING. The semantics are laid out
in the DESCRIPTION clause. The change is that a restriction in
the permitted repertoire would be lifted. It's rather like the
CCRs that prohibit tile roofs for houses in my neighborhood.
There may have been a reason for such a restriction 25
years ago, but it no longer makes sense.
> I'm all for adding support for multibyte characters, but I think we
> should follow the same rules we impose on the rest of the world.
> I've never liked the "do as I say, not as I do" mentality.
>> Why not add a new branch, copy the existing one, update
> DisplayStrings to SnmpAdminStrings, and depreciate the old branch?
> Adding multibyte character support is going to mean that agents and
> management applications are going to have to be updated, regardless
> of whether or not the change is 'in-place' or a new branch is to be
> supported.
That's why the "weasel words" are proposed for the DESCRIPTION
clauses. As a practical matter, robust management systems have
long had to deal with the reality that some agent implementations
have not enforced the NVT ASCII constraint. See the archives
of the entity mib and MIBs mailing lists for detailed arguments.
The decision to take this approach in those cases was not arrived
at lightly, and the trade-offs should be thoroughly understood
in this case as well.
------------------------------------------------------------------------
Randy Presuhn randy_presuhn at bmc.comhttp://www.bmc.com/
Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street
Fax: +1 408 965-0359 San Jose, California 95131 USA
------------------------------------------------------------------------
Any relationship between my opinions and BMC's should be coincidental.
------------------------------------------------------------------------