Re: IP MIB issues

[Brian Haberman <[e-mail]>]

<IPv6 WG co-chair hat on>
I would like to set a one week discussion period for these
issues (i.e. speak your mind by Monday 4/5).  After that,
the chairs will determine if there are reasons to not make
the recommended changes.
<IPv6 WG co-chair hat off>

Further comments in-line...

[e-mail] wrote:

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

I support these changes being made.  I add clarity what is being
reported.

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

I agree that this is an ifTable issue and should not be in the IP MIB
module.  I support removing it.

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

Thanks for the follow-up Shawn.

Regards,
Brian

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