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

["David Harrington" <ietfdbh at comcast.net>]

Hi,

I concur with Juergen.
I recommend redesigning the table structures so the long field is not
an INDEX.
(but I also do not have time to help do the redesign)

I am curious about the nature of the field that requires 253 octets.
Is the proposed MIB available someplace (in text format)?

dbh

> -----Original Message-----
> From: mib-doctors-bounces at ietf.org 
> [mailto:mib-doctors-bounces at ietf.org] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Thursday, August 27, 2009 1:34 AM
> To: Bert Wijnen (IETF)
> Cc: Frank Chao (fchao); MIB Doctors (E-mail)
> Subject: Re: [MIB-DOCTORS] Fw: Octet String as Index longer 
> than 128 OIDs, 8021X-REV MIB issue
> 
> 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/>
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS at ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors
>