Re: How to specify InetAddressType COMPLIANCE requirements

["C. M. Heard" <heard@pobox.com>]

On Thu, 31 Jul 2003, Wijnen, Bert (Bert) wrote:
> I have some people (IPCDN WG) who have (In MODULE-COMPLIANCE):
> 
>    OBJECT diffServMultiFieldClfrAddrType
>       SYNTAX  InetAddressType { ipv4(1) }
>       DESCRIPTION
>          "An implementation is only required to support IPv4
>           addresses."
> 
>       Or possibly a DESCRIPTION text of:
>          "A DOCSIS 1.0, 1.1 or 2.0 implementation is required
>           to support IPv4 addresses at a minimum."

What these say (literally) is that an implementation is not required
to support ipv6(2) addresses even if it supports that protocol.  I
would be inclined to say that this is appropriate only if the MIB
module is IPv4-specific.  That is sometimes appropriate, such as for
the DHCPv4 server MIB, but probably not here, and certainly not in
the general case.

> And I have people (MPLS WG) who have:
> 
>    OBJECT mplsFTNAddrType
>    SYNTAX InetAddressType { ipv4(1), ipv6(2) }
>    DESCRIPTION
>        "An implementation is only required to support IPv4
>         and/or IPv6 addresses.  An implementation is only
>         required to support the address types that are actually
>         supported on the LSR."

This one is better.  But as a model for what to recommend for a
general template it falls a little short, in my opinion.  I say
that because it allows for the possibility that a particular LSR
(label-switched router) supports address types other than IPv4 or
IPv6 but the implementation of this MIB object within that router
only supports ipv4(1) and ipv6(2).  That probably doesn't make any
difference in this case (presumably LSRs cannot support other
address types anyway), but in the general case we can do better.

> The question here is that people want to express that IPv4 support
> is sufficient for devices that do not (yet) have IPv6 stacks
> but they would want to also indicate that IPv6 support is needed
> (required) if the device DOES have an IPv6 stack. In fact, with
> our IETF drive to make sure that all new specs are both IPv4 and
> IPv6 friendly, we sort of force them to consider IPv6.
> 
> I guess in the future (well probably after we all retire) we may
> find devices that no longer have an IPv4 stack, and so we might
> want to carter for that too. I think the mplsFTNAddrType spec
> covers that all pretty well.
> 
> Can we use that sort of statement as a suggestion/recommendation
> for all such MIB modules that are facing this issue?
> 
> I think we can/should. Comments please.

I agree with everything that you have said, but I would suggest
something along the following lines as a template for the general
case:

     OBJECT mplsFTNAddrType
     DESCRIPTION
         "An implementation is required to support the address
          types that are actually used by the LSR, but is not
          required to support other address types."

By leaving out the SYNTAX clause one allows the MIB module to
support any address types that are later put into InetAddressType
repertoire without having to write a new compliance statement, but
the language in the DESCRIPTION clause makes it clear that an
implementation of the MIB does not need to support address types
that are not implemented in the underlying protocol stack.  (Please
note that this is not to be interpreted as a suggestion that the
actual OBJECT clause for mplsFTNAddrType needs to be changed -- I'm
just using it as a handy example).

Another option might be to write separate compliance statements for
IPv4 and IPv6, but it's less flexible and sounds like more work than
is actually warranted.

Mike