IP MIB issues

[[e-mail]]

There were two suggested changes to the IP MIB that
may not have had sufficient discussion during the WG last call.

The first is a simple renaming of some objects in order to provide
better clarity.

The second is the removal of an object from the IPv6 interface table
as it may a) not be useful b) be in the wrong table.

The document has been through WG last call and through IESG last call.
There are a small number of editorial revisions required from the IESG last
call so a new revision will be created.  Including the following changes
would
be simple.

The chairs will be sending another piece of mail to specify when the
deadline
for comments is.

**

For issue 1 the original request described it as such:

I believe that use of "AdminStatus" in ipv4InterfaceAdminStatus and
ipv6InterfaceAdminStatus is confusing.

These are not "AdminStatus" in the same sense as ifAdminStatus as is
explained in section 3.2.2.  Rather these enable or disable the
connectivity between a particular version of IP and (one of) the
ifIndex on top of which it operates.  These should really be
xxxInterfaceEnableStatus.

My previous position was to skip this change as it did not seem to be
a major issue and I was attempting to avoid additional changes to the
MIB.

My current position is that as I need to make changes anyway I may as
well include this change.

If there is no discussion I shall change the names of these objects.  If
you feel that the names of these objects should not be changed send mail
by the deadline that the chairs specify.

**

For issue 2 we have the following discussion:

Keith: 
Why is ipv6InterfacePhysicalAddress defined in
draft-ietf-ipv6-rfc2011-update?

For all instances for which it is defined, i.e., all values of i, I believe
the value of ipv6InterfacePhysicalAddress.i is always same as the value of
ifPhysAddress.i

Thus, it is redundant, right ?

**

Shawn:
While I don't have experience with them I've been told by other people
that there are cases where the addresses may be different.  I believe
the example given was an ether switch wherein each interface might have
its own physical address but the box elects to use a single ether
address for some or most purposes.  I can try and find the old
description if you'd like more.

<I was unable to find a better description to send to Keith.>

**
Keith:
This example:

    "an ether switch wherein each interface might have its own physical
    address but the box elects to use a single ether address for some
    or most purposes"

has long been modeled in the Bridge MIB WG as the "switch" having
an internal interface with its own MAC address which id independent of
its external interfaces.

In any case, it's not IPv6-specific.  That is, if such an object were
needed, it would be needed for IPv4 as well, or any past internetwork
protocol (e.g., DECNET) or any future internetwork protocol (IPv9).

Bottom line: I believe the solution to this issue is to have an extra
ifTable row for the second MAC address.  Even if I'm wrong, it's an
ifTable issue, not an IPv6 (or IPv4) issue, and therefore must not be
in this MIB.

**

Previously I was attempting to maintain a potentially useful object.
Upon reflection I have decided that if a better justification for keeping
the object can't be found it should be removed.  

If there is no discussion I shall remove this object.  If you feel it is
a useful object and should be kept send mail by the deadline that the chairs
specify.

regards,
Shawn A. Routhier


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------