[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BER encoding of Unsigned32 and BITS

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

At 11:55 AM 9/4/03 +0200, Juergen Schoenwaelder wrote:

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

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


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.)


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

/js