Re: draft-ops-endpoint-mib-08.txt

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

>>>>> Thomas D Nadeau writes:

Thomas> That is true, but it just does not make sense to include DNS
Thomas> names in places where only IP (v4/v6/whatever) are required.

Maybe.

Thomas> Is it then reasonable to restrict the subtypes in the
Thomas> DESCRIPTION clauses within the MPLS MIBs?

I think the "problem" here is that the InetAddress* definitions try to
encourage MIB definitions that support new address types if there is
ever a need for it. Now, you want to say that IPv4 and IPv6 is fine,
similar IP addresses may also be fine, but something like DNS names is
not OK. Sure, you can write in the DESCRIPTION clause that a dns(?) is
not allowed for the InetAddressType object. But what if there is
another "unwanted" definition in the future?

>> On the other hand, will there be a problem if you do not subtype
>> and just use the more generic InetAddressType and InetAddress?  Is
>> the object writable or is it readonly?

Thomas> The object is writable. It is also being used as a tertiary
Thomas> index in a table, so the type of address is not necessarily
Thomas> known a priori, so I don't think that this will work. I am
Thomas> open to suggestions though.

Again, why does a DNS name not work? BTW, which document are we
talking about? I found <draft-ietf-mpls-lsr-mib-04.txt> and its usage
of InetAddressIPv4 and InetAddressIPv6 is actually what we tried to
avoid. Note that this construction also won't work with non-global
IPv6 addresses.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>