Subject: Re: [Adslmib] Re: BITS vs OCTET STRING

From: [email-masked]
Date: Mon, 11 Jul 2005 10:54:33 +0300

Hi Randy,

      Thanks very much for your inputs.

       The two issues that you raised will be investigated and a decision
made accordingly.

Kind Regards,

Menachem Dodge
ECI Telecom Ltd.
Broadband Access Division

Tel:      +972-3-9268421
Mobile: +972-54-5788421
Fax:      +972-3-9287342

                      "Randy Presuhn"                                                                                                     
                      <randy_presuhn@mind         To:      <[email-masked]>                                                   
                      spring.com>                 cc:      [email-masked], [email-masked], [email-masked],                 
                      Sent by:                    [email-masked]                                                            
                      adslmib-bounces@iet         Subject: [Adslmib] Re: BITS vs OCTET STRING                                             
                      f.org                                                                                                               

                      11/07/2005 07:07                                                                                                    

Hi -

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

----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; "Robert Ray" <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
> 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

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib