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

[Fred Baker <fred@cisco.com>]

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.