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

RE: InetAddressType DEFVAL clause



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




-----Original Message-----
From: Eduardo Cardona 
Sent: Friday, May 23, 2003 9:55 AM
To: mibs@ops.ietf.org
Subject: InetAddressType DEFVAL clause