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

[Keith McCloghrie <kzm@cisco.com>]

I remember it differently.

The SMIv1 did intend to allow new address types to be added as and when
appropriate.  That's why RFC 1155 defines this:

                  -- application-wide types

                  NetworkAddress ::=
                      CHOICE {
                          internet
                              IpAddress
                      }

                  IpAddress ::=
                      [APPLICATION 0]          -- in network-byte order
                          IMPLICIT OCTET STRING (SIZE (4))
                  ...

and in RFC 1212:

   To define the instance identification information, determine which
   object value(s) will unambiguously distinguish a conceptual row.  The
   syntax of those objects indicate how to form the instance-identifier:
          ...
          (5)  NetworkAddress-valued: `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); or,
          ...

However, none were added to the SMIv1 because doing so would have
required coding changes in the implementation of every SNMP engine,
effectively requiring a version change.  So, when it came time to
define SMIv2 (see RFC 1442), we adopted Marshall's proposal to just
define NsapAddress as a new type and forget NetworkAddress entirely.

I've always thought the right solution would be to allow a leaf object
to have a syntax of "SEQUENCE { type1, type2, ... }", but INDEXing
would be even more messy than it was in 1212 (see above quote), and so
nobody ever agreed with me.

Keith.

 
> At 05:52 PM 3/2/2001 -0500, David Harrington wrote:
> >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?
> 
> Pure recollection...
> 
> As I recall, Keith was concerned that some implementations might define a 
> fixed length storage vehicle to store the NetworkAddress in, such as
> 
>          typedef
>          union NetworkAddress {
>              struct IpAddress {
>                  unsigned char type;
>                  unsigned char address[4];
>              } ipaddress;
>          } networkaddress;
> 
> which a new variable length network address (such as an IPv6 address or a 
> CLNS NSAP) might overrun. This would cause issues in a deployed 
> implementation if a new NetworkAddress type were defined. So we went in the 
> direction of guaranteeing that the bug would occur - we made a TC called 
> IpAddress whose length is implicit and is exactly four bytes.
> 
> My observation at the time was that an choice is inherently a variable 
> length object and contains within it its own length. Thus, a sensible 
> implementation could either verify that it had storage to write to before 
> doing the write, or could allocate storage.
> 
> The InetAddress approach helps, in that people are on notice that they 
> should be able to store a 16 byte address in one. It is not future-proof, 
> however. If in the future we come up with an IPv17Address of 31 bytes, we 
> are guaranteed to be storing the string in a fixed length container of 16 
> bytes. A variable length object would be better.
> 
> 
>