RE: How to specify InetAddressType COMPLIANCE requirements

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

Thanks for the feedback/comment.

I think that most of these people know that they only want to
write a MODULE-COMPLIANCE for support for IPv4 and/or IPV6.
No DNS, no other address types.

So Leaving in the SYNTAX in the OBJECT clause seems wise to me.

The MIB itself of course has no refinements on the inetAddressType.
It only occurs in the MODULE-COMPLIANCE, so in the event other
or new address types are in need of being supported in the future,
then one can just write a new MODULE-COMPLIANCE in a separate
doc (or in a revision).

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: donderdag 31 juli 2003 18:00
> To: Mreview (E-mail)
> Subject: Re: How to specify InetAddressType COMPLIANCE requirements
> 
> 
> 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
> 
>