At 07:21 AM 12/1/03 -0500, Brian Haberman wrote:
>Wes Hardaker wrote:
>
>>Unfortunately, I have just learned that I'd really need this update.
>>I'll say this is unfortunate because the cutoff date for comment is
>>tomorrow, and I haven't had a chance to read the document.
>
>I would encourage you to make comments anyway. This MIB won't
>be published right away due to a dependency on an updated Inet
>Address TC document.
>
>>However, a really really really quick scan produced a couple of
>>comments.
>>1) The description field for the ipAddressEntry object is simply
>> ridiculously short:
>> "inet addr entry"
As the editor I thought the description for the table object (ipAddressTable)
covered the entry object as well and therefore repeating the same text would
not be useful. Do you think there is something else that should be added to
the description of the entry that isn't in the description of the table?
DESCRIPTION
"This table contains addressing information relevant to the
entity's interfaces.
This table does not contain multicast address information.
Tables for such information should be contained in multicast
specific MIBs such as RFC3019.
Note well: When including IPv6 link-local addresses in this
table the entry must use an InetAddressType of 'ipv6z' in
order to differentiate between the possible interfaces."
>>2) Was there every discussion about making this table writable? One
>> of the most longstanding needs within MIBs has been the ability to
>> assign addresses to interfaces. I will have to go back and search
>> the mail archives to find out if this was ever discussed, but it
>> would be pretty simple, I would think, to make this table
>> writable. This is the obvious place to make support for settable
>> addresses, so I'm curious as to why it wasn't done...
>
>I don't recall this specific topic being discussed. However, there are
>several MIBs that have gone to having multiple conformance statements.
>One conformance statement handles read-only and the other read-write.
>As for why it wasn't done, these updates have been trying to keep the
>changes to just making the documents support IPv6. Though, we did break
>that with TCP-ESTATS...
>
>Brian
As with Brian I don't recall this specific topic being discussed.
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[EMAIL PROTECTED]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
Shawn A. Routhier
SMTS
Wind River Networks Business Unit
510 749 2095 office
510 749 2560 fax
www.windriver.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
