[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: InetAddressType DEFVAL clause



HI,

The value of "0.0.0.0" is incorrect in the example below.
A valid value is '00000000'h.

<soapbox>
The InetAddressType and InetAddress TCs are poster childs
for why we need a discriminated union data type!
</soapbox>

At 10:32 AM 5/23/2003 -0600, Eduardo Cardona wrote:
>Sorry my previous message was send before wrap up ( I hate the email
>composer with the save Icon by the send icon)
>
>
>Hi all,
>
>I wonder if the DEFVAL clause should or should not be used in a
>InetAddressType  OBJECT-TYPE definition. Should be a common practice in
>a RowStatus type to describe that type and Address MUST be set together?
>
>Supposed that a table is created (a) by the agent in a discovered
>process or (b) by a manager. 
>
>In (a) the system can detect the IPv6/Ipv4 address type and derive the
>type by itself.  
>
>
>When a manager is creating a row (b) may be desirable to or not to
>include the type during the sets. 
>The length of the Address 4 | 8| 16 | 20 at least will identify if is
>ipv4, ipv4z, ipv6 and ipv6z but a more  sophisticated tool would  be
>needed to detect if the type is dns, If that is the interpretation the
>DEFVAL clause is not acting as supposed which is to initialize the
>missing column parameter with the DEFVAL value, 
>if not the DEFVAL clause should not be used in InetAddressType
>definitions which I think is the intention of RFC3291 as quoted below.  
>
>>From RFC 3291 
>"
>The value of an InetAddress object must always be
>consistent with the value of the associated InetAddressType
>object. Attempts to set an InetAddress object to a value
>which is inconsistent with the associated InetAddressType
>must fail with an inconsistentValue error.
>" 
>
>
>Now, since the above paragraph is a must requirement, and this TC
>convention is becoming very common for the IPv6 transition, I guess an
>extension for RowStatus in the RFC3291 content would be desirable to
>overcome redundant information in MIB definitions and to normalize the
>InetAddress as much as possible, or in draft
>draft-ietf-ops-mib-review-guidelines-xx.txt
>
>
>Another point that worries me is the wrong interpretation of InetAddress
>in some RFCs 
>
>For example, in RFC 3176 
>"
>
>sFlowCollectorAddressType OBJECT-TYPE
>     SYNTAX      InetAddressType
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>       "The type of sFlowCollectorAddress."
>     DEFVAL { ipv4 }
>     ::= { sFlowEntry 8 }
>
>sFlowCollectorAddress OBJECT-TYPE
>     SYNTAX      InetAddress
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>       "The IP address of the sFlow collector.
>        If set to 0.0.0.0 all sampling is disabled."
>     DEFVAL { "0.0.0.0" }
>     ::= { sFlowEntry 9 }
>
>"
>As indicated above, some definitions are indicating to implementers that
>an InetAddress type ipv4 size is in general from 9 characters (0.0.0.0.0
>-in other words encoding 0x302e302e302e30) to 15 octets
>(255.255.255.255) same can happen to Ipv6 definitions creating a lot of
>confusion in the early implementation
>
>Advise would be appreciated
>
>Eduardo
Regards,
/david t. perkins