Re: Pseudo WG Last Call for: http://www.ietf.org/internet-drafts/draft-ietf-ops-taddress-mib-02.txt

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

On Tue, 9 Apr 2002, Juergen Schoenwaelder wrote:
> Mike> For that reason, I suggest that it be pointed out both in the
> Mike> "Overview" section and in the DESCRIPTION clause of the
> Mike> TransportAddress TC that any transport domain registered in a
> Mike> separate MIB module CANNOT be one that is identified by a
> Mike> TransportAddressType value.  The purpose of putting it in both
> Mike> places is to make sure that MIB designers using the TCs are
> Mike> aware of the limitations that come with specifying a
> Mike> TransportAddressType object instead of a TransportDomain object
> Mike> as the context for interpreting a TransportAddress value.
> 
> I am fine with adding such a note. In fact, we need to decide what
> we want to do about this. We have two options:
> 
> (a) Document this difference between TransportDomain and
>     TransportAddressType and let the MIB authors decide how much
>     extensibility they want/need. This might cause surprises down
>     the road.

More precisely, this option forces MIB authors to decide on the
tradeoff between flexibility and convenience.  That's OK, as
long as they do so with their eyes open.  Note that there is a
very simple rule:  if there is the possibility that a
TransportAddress object will need to contain address types other
than those that can be represented with TransportAddressType, then
use a TransportDomain object as the discriminator.  This works,
because the WG that maintains the MIB module has a "contract" to
make sure that there is always a TransportDomain OID corresponding
to each TransportAddressType.

> (b) Partition the TransportAddressType number space similar to
>     SnmpSecurityModel. We will loose the nice enumerations but have
>     the advantage that things will still work with private transport
>     domains. We would require IANA to maintain the assigned numbers in
>     the official non-private number space.

I think this proposal actually creates more problems than it solves.

The first set of problems is administrative workload.  It would clearly
require that TransportDomain OID assignments and corresponding values
in the non-private TransportAddressType number space be maintained in
parallel.  Thus, they'd need to reside in the same IANA-maintained
module, with careful instructions on keeping the two in sync.  And it
would also require writing an IANA considerations section to state on
what authority new assignments can be made.  If the assignments are to
require WG approval, then they might as well live in the MIB module as
they do now.

The second problem is more serious:  there would be two private
methods of identifying transport domains without any obvious way to
guarantee that they are in sync.  In other words, it now becomes
possible not only to have TransportDomain values for which there are
no corresponding TransportAddressType values -- as in (a) above --
but also to have TransportAddressType values for which there are no
corresponding TransportDomain values.  Problems can arise no matter
which discriminator type a MIB designer chooses.

So my vote is for (a).

Mike