Subject: [ipcdn] RE: Bit ordering for docsQosParamSetRequestPolicy in QOS-MIB

From: Yost William <[email-masked]>
Date: Wed, 10 May 2000 10:45:16 -0500

I think the MIB should be changed so it is an Unsigned32 syntax.  That would
prevent it from being printed as a negative number by some management
program.  Either that, or an OCTET STRING (SIZE(4)).  If you make it an
octet string, a management program will probably print it in Hex which is
kind of what you want.

The octet string is equivalent to the BITS, as far as the SNMP protocol is
concerned, so that would be the minimal impact of a change to make I think.
It just avoids the built in definition that BITS has of bit 0 being most
significant.

If you don't change the MIB, I think there is going to be a continuing
confusion about what bit means what.

--- William H. Yost, Thomson Consumer Electronics: (317) 587-4816 ---   
. Home of RCA, Proscan, GE electronics .

-----Original Message-----
From: Michael W. Patrick [mailto:[email-masked]]
Sent: Wednesday, May 10, 2000 10:32 AM
To: Yost William
Cc: [email-masked]; [email-masked]
Subject: Re: Bit ordering for docsQosParamSetRequestPolicy in QOS-MIB 

Bill,

Yuck.  As it stands now, it looks like implementors will have 
to reverse and shift the bit orders of a binary request policy (lsb=bit 0)
when reporting the mib docsQosParamSetRequestPolicy(msb=bit 0).

This certainly was not what I intended.

My question is, would it be too confusing at this late date
to update the MIB to match the implementation, 
(e.g. by changing docsQosParamSetRequestPolicy to be an integer),
or should we leave the qos mib as-is and force the bit swap & shift?

-mike

>>>>> "Yost" == Yost William <[email-masked]> writes:

> The bit numbering of these bits is the same (as far as bit numbers
> go) in the QOS-MIB and the RFI Spec (SP-RFIv1.1-I04-000407), but the
> bit ordering is reversed.  SNMP defines bit 0 as the most
> significant bit in BITS, but the RFI Spec, in section C.2.2.6.3
> defines bit 0 as the LSB of the value field.  I assume this is what
> you intended, but I just wanted to double check.

> Here is a copy of the MIB element definition.

> docsQosParamSetRequestPolicy OBJECT-TYPE SYNTAX BITS
> { broadcastReqOpp (0), priorityReqMulticastReq (1), reqDataForReq
> (2), reqDataForData (3), piggybackReqWithData (4), concatenateData
> (5), fragmentData (6), supressPayloadHeaders (7),
> dropPktsExceedUGSize (8) }

> --- William H. Yost, Thomson Consumer Electronics: (317) 587-4816
> --- . Home of RCA, Proscan, GE electronics .

_______________________________________________
IPCDN mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/ipcdn

---

From: Yost William <[email-masked]>
Date: Thu, 11 May 2000 14:11:03 -0500

I agree if no one ever looked at the data inside the modem, but just looked
at a manager which properly displayed the BITS element as a set of
enumerated bit values, you would have no problem.  But some managers will
only show the value as an octet string in hex and you will be looking at a
dump of the configuration file and comparing it to what you see in SNMP and
there will be an opportunity for misuderstanding where there needn't be.

What Mike said below is still true, the agent will have to swap the bits in
the word before returning it in an SNMP reply.  People make mistakes, and
this is just one more place that some implementations may swap the bits and
some may not.

-----Original Message-----
From: Mike St. Johns [mailto:[email-masked]]
Sent: Thursday, May 11, 2000 11:55 AM
To: Michael W. Patrick; Yost William
Cc: [email-masked]; [email-masked]
Subject: Re: [ipcdn] Re: Bit ordering for docsQosParamSetRequestPolicy
in QOS-MIB

Guys -

Your confusing the MIB with the implementation - again.  The MIB is an 
abstraction of how things work underneath.  the BITS construct just maps a 
set of true/false values into an underlying construct that can get 
transmitted across the network.  At the agent end, ignore the bit position 
and concentrate on the bit meaning.  In other words, if the 
suppressPayloadHeaders bit is set in this , do whatever you would normally 
do for suppressPayloadHeaders.  If that's setting the corresponding bit in 
a MAC request, then so be it, but these things ARE NOT LINKED except by the 
name's meaning - the assignment of the actual bit position is a transport 
mapping, nothing more and must not be too closely tied to some other field.

We had this same discussion in packet cable on the syslog level meanings of 
the docsDevEvent priority levels.

---

From: Yost William <[email-masked]>
Date: Thu, 11 May 2000 14:11:03 -0500

- --- William H. Yost, Thomson Consumer Electronics: (317) 587-4816 ---   
. Home of RCA, Proscan, GE electronics .

- -----Original Message-----

Guys -

------- End of Forwarded Message