Re: DS MIB - please review this list...

["C. M. Heard" <heard@vvnet.com>]

On Fri, 2 Mar 2001, David Harrington wrote:
> I don't remember why NetworkAddress was deprecated in SMIv2. It seems to
> me that if we want a tagged address, or a discriminated union, that
> NetworkAddress did just that using one extra byte in the Octet String,
> rather than as a separate InetAddressType object. On the face of it, the
> NetworkAddress approach seems simpler.
> 
> Can somebody refresh our collective memories about why NetworkAddress
> was deprecated? Does the InetAddress approach avoid the problem of
> NetworkAddress, and provide a more flexible, easier to maintain address
> type?

The problem with NetworkAddress was that SNMP was not designed to allow
type extensibility.

RFC 1155 defined NetworkAddress as a CHOICE type, presumably with the
intent that it would be able to represent any kind of network address,
including those that had yet to be invented.  It was apparently assumed
that new application-wide types with different ASN.1 tags could be
introduced into the SMI as the need arose for new network address types.

In the meantime, RFC 1157 defined the value field of a VarBind in an
SNMPv1 PDU to be of type ObjectSyntax.  ObjectSyntax was a CHOICE type
imported from RFC 1155 containing all of universal and application-wide
types that RFC 1155 allowed an object to be.  The SNMPv1 elements of
procedure in RFC 1157 required that a PDU containing a varbind value field
with an unknown ASN.1 tag be discarded and flagged as an ASN.1 parse error.

The upshot was that introducing new application-wide types would obsolete
deployed SNMPv1 implementations.  That meant that it was impractical to
introduce new tagged types into the SMI, which made NetworkAddress
useless for its intended purpose.

SNMPv2 carried forward the SNMPv1 feature (or bug, depending on your
perspective) of allowing only a fixed set of types in the value field
of a varbind.  SMIv2 made it illegal to use the Opaque type to get
around this stricture, so the only legal method that remains for
defining open-ended types is the TEXTUAL-CONVENTION.

>From my perspective, NetworkAddress would have been a very elegant way
to solve the variable-type address problem had SNMP been designed to
support extensible data types.  When used in a value field of a varbind
NetworkAddress was encoded on the wire in the same manner as whichever
of the choices was active.  In other words, in that context the type
was discriminated by the ASN.1 tag, without any extra octet.  The
situation was, of course, different when it was used as an index object.
The prescription in RFC 1212 for making an instance-identifier from a
NetworkAddress-valued index object was to append "`n+1' sub-identifiers,
where `n' depends on the kind of address being encoded (the first
sub-identifier indicates the kind of address, value 1 indicates an
IpAddress)".  That prescription is indeed much like an <InetAddressType,
InetAddress> pair, but without the presence of an extra object. 

Mike