Re: [MIB-DOCTORS] Fw: Octet String as Index longer than 128 OIDs, 8021X-REV MIB issue

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Wed, Aug 26, 2009 at 11:30:13PM +0200, Bert Wijnen (IETF) wrote:
> MIB Doctors, Dan and I have receieved the below question.
> 
> I have answered that I find it ugly (at least not pretty).
> 
> The question is... what is a good solution? I can't quicklly think of
> a good and nice solution. Do we have ideas/sugegstions?
> 
> Pls copy Frank explicitly, because he is not on the mib-doctors list
> 
> Bert
> 
> ----- Original Message -----
> From: Frank Chao (fchao)<mailto:fchao at cisco.com>
> To: Romascanu, Dan (Dan)<mailto:dromasca at avaya.com> ; Bert Wijnen (802.1)<mailto:bert802 at bwijnen.net>
> Sent: Saturday, August 15, 2009 12:19 AM
> Subject: RE: Octet String as Index longer than 128 OIDs, 8021X-REV MIB issue
> 
> Hi Dan and Bert,
> 
> I am trying to resolve this issue to define a TC.  Not sure it is workable.  Can you help me to review the TC I proposed.
> 
> 
> OctetStringInOIDEncoding ::= TEXTUAL-CONVENTION
>     DISPLAY-HINT "255t"
>     STATUS       current
>     DESCRIPTION "This is a textual convention designed to represent
>                  an octet string containing administrative
>                  information, but encoded in the OBJECT IDENTIFIER
>                  format.
> 
>                  Each sub-identifier must not exceed the value
>                  2^32 - 1 (4294967295 decimal) [RFC2578] with 4
>                  bytes space needed to store the value. An object
>                  sub-identifier can hold 4 octets information, each
>                  octet (8-bit byte). Therefore, encoding 4 octets
>                  into a sub-identifier in the index field can reduce
>                  the length of OIDs of the columar objects.
> 
>                  The purpose of this textual convention is to help
>                  increase the maximum length of an OCTET STRING object
>                  ,as an index, to 256 octets long. Currently, the
>                  sub-identifiers of an instance of a columar
>                  object is limited 128 [RFC2578]. If using the
>                  OCTET STRING object as the INDEX, the mximum length
>                  of the OCTET STRING index will be limited less than
>                  128. By encoding the OCTET STRING information into
>                  OBJECT IDENTIFIER, the longer OCTET STRING can be used.
> 
>                  The encodeing rules is as following :
> 
>                  Octets are numbered by their position in one
>                  sub-identifier, starting at zero. Position zero
>                  is the high order (or left-most) byte in the
>                  first sub-identifier of the list of
>                  sub-identifiers. Position 3 is the low order
>                  (or right-most) byte of the first sub-identifier
>                  of the list of sub-identifers.  Position 4 is
>                  the high order byte in the second sub-identifier
>                  of the list of sub-identifiers, and so on. When
>                  the number of bytes is not a multipple of four,
>                  then there will be remaining bytes in the final
>                  sub-identifier. When a value of the octet string
>                  is encoded into OID list format, the remaining
>                  bytes, if any, of the final sub-identifier are
>                  set to zero. The octet string values are grouped
>                  four per sub-identifier (4-byte integer).
> 
>                  Encoding of 'n' octets string, numbered 0 to
>                  (n - 1) octets string are in (n + 3) / 4
>                  sub-identifier.  And any remaining octets in the
>                  last sub-identifier should be zero.
> 
>                  This textual convention should be only used for
>                  the object as INDEX object(s) of a conceptual
>                  table.
>                 "
> SYNTAX      OBJECT IDENTIFIER (SIZE (1..64))

Technically, I do not see how the length of the OCTET STRING will be
communicated. That said, I agree with Bert that this looks ugly.  The
question is why you need such a long INDEX and whether the MIB module
can be restructured to avoid it. This is usually how we deal with
this, not always nice but in most cases workable. Remember that having
such long indexes is also costly since every table cell will carry it,
making every getnext/getbulk walk more costly.

Before you ask, no I do not have the MIB module in question and I also
have no cycles to work on it if you send it me. This is just a
suggestion for you or the IEEE group to think whether there are others
ways to index things, e.g. by introducing index numbers for the long
octet string you are deadling with.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>