Re: Protocol operations proposal deadline

>>>>> On Fri, 13 Sep 2002 17:28:39 +0100, Dave Shield <[email protected]> said:

Dave> I'm concerned that my desire for flexibility might end up derailing
Dave> your object-oriented approach - so how about the following
Dave> proposal.

I don't think so, actually.

Dave> The basic PDU format defined for SNMPv4 (or whatever we decide to
Dave> call it) could look something like:

Dave>      PDU ::=
Dave>          SEQUENCE {
Dave>              request-id
Dave>                  Integer32,
Dave>              error-status
Dave>                  INTEGER,
Dave>              error-index
Dave>                  INTEGER,
Dave>              error-description
Dave>                  OCTET STRING,
Dave>              options
Dave>                  OCTET STRING,
Dave>              variable-bindings
Dave>                  VarBindList
Dave>          }

That structure doesn't match what I have in my document, as you'll see
shortly.  I don't think VarBindLists are the wave of what I'd like to
see in the future as they're still tied to complex oid encodings which
have been limiting things for too long.  As far as the error-* fields,
I've gotten a lot of feedback saying they don't really need to be in
the outgoing request and that having exactly-matching PDUs isn't
really necessary as it used to be.

Dave> But the semantics of the individual bits of the 'options' field
Dave> are left undefined for now.  (Or probably some "fallback
Dave> semantics" are defined, leaving the door open for making use of
Dave> this field later).

I believe there are correct ways to deal with options within BER (as
Randy mentioned) without requiring a genericly wrapping OCTET STRING.
Traditionally in the past, SNMP hasn't used the extension mechanisms
but maybe it's about time we start.

Since I know you can read BER blind, an extension in BER has an outer
wrapping (if Randy and I are talking about the same thing).  Thus, if
the we have 2 fields an INTEGER and a OCTET STRING, both of which are
optional within the parent enclosure (not shown) the encoding might
look like any of the following:

INTEGER only, value = 1:
  A0 03 02 01 01

OCTET STRING only, value = 'A':
  A1 03 04 01 65

both, same values:
  A0 03 02 01 01 A1 03 04 01 65

As you can see there is an outer-wrapper with application specific
tags indicating the field being specified.  Now, I do need to go look
up the details about defining this within ASN.1, but this is how you
should "technically" do extensions within BER encodings I think.
Someone with a better grasp on ASN.1 rules might correct me at this point.

Anyway, we can argue over encoding semantics in a bit once the WG
makes a decision as to what we should go forward with.

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett