<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...
[EMAIL PROTECTED] 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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
