text for removal of reduntant size/range constraints

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

On Sat, 5 Jul 2003, C. M. Heard wrote:
> JS> j) The text at the start of page 27 says that addition of restrictions
> JS>    is an editorial change if the restriction makes an already existing
> JS>    protocol imposed restriction explicit. Question: Is it the removal
> JS>    of "duplicate" restrictions also considered an editorial change?
> JS>    The typical example is "DisplayString (SIZE (0..255))" where the
> JS>    size constraint adds nothing new to the DisplayString definition.
> 
> BW> I would say that such would be allowed too.
> 
> I agree, subject to the proviso that I don't think that that there should
> be any rule against such things as "DisplayString (SIZE (0..255))").

Here is the proposed text.

On page 27, change:

   - Although not specifically permitted in bullets (1) through (8), it
     is generally considered acceptable to add range constraints to the
     SYNTAX clause of an integer-valued object, provided that the
     constraints simply make explicit some value restrictions that were
     implicit in the definition of the object.  The most common example
     is an auxiliary object with a SYNTAX of INTEGER or Integer32 with
     no range constraint.  Since an auxiliary object is not permitted to
     assume negative values, adding the range constraint (0..2147483647)
     cannot possibly result in any "over the wire" change, nor will it
     cause any compilation compatibility problems with a correctly
     written MIB module.  Such a change SHOULD be treated by a reviewer
     as an editorial change, not as a semantic change.

to:

   - Although not specifically permitted in bullets (1) through (8), it
     is generally considered acceptable to add range constraints to the
     SYNTAX clause of an integer-valued object, provided that the
     constraints simply make explicit some value restrictions that were
     implicit in the definition of the object.  The most common example
     is an auxiliary object with a SYNTAX of INTEGER or Integer32 with
     no range constraint.  Since an auxiliary object is not permitted to
     assume negative values, adding the range constraint (0..2147483647)
     cannot possibly result in any "over the wire" change, nor will it
     cause any compilation compatibility problems with a correctly
     written MIB module.  Such a change SHOULD be treated by a reviewer
     as an editorial change, not as a semantic change.  Similarly,
     removal of a range or size constraint from an object definition
     when that range or size constraint is enforced by the underlying
     data type SHOULD be treated by a reviewer as an editorial change.

//cmh