RE: InetAddressType DEFVAL clause

["Eduardo Cardona" <e.cardona@CableLabs.com>]

Thanks for the response, 

I think I agree in all your interpretations. 

still I believe the current TC may lead in re-stating the same
conditions in many mibs where could be avoided if defined in a general
scope.

Let me explain a little bit:
Many systems rely in DEFVAL to minimize configuration overhead, TC
Inetaddress/Type have the unique characteristic of being interdependent
by nature rather than application specific.

My interpretation of DEFVAL clause in RFC2578 is that it does not impose
the DEFVAL as whatever is in the clause if not defined in a SNMP SET. I
believe that if a DEFVAL "suggested" value is not possible under certain
conditions, rather that a DEFVAL clause a more specific DESCRIPTION
clause would be the prefered one 

In the InetAddress case, 
As an example 

A user creates a row with Address (ipv6) but not type (leave default
value)
1) One agent can recognize the situation and override the DEFVAL =
'ipv4' with Type = 'ipv6'
2) Another implementation  may ignore the Type value and leave DEFVAL =
'ipv4', resulting in an inconsistency 


From RFC 3291
"
InetAddress ::= TEXTUAL-CONVENTION 
....
"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. "

"

Under that restriction (implementation side) 
How a type is parsed by the agent based on the address : 
Type = 'ipv4' <-> Address SIZE = 4 && all octets <> "." 
Type = 'ipv4z' <-> Address SIZE = 4 && all octets <> "." 
Type = 'ipv6' <-> Address SIZE =  16 && all octets <> "." 
Type = 'ipv6z' <-> Address SIZE  = 20 && all octets <> "." 
Type = 'dns'  <-> Address (SIZE > 0 && at least one octet == ".") ||none
of above ? -> local DNS 
Type =  'unknown' <->  SIZE == 0 || none of above


a) Does it mean that a previously defined entry cannot change (e.g from
Ipv4 to Ipv6)?
Or 
b) Needs to be destroy and recreated?
Or 
c) set a Null value in Address, then the agent turns Type into
'unknown' then the Address can be set to the specific required type and
Type becomes the associated type to the las Address set?
d) Impose a multiple varbinds SNMP SET in the manager side 

a) and b) I believe are undesirable in all conditions, d) not sure if
realistic.

I believe the quoted section may indicate that the agent is capable
enough to try to conbey to option c)(desired one IMO )  but still not
work if multiple addresses objects are associated with the same Type. 
Then the quoted statement could be reevaluated for something like. 

"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 change the fail with an inconsistentValue error. "

-----Original Message-----
From: C. M. Heard [mailto:heard@pobox.com] 
Sent: Friday, May 23, 2003 10:44 AM
To: mibs@ops.ietf.org
Subject: Re: InetAddressType DEFVAL clause


On Fri, 23 May 2003, Eduardo Cardona wrote:
> 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 ?

I don't see anything particularly pernicious about a DEFVAL for an
InetAddressType object, provided that a compatible DEFVAL is given for
all InetAddress columns whose type it governs.  Note that RFC 3291 is
quite explicit in requiring that an agent not permit inconsistent
combinations, and that should be sufficient to catch errors.



> Another point that worries me is the wrong interpretation of 
> InetAddress in some RFCs For example in RFC 3176

RFC 3176 is an Informational document describing a proprietary MIB
module.  I'd be more concerned about this appearing in a document that
was produced by an IETF WG or by another SDO.  Can you point to such a
document?

> Some documents are indicating to implementers that an InetAddress size

> is in general from 9 characters (0.0.0.0.0) in other words encoding 
> 0x302e302e302e30 to 15 (255.255.255.255) same can happen to Ipv6

I saw a DEFVAL { "0.0.0.0" } in RFC 3176 but nothing about the
InetAddress size being 9 octets.  That may be just an oversight and not
such a glaring misunderstanding as you suggest.  Of course it's possible
that I missed something.  Again, the real concern would be if that
appeared in a document produced by an IETF WG or by another SDO.

//cmh