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

From: "Michael W. Patrick" <[email-masked]>
Date: Wed, 10 May 2000 11:32:18 -0400

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: "Mike St. Johns" <[email-masked]>
Date: Thu, 11 May 2000 09:54:37 -0700

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.