RE: Minutes from the sming wg interim meeting, June6-8,2002 in W ashington DC
"Harrington, David" <[email protected]> Fri, 6 Sep 2002 06:03:39 -0400
| Newsgroups | gmane.ietf.sming |
|---|---|
| Message-ID | <6D745637A7E0F94DA070743C55CDA9BA075E97@NHROCMBX1.ets.enterasys.com> |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2558C.1105E20C Content-Type: text/plain Hi, As SNMP is being more widely accepted, other standards bodies are creating their own mibs, and are not always following all the crappy little rules we define. I have recently run into mibs from other organizations with 0 sub-ids, so we need to be careful about relying on good OID-assignment behavior, and make sure the rationale behind any crappy little rules that would affect this are clearly and prominently documented. dbh > -----Original Message----- > From: Steve Waldbusser [mailto:[email protected]] > Sent: Tuesday, July 23, 2002 9:01 PM > To: David T. Perkins > Cc: [email protected] > Subject: Re: Minutes from the sming wg interim meeting, > June6-8,2002 in > Washington DC > > > > David, > > You're right. I think it really reflects an error in the discussion > and/or minutes rather than an error in the solution. > > You'll be able to skip any zeros in the base during your > traversal to > the top-level table node. For example, if fooTable is { 0 1 0 1 0 1 }, > then you'll skip the zeros as you parse down to figure out > that it's in > the fooTable. At that point the next node cannot be zero > (fooEntry) nor > can nodes below that. > > Another way to put it is that the zero 'separator' must be after the > fooTable node. You shouldn't be looking for the separator until after > you've found the top-level table. > > But we'd better be sure we outlaw zeros in the hierarchy in > SMI-DS just > as we have in 2578 (I think Andy has already done this). > > > Steve > > > "David T. Perkins" wrote: > > > HI, > > > > Note guys that there is a technical assumption in the following that > > is not correct. That is that a zero valued sub-identifier cannot > > occur in the OID for an object type. The only restriction that the > > SMI has it that the last sub-id cannot have a value of zero. Thus, > > any sub-id from the root (and even the root) can have a value of > > zero. For example, it would be valid to have the following > > definition for an object type: > > > > foo OBJEC-TYPE > > ... > > ::= { 0 1 0 1 0 1 } > > > > The rules are in RFC 2578, section 7.10 (last paragraph). > > > > More comments later... > > > > Regards, > > /david t. perkins > > ------_=_NextPart_001_01C2558C.1105E20C Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DUS-ASCII"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2655.35"> <TITLE>RE: Minutes from the sming wg interim meeting, June6-8,2002 in = Washington DC</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Hi,</FONT> </P> <P><FONT SIZE=3D2>As SNMP is being more widely accepted, other = standards bodies are creating their own mibs, and are not always = following all the crappy little rules we define. I have recently run = into mibs from other organizations with 0 sub-ids, so we need to be = careful about relying on good OID-assignment behavior, and make sure = the rationale behind any crappy little rules that would affect this are = clearly and prominently documented.</FONT></P> <P><FONT SIZE=3D2>dbh</FONT> </P> <P><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: Steve Waldbusser [<A = HREF=3D"mailto:[email protected]">mailto:[email protected]= om</A>]</FONT> <BR><FONT SIZE=3D2>> Sent: Tuesday, July 23, 2002 9:01 PM</FONT> <BR><FONT SIZE=3D2>> To: David T. Perkins</FONT> <BR><FONT SIZE=3D2>> Cc: [email protected]</FONT> <BR><FONT SIZE=3D2>> Subject: Re: Minutes from the sming wg interim = meeting, </FONT> <BR><FONT SIZE=3D2>> June6-8,2002 in</FONT> <BR><FONT SIZE=3D2>> Washington DC</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> David,</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> You're right. I think it really = reflects an error in the discussion</FONT> <BR><FONT SIZE=3D2>> and/or minutes rather than an error in the = solution.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> You'll be able to skip any zeros in = the base during your </FONT> <BR><FONT SIZE=3D2>> traversal to</FONT> <BR><FONT SIZE=3D2>> the top-level table node. For example, if = fooTable is { 0 1 0 1 0 1 },</FONT> <BR><FONT SIZE=3D2>> then you'll skip the zeros as you parse down to = figure out </FONT> <BR><FONT SIZE=3D2>> that it's in</FONT> <BR><FONT SIZE=3D2>> the fooTable. At that point the next node = cannot be zero </FONT> <BR><FONT SIZE=3D2>> (fooEntry) nor</FONT> <BR><FONT SIZE=3D2>> can nodes below that.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Another way to put it is that the zero = 'separator' must be after the</FONT> <BR><FONT SIZE=3D2>> fooTable node. You shouldn't be looking for the = separator until after</FONT> <BR><FONT SIZE=3D2>> you've found the top-level table.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> But we'd better be sure we outlaw zeros in the = hierarchy in </FONT> <BR><FONT SIZE=3D2>> SMI-DS just</FONT> <BR><FONT SIZE=3D2>> as we have in 2578 (I think Andy has already = done this).</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Steve</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> "David T. Perkins" wrote:</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> > HI,</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > Note guys that there is a technical = assumption in the following that</FONT> <BR><FONT SIZE=3D2>> > is not correct. That is that a zero valued = sub-identifier cannot</FONT> <BR><FONT SIZE=3D2>> > occur in the OID for an object type. The = only restriction that the</FONT> <BR><FONT SIZE=3D2>> > SMI has it that the last sub-id cannot = have a value of zero. Thus,</FONT> <BR><FONT SIZE=3D2>> > any sub-id from the root (and even the = root) can have a value of</FONT> <BR><FONT SIZE=3D2>> > zero. For example, it would be valid = to have the following</FONT> <BR><FONT SIZE=3D2>> > definition for an object type:</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > foo OBJEC-TYPE</FONT> <BR><FONT SIZE=3D2>> > = ...</FONT> <BR><FONT SIZE=3D2>> > = ::=3D { 0 1 0 1 0 1 }</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > The rules are in RFC 2578, section 7.10 = (last paragraph).</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > More comments later...</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > Regards,</FONT> <BR><FONT SIZE=3D2>> > /david t. perkins</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C2558C.1105E20C--