Re: FW: I-D ACTION:draft-ietf-ops-mib-review-guidelines-00.txt

["C. M. Heard" <heard@pobox.com>]

On Wed, 12 Feb 2003, Harrie Hazewinkel wrote:
> On Tuesday, February 11, 2003, at 04:52 AM, C. M. Heard wrote:
> > In separate comments, Bert Wijnen has asked me to remove mention here
> > of DisplayString and to point out in Appendix D that it is not to be
> > used in new MIB modules because it does not support i18n.  When I
> > put those changes into Appendix D I will state that SnmpAdminString
> > is the "approved" replacement because it supports UTF-8.
> >
> > Will that take care of these concerns?
> 
> Yes.

Good.  We are still wrangling a bit about the text on the
MIB Doctors list, and once we come to consensus on the
details I will post then here for your review.

> A side note, (note for this document) would it be allowed then
> to replace TC representing UTF-8 with the SnmpAdminString TC??

As far as I know, the SMIv2 documents do not explicitly say one
way or another whether the SYNTAX value in an object definition
can be changed from one TC to another.  However, they do allow
replacement of a base type by a TC provided that the TC resolves
to the same base type and that the semantics are identical with
the original definition.  It seems reasonable, then, to allow one
TC to be replaced by another provided that the base types are the
same and that the semantics are identical.  So, the answer I would
give is that it is OK to replace a TC representing UTF-8 with
SnmpAdminString _if_ that TC has the same semantics as
SnmpAdminString (or if the object's DESCRIPTION has imposed
additional restrictions on the TC to make this so).  Otherwise, no.

Having said that, I should point out that if a MIB module already
defines a local UTF-8 TC then you can't remove that TC from the
module, as it may be in an IMPORTS clause somewhere.  The most you
can do is to deprecate it.  So there is not as much benefit to
"tidying up" as one might think.  My own opinion is that it's
probably best to "grandfather" existing stuff and try to do the
right thing in new modules, and the guidelines are written accordingly.

> >>> 4.7.  Notification Definitions
[ ... ]
> > If you find the text confusing and would like for it to be cleaned up, 
> > it would be helpful to me if you could propose specific changes to the 
> > text.
> 
> What about this:
>     Examples of the second technique can be
>     found in the SNMP-REPEATER-MIB [RFC2108] and in the ENTITY-MIB
>     [RFC2737].
> 
> changes into
> 
>     Examples of the fixed time interval can be
>     found in the SNMP-REPEATER-MIB [RFC2108] and in the ENTITY-MIB
>     [RFC2737].
> 
> 
> Makes it more clear.

I'll be happy to make such a change, but I'm going to say
"fixed time interval technique".

Thanks again for your comments.

//cmh