Subject: BER encoding of Unsigned32 and BITS

From: "chum chum"<[email-masked]>
Date: Thu, 04 Sep 03 11:25:24

Hello,

I read the RFC 3084 (COPS-PR) and find in the example of BER encoding for EDP that:

02 01 08          :ipv4FilterIndex/Unsigned32/Value = 8

However, in the book "Understanding SNMP MIBs", page 396, Unsigned32 has a tag encoding of 0x42, not 0x02. Could someone tell me which one is correct?

How about BER encoding for BITS?
For example, in RFC 3317 (COPS-PR for DiffServ)

DsIfAlgDropCapsEntry ::= SEQUENCE {
        dsIfAlgDropCapsType                BITS,
        dsIfAlgDropCapsMQCount             Unsigned32
}

I want to encode the following:

dsIfAlgDropCapsType/BITS/value = 0011100 (binary)
Tag value = ??
length = ??
value = ??

Thank you very much,
C.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Sep 2003 11:55:59 +0200

>>>>> chum chum writes:

chum> I read the RFC 3084 (COPS-PR) and find in the example of BER
chum> encoding for EDP that:

chum> 02 01 08 :ipv4FilterIndex/Unsigned32/Value = 8

chum> However, in the book "Understanding SNMP MIBs", page 396,
chum> Unsigned32 has a tag encoding of 0x42, not 0x02. Could someone
chum> tell me which one is correct?

RFC 3159 (which defines the SPPI) follows the SMIv2 and defines
Unsigned32 as follows:

Unsigned32 ::=
    [APPLICATION 2]
        IMPLICIT INTEGER (0..4294967295)

The tag [APPLICATION 2] indeed becomes 0x42 in BER so I guess RFC 3084
is buggy. If others agree to this, you should submit a defect report
to the RFC editor.

chum> How about BER encoding for BITS?  For example, in RFC 3317
chum> (COPS-PR for DiffServ)

[...]

chum> I want to encode the following:

chum> dsIfAlgDropCapsType/BITS/value = 0011100 (binary) Tag value = ??
chum> length = ??  value = ??

I guess this is not really defined but I think you can assume that the
usual SNMP serialization rules defined in the transport mappings apply
which say that BITS are encoded as OCTET STRINGs (RFC 3417, section 8):

   (3)   When encoding an object whose syntax is described using the
         BITS construct, the value is encoded as an OCTET STRING, in
         which all the named bits in (the definition of) the bitstring,
         commencing with the first bit and proceeding to the last bit,
         are placed in bits 8 (high order bit) to 1 (low order bit) of
         the first octet, followed by bits 8 to 1 of each subsequent
         octet in turn, followed by as many bits as are needed of the
         final subsequent octet, commencing with bit 8.  Remaining bits,
         if any, of the final octet are set to zero on generation and
         ignored on receipt.

Of course, the COPS-PR/SPPI documents should say that somewhere.
(Perhaps they do and I just did not see that - otherwise this is
again something for the RFC editor's errata page.)

/js

---

From: Kwok Ho Chan <[email-masked]>
Date: Fri, 05 Sep 2003 16:46:33 -0400

Please see inline below with <KHC> denoting my comments.
Thanks!
-- Kwok --

>is buggy. If others agree to this, you should submit a defect report

<KHC>
The above indicated example section does contain a typo "02".  It should be 
"42".
The typo is only in the example section, it does not affect the definition 
sections of the RFC.
Please submit the correction.

>again something for the RFC editor's errata page.)

<KHC>
The SPPI (RFC 3159) does not list all types used in PIBs, it only indicate
the ones different from SMI.  The ones that are not defined in SPPI are assumed
to be same as in SMI.  This is stated in SPPI, section 2 on page 4 as:
"This document specifies the SPPI also via a ASN.1
definition, which is a modified version of the SMI's definition,
together with descriptive text for only those elements in the SPPI's
ASN.1 definition which have differences from the SMI's.  For elements
in the ASN.1 definition which have no descriptive text in this
specification, the reader is referred to the SMI's descriptive text
for that element."

Hence IMHO, no RFC editor's errata page needed for this.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Sep 2003 12:36:47 +0200

>>>>> Kwok Ho Chan writes:

[...]

Kwok> <KHC> The SPPI (RFC 3159) does not list all types used in PIBs,
Kwok> it only indicate the ones different from SMI.  The ones that are
Kwok> not defined in SPPI are assumed to be same as in SMI.  This is
Kwok> stated in SPPI, section 2 on page 4 as: "This document specifies
Kwok> the SPPI also via a ASN.1 definition, which is a modified
Kwok> version of the SMI's definition, together with descriptive text
Kwok> for only those elements in the SPPI's ASN.1 definition which
Kwok> have differences from the SMI's.  For elements in the ASN.1
Kwok> definition which have no descriptive text in this specification,
Kwok> the reader is referred to the SMI's descriptive text for that
Kwok> element."

Kwok, please note that the serialization of BITS into OCTET STRING
values is not defined in the SMI and hence your comment does not
really help.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Kwok Ho Chan <[email-masked]>
Date: Mon, 08 Sep 2003 15:00:50 -0400

Juergen:

The intent for the SPPI is to reuse as much of SMIv2 as possible.
I believe BITS is a construct created in SMIv2 (I think in the modified 
version).
And it is described in RFC 2578 (SMIv2) section 7.1.4 on page 22.

If you feel the SPPI (RFC 3159) needs to be corrected, please advise.
Thank!
-- Kwok --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Sep 2003 09:01:28 +0200

>>>>> Kwok Ho Chan writes:

Kwok> The intent for the SPPI is to reuse as much of SMIv2 as
Kwok> possible.  I believe BITS is a construct created in SMIv2 (I
Kwok> think in the modified version).  And it is described in RFC 2578
Kwok> (SMIv2) section 7.1.4 on page 22.

Kwok,

we are discussing the _encoding_ of BITS and not the BITS construct
per se. As I wrote before, the _encoding_ of BITS when using SNMP is
defined in RFC 3417 section 8 and is not really defined for COPS-PR as
far as I can tell.

/js

---

From: Kwok Ho Chan <[email-masked]>
Date: Mon, 15 Sep 2003 16:24:29 -0400

Chum:
SPPI treats BITS the same way SNMPv2/SMIv2 does, as a pseudotype.
Hence the encoding will be the same.

>dsIfAlgDropCapsType/BITS/value = 0011100 (binary)
tag value = 0x04  (same as for OCTET STRING)
length     = 0x01
value       = 0x38  (for binary 0011 100 0, with zero padded at LSBit)

Hope this helped.

We may also need to see if the SPPI needs to be updated on explaining this.

-- Kwok --

At 11:25 AM 9/4/03 +0000, chum chum wrote:
>However, in the book "Understanding SNMP MIBs", page 396, Unsigned32 has a 
>tag encoding of 0x42, not 0x02. Could someone tell me which one is correct?
>