Re: BITS vs OCTET STRING

Hi -

Apologies for the massive CC list - is there anyone who is not on the adslmib list?

----- Original Message ----- 
> From: <[email protected]>
> To: <[email protected]>
> Cc: <[email protected]>; "Robert Ray" <[email protected]>; <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>
> Sent: Sunday, July 10, 2005 5:45 AM
> Subject: BITS vs OCTET STRING
...
> As you may know the ADSLMIB WG is currently working on the draft:
> draft-ietf-adslmib-adsl2-00.txt.
> I would like to request your advice regarding one of the issues raised:
>
> Currently the draft has defined a Textual Conventions - Adsl2ScMaskDs
> which  uses the SYNTAX  BITS to
> define 512 bits;  bit0 (0)   .... bit511(511). This bit map indicates
> whether the corresponding bin is in use or not. The value
> zero indicating that the bin is in use and the value one indicating that
> the bin is not in use. This textual convention is used by
> the adsl2LConfProfScMaskDs parameter which is part of the ADSL2 line
> configuration profile. The
> adsl2LConfProfScMaskDs field is not expected to be changed dynamically.
>
> There is also a similar parameter for the upstream direction.

It's probably  time for a TC, no matter which SYNTAX you use.

> An alternative has been proposed in which an OCTET STRING be used instead
> of BITS.
>
> The argument put forward for this change is: Using an OCTET STRING instead
> of a very large BITS type, provides a better economy of description.
>
> Questions:
> 1. The BITS data type was added only in SNMPv2 and it is stored as an OCTET
> STRING. Is the current situation (sequence of 1-bit flags) an example for
> which the BITS data type was defined?

It sounds like it's really an array, rather than a sequence, since the bits
are many instances of the same semantic respectively reporting on many
instances of the same resource type.

Although one *could* use BITS for this, this scenario is not what motivated
the development of the BITS construct.

> 2. Are there any particular issues that we should be aware of, in the use
> of either of the data types?

One advantage of using BITS for this is that extending a MIB module to add
more bits is permitted.  A possible (RFC 2578 section 10.2 (1))  A possible
disadvantage is how generic user interface tools might like to display
the information.

> 3. What would you advise as the better approach?
...

I have a *very* slight preference for OCTET STRING, but could live with
either one.  If you think this thing might grow in future versions of the MIB
module, then BITS  becomes preferable.  You might also consider how well
the tools used for managing these devices handle display of the two types,
in light of the semantics of these objects.

Randy