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