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

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> C M Heard writes:

Mike> I have two comments, one substantive and one cosmetic.  First
Mike> the substantive comment: in Section 3, "Overview", the document
Mike> states that

Mike>    It is expected that this MIB module will be updated by
Mike> subsequent RFCs which register additional well-known transport
Mike> domains and which introduce new textual conventions for the
Mike> address formats used by those new transport domains.

Mike> This statement gives the impression that it is possible for
Mike> subsequently-defined MIB modules to contain transport domain
Mike> definitions that effectively extend the values of all of the TCs
Mike> defined in the TRANSPORT-ADDRESS-MIB.  However, that is not
Mike> really true: while it is possible to extend the values of
Mike> TransportDomain and TransportAddress in another MIB module, it
Mike> is not possible to extend TransportAddressType in that way.

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.

(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.

What do people prefer?

Mike> The cosmetic comment is that the heading and values of the
Mike> "encoding" column in the TransportAddressLocal DESCRIPTION
Mike> clause don't line up.

Fixed.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>