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