RE: Proposed "Last Call" version of draft-ietf-ops-mib-review-gui delines [ Corrected, for the 2nd time ]

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Mmmm... RFC2578 (sect 7.5) says:

7.1.5.  IpAddress

   The IpAddress type represents a 32-bit internet address.  It is
   represented as an OCTET STRING of length 4, in network byte-order.

   Note that the IpAddress type is a tagged type for historical reasons.
   Network addresses should be represented using an invocation of the
   TEXTUAL-CONVENTION macro [3].

So why do we want to suggest that it can be OK to use this type?
The SHOULD allows for exceptions, and that seems good enuf for me.
We are talking about NEW MIB modules, right? I think the reason for 
allowing it is not "instrumenting for an ipv4-cnetrix object", then I
think one would use the below. The only reason I can see the use of an
IpAddress type is for things like alarmActiveVariableIpAddressVal
in the ALARM-IB in RFC3877.

If someone has a need for a specific IPv4 address type, then I would
think it better (in a new MIB MOdule) to allow for just InetAddressIPv4
(which already allows for that in exceptional cases):

   InetAddressIPv4 ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "1d.1d.1d.1d"
       STATUS       current
       DESCRIPTION
           "Represents an IPv4 network address:

              octets   contents         encoding
               1-4     IPv4 address     network-byte order

            The corresponding InetAddressType value is ipv4(1).

            This textual convention SHOULD NOT be used directly in object
            definitions since it restricts addresses to a specific format.
            However, if it is used, it MAY be used either on its own or in
            conjunction with InetAddressType as a pair."
       SYNTAX       OCTET STRING (SIZE (4))

Maybe I do not understand why we have this discussion.
Does anyone have an example of where it (IpAddress) was needed in a NEW MIB
module?


Bert
> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of Juergen Schoenwaelder
> Sent: Saturday, January 08, 2005 15:07
> To: David B Harrington
> Cc: 'C. M. Heard'; 'Mreview (E-mail)'
> Subject: Re: Proposed "Last Call" version of
> draft-ietf-ops-mib-review-guidelines [ Corrected, for the 2nd time ]
> 
> 
> On Sat, Jan 08, 2005 at 08:36:45AM -0500, David B Harrington wrote:
>  
> > If we want to put this in at all, then I prefer Dave's proposed text
> > to Juergen's, since Dave's make it seem more exceptional.
> > "inherently IPv4-centric" is too ambiguous.
> 
> (D) The IpAddress type MAY be used in cases where the
>     object is inherently IPv4-specific and is either 
>     a scalar or appears in a table which is only applicable 
>     to IPv4.
> 
> (J) The IpAddress type MAY be used in cases where the 
>     object is inherently IPv4-specific.
> 
> So what about this:
> 
> (S) The IpAddress type MAY be used in cases where the
>     object is inherently IPv4-specific and only applicable
>     to IPv4.
> 
> My main point was that talking about scalars and tables does not add
> value and creates a special case for accessible-for-notify objects
> which I think does not make sense and was probably not the intention.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
>