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

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 26 Aug 2009 23:30:13 +0200

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) 
To: Romascanu, Dan (Dan) ; Bert Wijnen (802.1) 
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))

Thanks,

Frank

From: Frank Chao (fchao) 
Sent: Monday, August 03, 2009 2:50 PM
To: 'Romascanu, Dan (Dan)'
Subject: Octet String as Index longer than 128 OIDs

Hi Dan,

   Need your help to resolve this problem.

   I am working on the .1X-REV MIB and have a problem as you have reviewed.  One object is defined (1,,253) octet string and will be used as INDEX, apparently, the maximum OIDs length is more then 28 as standard specified.  But people in the .1 security group still think that it is possible the length of the object could be 253 octet when people configured this object information.  The original thought was to divide into 2 objects but after deep thinking, it is the same because they both will be in the index field.  Do you have any experience about this or you have solution for this ?

Thanks a lot,

Frank

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.409 / Virus Database: 270.13.58/2308 - Release Date: 08/16/09 21:46:00

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Aug 2009 07:33:37 +0200

On Wed, Aug 26, 2009 at 11:30:13PM +0200, Bert Wijnen (IETF) wrote:
> From: Frank Chao (fchao)<mailto:[email-masked]>
> To: Romascanu, Dan (Dan)<mailto:[email-masked]> ; Bert Wijnen (802.1)<mailto:[email-masked]>

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/>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 27 Aug 2009 08:41:11 -0400

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: [email-masked] 
> [mailto:[email-masked]] 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
> 
> > To: Romascanu, Dan (Dan)<mailto:[email-masked]> ; Bert 
> Wijnen (802.1)<mailto:[email-masked]>
> > 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.
> > 
> > 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 27 Aug 2009 14:48:39 +0200

http://www.ieee802.org/1/files/private/X-rev-drafts/d4/IEEE8021-PAE-REV-
MIB-D4-0.txt 

I think that this is the last balloted version. 

Dan

> [mailto:[email-masked]] On Behalf Of David Harrington